Windows 10 - clean out USB enumeration/driver cruft

Question

Summary

I'm developing firmware and a PC test application for a custom USB device, using the STM32F072 Discovery board. The device includes Microsoft Windows Compatible IDs (WCIDs) to enable automatic installation of the WinUSB driver on the PC.

The device is enumerated correctly on other Windows 10 hosts, but not on my Windows 10 development PC. My development PC had previously tried to enumerate the device when it had the same VID/PID combo, but with different descriptors/metadata. If I change the PID to some other number (new to my development PC), it does enumerate correctly.

Questions

1. How can I get this to work with my desired VID/PID combo on my development PC?
2. Is Windows caching USB metadata the cause of the failed enumeration on this one PC?
3. What are best practices on the (Windows) PC-side for testing/development of USB device firmware, during the stage when device descriptors and metadata are in flux? Is it possible to avoid chewing up PIDs just to avoid the Windows caching?

Details

Because of the way Windows caches USB descriptors and the like from previous enumerations, during firmware development, I was incrementing the device Product ID (PID) in the firmware after each time I made other changes, to ensure that Windows wasn't caching things from previous iterations of the descriptors, and messing up stuff that would otherwise work.

Now I've gotten the device to enumerate successfully on Windows 7, 8, and 10 PCs as a WinUSB device, and I've established communication. But when I change the firmware back to using the VID/PID that I started with, and then connect the device to my development PC, it shows up in Device Manager under "Other devices" with an error icon. I think this is because my (Windows 10) development PC previously had seen this VID/PID combo as having different descriptors, so it's getting confused by some bad cached stuff.

I've tried using regedit to delete the device's registry keys under HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_xxxx&PID_yyyy, but the problem persists. (Also, I get an error, because it can't delete the VID_xxxx&PID_yyyy\zzzzzzzzzzzzz\Properties subfolders.) I also tried using USBDeview to uninstall old iterations of the device, but that hasn't made a difference either.

Also of note is that I can no longer pass the device through to Virtual Box virtual machines. I'm not sure what happened there.

Solution 1

Try removing any relevant registry keys of the form:

HLKM\SYSTEM\CurrentControlSet\Control\UsbFlags\vvvvpppprrrrr

The MSDN article Microsoft OS Descriptors for USB Devices says:

The operating system creates a registry entry, named osvc, under this registry key that indicates whether the device supports Microsoft OS Descriptors. If the device does not provide a valid response the first time that the operating system queries it for a Microsoft OS String Descriptor, the operating system will make no further requests for that descriptor.

Solution 2

I know the OP has resolved his issues, but for future reference for anyone else having this problem: I had similar issues while developing a USB device with a vendor-specific class. Specifically, (similar to your experience) I was unable to delete the keys from:
HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_xxxx&PID_yyyy,
so I had to increment the PID every time I modified my device code.

The reason why these keys can't be deleted is that the Properties registry subfolder is owned by the System user, so even running as Administrator you can't delete this subfolder nor change its permissions.

Running Regedit via PsExec (which is part of the SysInternals suite from Mark Russinovich) from an elevated command prompt with: psexec -s -i regedit.exe runs regedit as System user, which means you can delete that pesky Properties subfolder and the parent VID_xxxx&PID_yyyy keys.

Solution 3

I'm confronted with the same issue and uninstalling the device did not help. Messing around with the registry makes me feel uneasy. I still don't see a real answer to question #3. What worked in my case: open device manager, select the non-working device and do "update driver". Select the driver manually from the list of locally available (Microsoft) drivers. This did not solve all my problems but at least Windows does not ignore my device anymore and I can continue developing.

EDIT: I found a very helpful description on a github project named WCID Devices by Pete Batard. I strongly recommend reading the section Implementation and the following on this page WCID Devices

Solution 4

there are tools for removing hidden traces of USB devices like USBOblivion http://www.thewindowsclub.com/usboblivion-remove-usb-traces-windows , USBDeview,...

sources of USBOblivion are here: https://sourceforge.net/projects/usboblivion/ (https://www.openhub.net/p/usboblivion)

http://www.techerator.com/2010/05/how-to-remove-hidden-duplicate-copies-of-usb-device-drivers-in-windows/

Solution 5

To Remove TrustedInstaller Owned Registry Keys

Unfortunately the old PsExec trick of running RegEdit doesn't always work. In that case try to use:

• ExecTI - Run as TrustedInstaller
  Run it to open the ExecTI GUI and enter: C:\Windows\regedit.exe

To repair file and registry permissions

You can also try using the very old tool: subinacl.exe
Example:
subinacl.exe /subkeyreg HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Enum\USB\VID_0000&PID_0002\

Further described here. And has been shown to still work on Win10.

View more solutions

Comments

[cp.engr]

This did not resolve my issue by itself, but the list of registry keys on the USBOblivion gave me hints on where to look for keys to delete, which led to me resolving the issue.

[cp.engr]

Besides that, I also deleted registry keys from HKLM\ControlSet001\Control\usbflags\vvvv* and HKU\.DEFAULT\Software\Microsoft\TelemetryClient\ThrottleStor‌​e\watson\generic\gen‌​eric\pnpdeviceproble‌​mcode\*vid_????* to get it to work. I'm not sure if both of those were required, though. Do you know about these? Also, any input on my question #3?

[David Grayson]

I'm glad you were able to get it to work. I don't know much about those other flags, except of course ControlSet001 is probably made from a copy of ControlSet. The pnpdeviceproblemcode stuff looks relevant to. I don't have too much to say for question #3: usually uninstalling all the relevant device nodes in the Windows Device Manager is enough to test your new descriptors (don't forget to uninstall any composite parent nodes for USB composite devices). But also remember to clear those registry keys if you have trouble.

[cp.engr]

Thanks. My issue is resolved for now (and I upvoted this answer), but I hesitate to accept it without something more formal (comprehensive list of registry keys, and Q#3) - which no one seems to be doing. Thoughts? Seem fair? Re Q#3, I feel like there ought to be a "disable descriptor caching" mode. Seems like not a lot of thought was given to this stage of device development.

[eric frazer]

@cp.engr - how about you share what you found out?

[cp.engr]

@ericfrazer, there never was a clear authoritative comprehensive answer. My findings are in comments here. It's been over a year, and I don't have this development environment handy anymore, so that's all I have to offer.

[not2qubit]

This method no longer seem to work: Resulting in: The handle is invalid. Error establishing communication with PsExec service on xxxx.

[not2qubit]

Apparently this happens when you have disabled SMB shares (which you should!) which is used by this prog AFAICT.

[Geoff S]

Did you run the command from an elevated command prompt (i.e. run as administrator...) ? Running from a regular command prompt results in an error Couldn't install PSEXESVC service: Access is denied.