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.

Answer 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.

Answer 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.

Answer 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