I’m currently working on a driver for an USB device.
As the new USB-H/W is not available yet I use the OSR FX2 board as a substitute
and I’ve put the VID/PID my .inf file.
My problem is:
When the debug target system reboots, the driver is loaded and unloaded
(DriverEntry, DeviceAdd und ContextCleanup) even though no
USB device is connected yet.
Any idea what I did wrong?
A 2nd related question: Having an exception (sxe ld MyDriver) in place I wonder
if it’s possible to get the name of it?
Of course I know the name but in case I have enabled multiple exceptions I’d
like to know if it’s possible to find out the actual module loaded?
PS: There was no driver installed for the OSRFX2 before.
Exactly how did you install your driver? 99% of the time, this is caused by the developer using devcon install to install their driver package. That is never what you want. That creates a new, fake device with the name matched by your INF – a fake, virtual device that is not associated with any hardware.
Regarding sxe ld, if you look through the stack, you can find a pointer to the driver name. It isn’t obvious.
I’m curious what kind of USB device it is. Since you are writing a driver I am assuming the device does not look like any of the standard USB device classes.
Since it does not look like normal device classes, is it only used by one application that you’re writing? If so, consider not writing a driver at all and just make the correct USB descriptor that cause it to automatically get hooked up as a WinUSB device. Your application can then find the device by guid and open the USB pipes and talk to the device, no OS kernel driver development needed, your “driver” is just part of the application.
There are devices that are not exactly a standard class and also need more than a dedicated application to use, and you want your device to be usable from arbitrary applications that expect a certain kind of device. Those are the ones that will require a full custom driver.
My suggestion also is that since you don’t have the device yet, consider just making a suitable development virtual device in QEMU that behaves somewhat like the real device, and do your development there for a while. A big plus of a virtual device is you can force it to have all kind of error conditions that your real device may occasionally have but are difficult/almost impossible to reproduce on demand for real hardware. Real hardware also often does not work exactly like the specifications claim, and if you can prove the real device is not behaving like a virtual device that does conform to the specifications it makes it much easier to determine if an issue is your driver, or the device, or it’s firmware. Writing a simple simulation of a device often helps you the driver developer understand the device really well. The simulation also generally does not need to be perfect to be extremely useful. Hardware people (and management) are also usually impressed when they delivery the hardware and you already have a very functional driver running.
Thanks for your suggestions. Without going into project details WinUSB is not an option
in our use-case for several reasons.
We already have a several native WDM drivers with a specific interface
for different old variants of the hardware and are now redesigning the hardware. (Refresh)
Changing several concurrently running of user-mode softwares to use a completely
different access model/interface would pose much more risk to the project.
Apart from that: Simulation is exactly what I want to do as long as the correct H/W is not available… but with a real USB device which I can connect and disconnect. I already did it with a
ROOT enumerated driver and my problems seems to be caused by
carelessly switching over and not reading documentation completely.
