Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression: DeviceIoControl failed from libusb_open immediately after libusb_close on Windows 10 #43

Closed
xlz opened this issue Apr 12, 2017 · 3 comments

Comments

@xlz
Copy link

xlz commented Apr 12, 2017

Our users started to get this error on Windows:

libusb_open returned: -99

First-chance exception at 0x00007FFDB1743C58 in Protonect.exe: Microsoft C++ exception: UsbDkDriverFileException at memory location 0x00000095014FDA30. Driver file operation error. DeviceIoControl failed (The system cannot find the file specified. Error code = 2)

First-chance exception at 0x00007FFEC5F83C58 in Protonect.exe: Microsoft C++ exception: UsbDkDriverFileException at memory location 0x000000900C59D3F0. Driver file operation error. DeviceIoControl failed (The system cannot find the file specified. Error code = 2)
OpenKinect/libfreenect2#812 (comment)

The error can be reproduced by libusb_open() immediately after libusb_close() and would go away if there is some time delay between the two calls.

The error is only reproduced with v1.0.17 and not v1.0.16.

@dmitryfleytman
Copy link
Contributor

This is by design. On libusb_close() UsbDk initiates device reset and client have to wait until reset completion in order to open it again.

Commit 848bb79 introduced between versions 1.0.16 and 1.0.17 increased amount of time client application has to wait for device re-appearance, therefore you hit this issue more frequently.

In order to resolve the issue properly, you should either wait for hotplug event related to the device in question or wait for the device in question to re-appear in libusb device list. After that, libusb_open() will work as expected.

@xlz
Copy link
Author

xlz commented Apr 18, 2017

libusb API provides:

Devices are reference counted with libusb_ref_device() and libusb_unref_device(), and are freed when the reference count reaches 0.

The bug happens when the reference count is 1.

libusb_get_device_descriptor, ref=1
libusb_open, ref=2
libusb_close, ref=1
libusb_open <-- bug

Presumably the device should not even be reset when libusb_get_device_descriptor() still holds onto it.

@dmitryfleytman
Copy link
Contributor

UsbDk resets physical USB device on close, this does not affect libusb device structure, it remains valid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants