Replace USB Driver with my own

I would like to replace a USB driver bound to a device attached to a windows system with my own driver.

I have investigated different techniques to do this. I tried the SetupDi… api to change the HARDWARE_ID of the device to my own hardware id (not possible to Set this property). I also tried writing a filter to catch the QUERY_ID messages and rewrite to my own ID. Seemed overly complicated and flakey.

However it seems i do not need a filter driver at all because for example i notice vmware doesnt use a filter to capture a USB device for passthrough. It somehow reenumerates the device and sets its Hardware ID to the VMWARE USB hardware id and that then binds to their own driver like normal

Any tips on how to implement usb device capture like vmware does it?

xxxxx@gmail.com wrote:

I would like to replace a USB driver bound to a device attached to a windows system with my own driver.

I have investigated different techniques to do this. I tried the SetupDi… api to change the HARDWARE_ID of the device to my own hardware id (not possible to Set this property). I also tried writing a filter to catch the QUERY_ID messages and rewrite to my own ID. Seemed overly complicated and flakey.

No such machinations are necessary. Just write your own INF file
matching the current hardware ID. Then you can use Update Driver
Software from Device Manager, or “devcon update”, to make your driver
the current one.

However it seems i do not need a filter driver at all because for example i notice vmware doesnt use a filter to capture a USB device for passthrough. It somehow reenumerates the device and sets its Hardware ID to the VMWARE USB hardware id and that then binds to their own driver like normal

Any tips on how to implement usb device capture like vmware does it?

VMWare has hooks throughout the system. I would guess they are using
filter drivers on the USB host controller or hub driver to redirect things.

I would point out that VirtualBox is open source. You can go look at
how they did it.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

No this does not work because when you update the inf file to match the target, that driver will become the preferred for that sort of device from then on.

I would have suspected a filter driver would be listed in the UpperFilters or LowerFilters registry entries for the USB Host controller, however no such entries are there.

Virutalbox is not open source regarding USB capture, qemu doesnt support windows capture and vmware is closed source, hence its a secret sauce :slight_smile: There are other products out there that just use filter drivers for this but i feel this is not optimial.

Ideally the way i want it to work is to have a generic usb driver that is registered with a specific hardware id. I reenumerate the port while changing the hardware id while removing compat ids and of the device and my driver is bound automatically at that point.

There is an opensource product called usbdk that basically hacks the pnp events to capture the device. Reading carefully though MSDN docs the way they do it is not reliable because they are hiding/pasisng some pnp IRPs that will disrtupt the internal pnp statemachine. From my testing it locks the windows pnp system quite regularly

Michael B wrote:

Ideally the way i want it to work is to have a generic usb
driver that is registered with a specific hardware id. I
reenumerate the port while changing the hardware id while
removing compat ids and of the device and my driver is bound
automatically at that point.

I think you need a bus filter on usbhub for this. However as Doron would say “the device graph can be arbitrarily complex” because of actual and embedded hubs and you won’t know which PDO’s should have their hardware ID’s rewritten.

On Mar 7, 2016, at 3:34 PM, xxxxx@gmail.com wrote:

No this does not work because when you update the inf file to match the target, that driver will become the preferred for that sort of device from then on.

Yes. If you want specific advice, then you had better be more specific about your requirements and limitations. At this point, you’re assuming we can read your mind.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.