winusb driver DeviceInterfaceGUID missing

I have a USB device that use winusb. During use, sometimes, the device cannot be enumerated in win10 , and I found that the DeviceInterfaceGUID in the registry was missing,I don’t know why?

Is the device communication abnormal, causing the registry information to change?

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_2BC5&PID_0635&MI_00\6&32888da8&0&0000\Device Parameters。

At this time, I uninstalled the driver in the windows device manager, then refreshed it, and the DeviceInterfaceGUID in the registry is ok .

Is the device interface guid defined in your Extended Properties OS Feature Descriptor or set by the INF?

@Doron_Holan said:
Is the device interface guid defined in your Extended Properties OS Feature Descriptor or set by the INF?

yes, the device interface guid is defined in your Extended Properties OS Feature Descriptor。

When this occurs, are there any uninstall or new device enumerations in setupapi.dev.log outside of your manual actions in device manager?

What is the error code when you encounter enumeration issue? Does it become an unknow device? Or Code 10 error? Or other errors?

Could it be a FW timing issue that it sometimes fail to respond to Windows request of String Descriptor Request to Index 0xEE?https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-defined-usb-descriptors

Ref:
https://techcommunity.microsoft.com/t5/microsoft-usb-blog/how-does-usb-stack-enumerate-a-device/ba-p/270685

1 Like

@Doron_Holan said:
When this occurs, are there any uninstall or new device enumerations in setupapi.dev.log outside of your manual actions in device manager?

No,when this occurs, windows device manager looks ok,but in regedit ,the deviceInterfaceGuid is deleted.

This problem is occur. When our device is switched from win10 to vmware ubuntu 20.04, and then run the application, after switching back to win10, an exception occurs。

Hmmm … you say that the problem occurs when you “switch” the device and “switch” back, exactly what does that mean? Does that mean you physically unplug and replug the device, or use the USB redirect functionality in WMWare to change the connection between physical host and VM “host” and back?

@Xiaofan_Chen said:
What is the error code when you encounter enumeration issue? Does it become an unknow device? Or Code 10 error? Or other errors?

Could it be a FW timing issue that it sometimes fail to respond to Windows request of String Descriptor Request to Index 0xEE?https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-defined-usb-descriptors

Ref:
https://techcommunity.microsoft.com/t5/microsoft-usb-blog/how-does-usb-stack-enumerate-a-device/ba-p/270685

No,windows device manager looks ok,but in regedit ,the deviceInterfaceGuid is deleted.

In this case, hot plugging does not solve the problem。 I use usb logic analyzer found that only when the driver was uninstalled and then refreshed, it would trigger the reading of the OS descriptor

@craig_howard said:
Hmmm … you say that the problem occurs when you “switch” the device and “switch” back, exactly what does that mean? Does that mean you physically unplug and replug the device, or use the USB redirect functionality in WMWare to change the connection between physical host and VM “host” and back?

I use the USB redirect functionality in WMWare to change the connection between physical host and VM “host” and back.

maybe this occur when the fireware control transfer abnormal, but I don’t known why the regedit deleete the deviceInterfaceGuid.

It all depends on what VMWare is doing, but I’m guessing that WMWare is essentially doing a Zadig style in place removal and reinstall of the driver, removing the installed driver, triggering a PnP renumeration to inform the OS and directing the VID/PID to a VMWare tunnel driver (which is then installed in the VM) and then reversing that operation. To the OS, that’s simply an uninstall of the driver … and part of the uninstall process would be to remove any vestiges in the registry …

The problem (likely) is that the OS gets the GUID from the WCID string on initial device numeration and uses that to populate the registry, like is happening when you use DeviceManager to reinstall the driver in your first post … but that’s not happening here, the OS is not doing any numeration … it’s VMWare that is applying the registry fixups and again triggering a PnP renumeration. Since the device has already been “discovered” the OS will not read the WCID descriptor and never reload the GUID. WMWare is apparently unaware/ unwilling to detect and replace the device interface GUID in the registry, so …

A way to check this is to use USBTreeView on the target device before you do the “switch” and look at DeviceManager to see where it is. Do the “switch” and again examine USBTreeView to see if you see that device in the tree, then check DeviceManager to see if it’s there … I’m guessing that it’s gone in both places. Reverse the “switch” and you’ll see both reappear

… that is that …

@craig_howard said:
It all depends on what VMWare is doing, but I’m guessing that WMWare is essentially doing a Zadig style in place removal and reinstall of the driver, removing the installed driver, triggering a PnP renumeration to inform the OS and directing the VID/PID to a VMWare tunnel driver (which is then installed in the VM) and then reversing that operation. To the OS, that’s simply an uninstall of the driver … and part of the uninstall process would be to remove any vestiges in the registry …

The problem (likely) is that the OS gets the GUID from the WCID string on initial device numeration and uses that to populate the registry, like is happening when you use DeviceManager to reinstall the driver in your first post … but that’s not happening here, the OS is not doing any numeration … it’s VMWare that is applying the registry fixups and again triggering a PnP renumeration. Since the device has already been “discovered” the OS will not read the WCID descriptor and never reload the GUID. WMWare is apparently unaware/ unwilling to detect and replace the device interface GUID in the registry, so …

A way to check this is to use USBTreeView on the target device before you do the “switch” and look at DeviceManager to see where it is. Do the “switch” and again examine USBTreeView to see if you see that device in the tree, then check DeviceManager to see if it’s there … I’m guessing that it’s gone in both places. Reverse the “switch” and you’ll see both reappear

… that is that …

hi,craig_howard,thank you for you reply.

Usually we don’t use vmware when we use our device. In this case, the probability of this issue is very low. But I found that using vmware and win10 switch, this problem is inevitable, so I have been simulating and testing things like this.

