I wonder if anyone can help at all, this is a specialist problem.
I have an application that needs to read and analyze several USB devices (not at the same time, each of them runs in separate tests and can theoretically be run on different machines).
Each of the USB devices is based on the USB HID class and is manufactured by different companies, none of these USB devices is designed to work on a PC, but is designed for a different platform, however, for the purpose of testing the device that the client requested that the test application be launched from PC.
Some of the devices will start, will be recognized by windows that will initialize and start them correctly, using the universal HID class driver built into the windows, after which the devices will start sending the correct data packets of the checked data.
Some of the devices will start, they will be recognized by windows that try to start them, but will not be able to fully initialize them, leaving them in a state with half initialization. This is normal, since I can use the beagle protocol analyzer to capture initialization packets from a genuine platform, and then use the LibUSBDotNet library to replicate the remaining packets in the initialization sequence and get them to start sending packets correctly.
I have a problem with one specific device (although there are still some of them that I have not tested yet, so it is quite possible that one of them may also have the same problem). The problem is that the Windows HID class driver recognizes the device and tries to initialize it and start it, it works after the mod, and the device starts sending data.
The problem is that the data sent is different from that sent to the genuine platform (containing only a subset of the complete data). As if the windows initialized the device in a different mode.
When I take initialization packets from both a PC and a genuine platform using my USB protocol analyzer, I see that Windows sends a few slightly different initialization packets. Using LibUSBDotNet to resend the correct packages after Windows has already started the device seems to have no effect.
My problem is that I need windows to not try to initialize the device using the standard driver of the HID class, I tried to remove the driver in the device manager, but it still initializes it (and the driver is reassigned by the driver in the device manager). I did some investigation, and there are alternatives:
Create a specific driver whose windows will be assigned to a specific VID / PID of the device, but it does nothing, then I can use LibUSBDotNet to send the correct initialization sequence to the device from my own code.
Use something like WinUSB to create the correct driver for the device (or, possibly, to create a dead driver, such as 1.
Will a driver with a specific VID / PID be used by windows, preferring its built-in USB HID class driver? If not, will I spend my time on this route?
Please note: my mac correctly initializes the problem device, and I asked if the application could be developed for Mac, and their answer was disappointing only Windows.
I have no experience writing the right Windows drivers, although I have a relatively low level of experience with USB (so the part is not too worried). Can anyone suggest a good course of action (before I spend a lot of time learning how to write drivers for a PC just to find that my chosen course of action cannot do what I need).
Any help or suggestion is greatly appreciated.
Thanks Rich
Added after trying the sentences below:
I tried to use the LibUsbDotNet wizard to create the necessary files and install them, and it seemed to work - of course, the device now appeared in the Device Manager as a libusb-win32 device - not a HID device, but the libusb driver associated with it, Even after Of this, the device still starts initializing and starts sending incorrect types of data packets, although now these packets are no longer processed by the class driver and simply get lost.
I also stumbled upon Zadig, which has a similar create creation wizard for WinUSB, and it has exactly the same result.
A colleague suggested that this cannot be the window itself, which switches the device to this mode, and the device identifies that it is connected to the Windows machine and switches to this mode. I suspect this is the case, and in this case Iām stuck - time to have another conversation with the client.
Many thanks for the help.