LibUsbDotNet C# Usb Library

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

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

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

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?

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

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.

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.