What I don’t understand is that when an exception occurs, the contents of the registry are only deviceInterfaceguid missing, and other contents are normal. And In this case, hot plugging does not solve the problem.

@hong_zhong said:
What I don’t understand is that when an exception occurs, the contents of the registry are only deviceInterfaceguid missing, and other contents are normal. And In this case, hot plugging does not solve the problem.

It’s blindingly simple, really … and if you want to see it “play by play” then bring up ProcessMonitor and monitor for registry changes …

VMWare has a list of registry entries that are associated with a USB device, call them A, B, C and D and they go in locations 1, 2, 3 and 4. Those are registry entries that the OS uses to determine if a USB device is “there” or not. If the OS sees A, B, C and D at locations 1, 2, 3 and 4 then you have something in the device manager, if not then you don’t. The OS normally writes those entries when the driver is installed, and it also checks ONLY ON DRIVER LOAD (this is a key point, please reread those four words, repeat them to yourself, tell them to your spouse, sing them to your children, write them on your forearm) for a device interface GUID in the WCID extended descriptor. If it finds that GUID then it will write E at location 5 (which happens to be your GUID)

When WMWare does the “switch” it knows about A, B, C and D and stores them off, then removes them from the registry; they are gone. WMWare triggers a PnP renumeration (same as you do if you RClick on the top of the Device Manager tree and press “scan for new hardware”), the OS notices that A and B are now gone and removes the driver from PnP, same as if you had pressed “uninstall driver/ all” from the menu. The OS cleans up C, D and E. WMWare adds the VID/ PID of your device to it’s little tunnel driver (max of two devices, unfortunately), adds A and B to the target VM and triggers a renumeration; the target VM OS installs the driver (remember that little song? check your forearm …) and adds the GUID E to the registry.

Now it’s time for the switch back; VMWare removes A, B, C and D from the target VM OS and triggers a renumeration (removing that device), adds A, B, C and D to the host OS and again triggers a renumeration; the OS “sees” the device and it’s back in the Device Manager. Here’s the key point: VMWare knows absolutely nothing about E, the GUID. Not a bit, and won’t ever copy it … so when the OS cleans up after the first switch, that GUID is gone. Ask your spouse, what is the only time when that GUID ‘E’ will be read by the OS and written to the registry? If your children tell you “when the driver is loaded” then you know why after a “switch” the GUID is gone and only A, B, C and D remain … and if you check your forearm you’ll know why hot plugging won’t work either …

Again, bring up ProcessMonitor on the host and target VM, have it monitor for registry changes and you can see the action unfold …

@craig_howard said:

@hong_zhong said:
What I don’t understand is that when an exception occurs, the contents of the registry are only deviceInterfaceguid missing, and other contents are normal. And In this case, hot plugging does not solve the problem.

It’s blindingly simple, really … and if you want to see it “play by play” then bring up ProcessMonitor and monitor for registry changes …

VMWare has a list of registry entries that are associated with a USB device, call them A, B, C and D and they go in locations 1, 2, 3 and 4. Those are registry entries that the OS uses to determine if a USB device is “there” or not. If the OS sees A, B, C and D at locations 1, 2, 3 and 4 then you have something in the device manager, if not then you don’t. The OS normally writes those entries when the driver is installed, and it also checks ONLY ON DRIVER LOAD (this is a key point, please reread those four words, repeat them to yourself, tell them to your spouse, sing them to your children, write them on your forearm) for a device interface GUID in the WCID extended descriptor. If it finds that GUID then it will write E at location 5 (which happens to be your GUID)

When WMWare does the “switch” it knows about A, B, C and D and stores them off, then removes them from the registry; they are gone. WMWare triggers a PnP renumeration (same as you do if you RClick on the top of the Device Manager tree and press “scan for new hardware”), the OS notices that A and B are now gone and removes the driver from PnP, same as if you had pressed “uninstall driver/ all” from the menu. The OS cleans up C, D and E. WMWare adds the VID/ PID of your device to it’s little tunnel driver (max of two devices, unfortunately), adds A and B to the target VM and triggers a renumeration; the target VM OS installs the driver (remember that little song? check your forearm …) and adds the GUID E to the registry.

Now it’s time for the switch back; VMWare removes A, B, C and D from the target VM OS and triggers a renumeration (removing that device), adds A, B, C and D to the host OS and again triggers a renumeration; the OS “sees” the device and it’s back in the Device Manager. Here’s the key point: VMWare knows absolutely nothing about E, the GUID. Not a bit, and won’t ever copy it … so when the OS cleans up after the first switch, that GUID is gone. Ask your spouse, what is the only time when that GUID ‘E’ will be read by the OS and written to the registry? If your children tell you “when the driver is loaded” then you know why after a “switch” the GUID is gone and only A, B, C and D remain … and if you check your forearm you’ll know why hot plugging won’t work either …

Again, bring up ProcessMonitor on the host and target VM, have it monitor for registry changes and you can see the action unfold …

thank you ,I will use ProcessMonitor to check it.

@Xiaofan_Chen said:
What is the error code when you encounter enumeration issue? Does it become an unknow device? Or Code 10 error? Or other errors?

Could it be a FW timing issue that it sometimes fail to respond to Windows request of String Descriptor Request to Index 0xEE?https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-defined-usb-descriptors

Ref:
https://techcommunity.microsoft.com/t5/microsoft-usb-blog/how-does-usb-stack-enumerate-a-device/ba-p/270685

No,windows device manager looks ok,but in regedit ,the deviceInterfaceGuid is deleted.

In this case, hot plugging does not solve the problem。 I use usb logic analyzer found ,only when the driver was uninstalled and then refreshed in windows10 device manager, it would trigger the reading of the OS descriptor。