#14 No detection when multiple LibUsb devices attached

[Pat Kujawa]

I have two libusb devices which, for one of them individually, I have been able to open and communicate with using LibUsbDotNet (LUDN). However, when both devices are attached, LUDN isn't able to locate either device. Tracing the program flow, it looks like part of the problem is in creation of a LibUsbRegistry object: when GetPropertiesSPDRP is called, it iterates through all of the available properties but never successfully retrieves any (LibUsbDriverIO.UsbIOSync always returns false because Kernel32.DeviceIoControlAsObject returns false).

The LibUsbRegistry.DeviceList correctly shows that there are two devices attached and, under LibUsbRegistry.Device.Info, shows the correct VIDs and PIDs for each device. When the LibUsbRegistry object is passed into the Add method as a UsbRegistry object, however, none of the device properties (PID, VID, Name, etc) appear to be populated.

I'll keep testing until I can isolate a bit better.

Note: the problem seems to persist even when one of the devices is removed. Re-attaching to the same or a different port doesn't fix it. Uninstalling and re-installing the libusb driver seems to fix it, as long as only one libusb device is installed.

[Pat Kujawa]

Uninstalling the libusb driver, removing and re-attaching the device, and re-installing the libusb driver (from the LibUsbDotNet package) fixes the problem. LibUsbDriverIO.UsbIOSync returns true (Kernel32.DeviceIoControlAsObject returns true and Kernel32.GetOverlappedResult returns true), and GetPropertiesSPDRP is able to iterate through the device's properties.

Attaching the second libusb device causes the problem to reappear. After that, no combination of removing and replacing devices seems to fix it; the only fix is to uninstall and reinstall the libusb driver.

I'm running Windows 7 Ultimate (as administrator), by the way.

[Travis Robinson]

I Tested using two identical USB devices on Windows 7 32bit and was unable to reproduce this behavior. Are you using windows7 32bit or 64bit?

However, It sounds like the modified libusbdotnet libusb0.sys kernel driver is being replaced with the original driver from the libusb-win32 page when the second device is attached? The modified kernel driver implements the necessary functions to query the device registry properties.

[Pat Kujawa]

I am using 32-bit Windows 7 Ultimate.

You are right; the second device, when placed in a new usb port, was installing different libusb drivers than what was already there (installed by the first device, using LUDN's libusb drivers). I guess the fix lies in changing the libusb driver installation to use the drivers that are present, if any. I would have assumed that this was the default behavior, but apparently not. Do you know how I might set the driver INF to only install the libusb dll and sys files if they are not already present?

On a side note, why was it necessary to modify the libusb-win32 driver for LUDN? It seems like LUDN should be able to support the default libusb driver or else it is not really an interface to libusb, but an interface to a custom driver. Is there any way to make LUDN work with the default libusb? If not, can you submit your changes to the libusb-win32 project so that your customization becomes the default libusb implementation?

Thanks for the great interface. I hope that I am able to continue using it in an upcoming project, despite the aforementioned issues.
Pat

[Pat Kujawa]

I just changed the INF file for one device to name the libusb driver files to something else (i.e. libusb0.dll -> MyDevice.dll and libusb0.sys -> MyDevice.sys) and reflected that change by setting UsbGlobals.LIBUSB_SYS = "MyDevice.sys". With only MyDevice plugged in, as well as with a second libusb device using the libusb0 files plugged in, everything seems to work ok.

Do you foresee any problems with renaming libusb driver files for my device and telling LUDN to use that custom file rather than libusb0.sys/dll?

[Travis Robinson]

I think you have to do more than that. There are some other things to consider, like the device naming scheme (libusb0-0001, libusb-0002, etc), the install filter (if used).

The disadvantage of the stock libusb-win32 kernel driver is that there is to relationship between the usb devices and the windows registry. Libusb-win32 pulls everything directly from the usb device. This makes it difficult and unreliable to try and "guess which instance" when identical devices are connected and provides no real means to map WM_DEVICECHANGEs to the appropriate device.

I've submitted a feature request to the libusb-win32 page in attempt to get my kernel changes included.
In the meantime there will most likely be one more release that will fix several bugs and include support for the stock kernel driver if the modified kernel driver is not found, but obviously some restrictions will apply,

If they are unwilling then I suspect I'll take the same approach as you.

Regards,
Travis

[Travis Robinson]

The disadvantage of the stock libusb-win32 kernel driver is that there is
NO relationship between the usb devices and the windows registry.

[Pat Kujawa]

Thanks for clarifying. Good luck. If you need supporters to lobby the libusb-win32 team, let us know.