open_device(, FALSE) fails on one machine

[nikolajsheller]

Hello Allan

I have observed an odd problem on one particular Windows machine where open_device() succeed while enumerating (open_device(..., TRUE)), but fails when opening the the device for access (open_device(..., FALSE) via hid_open_path()).

1. This fails when enumerate is FALSE:
   DWORD share_mode = (enumerate)?
   FILE_SHARE_READ|FILE_SHARE_WRITE:
   FILE_SHARE_READ;

getLastError() yeilds ERROR_SHARING_VIOLATION.

2. This works when enumerate is FALSE:
   DWORD share_mode = (enumerate)?
   FILE_SHARE_READ|FILE_SHARE_WRITE:
   FILE_SHARE_READ|FILE_SHARE_WRITE;

This happens on a Windows 7 Home Premium 64 bit. I have not seen this problem on any other machines running Windows 7 and XP.
All other USB devices work as expected, and when requesting FILE_SHARE_READ|FILE_SHARE_WRITE, my USB device works as expected.

I am mystified as to why I must open a device with more permissions than required, but this is the case.

I can see there is some discussion about access permissions here:
#23
but I am unsure what your conclusion is.

Shall I create a pull request for this change?

Regards
-Nikolaj Løbner Sheller

[signal11]

Yes, this problem gets "fixed" every 3 months or so, but what really happens is that the problem gets shoved around, but every time we think we've fixed it right. Different versions of windows and different devices seem to behave differently, and nobody seems to be able to get all the facts, because most people just have one device or one PC or OS that they're using.

I've been getting emails from people saying that they want FILE_SHARE_READ|FILE_SHARE_WRITE for ages, but the problem is that if you put that in, then devices can't be opened exclusively anymore, which is desirable.

The fact that you're seeing this only on one installation likely means that on the PC that's failing, some other process is opening the device. What kind of device is it? Does it have a program that comes with it that's holding the device open or something like that?

When you say "all other devices work as expected," you're not checking that they are able to be opened exclusively by HIDAPI. You will likely see that the devices can be opened multiple times by HIDAPI, which is not desirable. I'm not 100% sure what the answer is here, but it may be time to just put an exclusive flag in hid_open() and hid_open_path() and try to then push that ability to all platforms. Any thoughts?

[nikolajsheller]

Hello Allan

Thank you for your quick and thorough reply.

I was suspected something along these lines was the case, after reading issue 23.

When I say "all other devices work as expected", I mean that no HID or other devices fail on that machine (mouse, keyboard, Microchip flashing devices etc) during regular use.
So you are correct in that I have not checked that they are able to be opened exclusively by HIDAPI.

My device is a custom device, and uses a unique PID. I do not know what other programs would access it.
Do you have any advice on how to monitor which programs open a given device?

I can see why it is desirable to open devices exclusively, so I agree using FILE_SHARE_READ|FILE_SHARE_WRITE is not a good solution.
My desire is to open my devices exclusively.

Regarding an "open non-exclusively" flag: I need to determine if it is a Windows bug or two programs that access my custom device before deciding whether I think this is a good idea.