On Thu, Aug 18, 2016 at 11:07 AM, Hermann Hamann wrote: > <What do you mean by private directory of some other device? > > If it helps you: > > C:\Program Files\RTLSDR Scanner>dir lib*.* > 12.04.2013 20:04 68.608 libusb-1.0.dll
Probably "C:\Program Files\RTLSDR Scanner" is in the global %PATH%, so it is not so "private". > < Why it crashed? > I don't know. I believe the crash probably happened when libusb1 accessed the device through the libusb0.sys driver (which in theory could work but the different drivers have their subtleties). libusb1 might have worked better if it could access the device through the WinUSB driver. Since the libusb-win32 library / libusb0 driver combination seems to work you have likely encountered a bug in the libusb1/libusb0.sys combination. It would be nice if you can file a bug and supply more detail, if not to get the bug fixed, at least warn others about the issue. > <If you want to use libusb-1.0 backend, you need to have libusb-1.0.dll in > <the system and better use WinUSB driver for your device. > > I want the backend that is in the registry. pyusb by default looks for libusb1 first, using the path, like how most applications loads DLLs. If you have the libusb1 DLL installed in the path but don't want to have it selected, you must select backend explicitly. I suppose libusb1 (somewhere through the Windows API layers) uses the registry to know which driver to use. It is however not obvious how pyusb should interpret the registry to choose its backend library. Flexibility comes at a cost. For instance, libusb-win32 ships both a library (DLL) and a driver (SYS) and the former always uses the latter to access the device, whereas libusb1 is just a library and can use various drivers (WinUSB, HID, libusb0.sys, libusbK) to access the device. The Windows driver registry will point to which driver is in charge of a device, and the application must perform requests to this driver, but the application (or developer) must itself select its libraries. And the pyusb application currently uses a DLL search to select default library backend, regardless of the device. If libusb1 would only support WinUSB, and we had a strict driver<->libusb relation, heuristics based on the registered driver could make more sense. Add more possible backends and drivers, try to make things consistent across platforms, and it all becomes more complex. Hermann, in your case you are probably better off selecting the libusb0 backend in your python application, if you know that your device requires libusb0.sys. Otherwise, register the device for WinUSB (with .inf file or Zadig), make sure a known good libusb1.dll is installed in the path (before any third party libusb1.dll) and select the libusb1 backend in your python application for good measure. BTW, Hermann's example patch hardcodes "ControlSet002" which I believe should be "CurrentControlSet", unless there are better ways to find the "Service" associated with a device. I also think device instances (e.g. different serial numbers but same vid/pid) can have different Service values, and I am not sure how the patch deals with that. Regards, Tormod ------------------------------------------------------------------------------ _______________________________________________ pyusb-users mailing list pyusb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pyusb-users
