3

When WMI is queried and returns a list of devices, I've noted some information at the END of the DeviceID string that isn't documented anywhere I've looked so far. Here's an example of a DeviceID string returned from a WMI query looking at Win32_PnPEntity:

USB\VID_046D&PID_082D&MI_00\7&3538A2BF&0&0000

Now, the first two parts - both the 'USB' and the VID and PID are really well documented, as is the 'interface number' - the &MI_XX. However, the last part of the string (shown below) isn't documented anywhere I've looked. I don't even know what to call this part of the DeviceID string:

\7&3538A2BF&0&0000

Curiously, it comes in several flavors. I've noted that if I have two identical devices plugged into the PC, I'll get different values, which I've defaulted to calling 'instance id's' for lack of better documented reference info. Here's what I see when I have two identical USB Web cameras plugged into my PC:

USB\VID_046D&PID_082D&MI_00\6&DB509D0&0&0000 USB\VID_046D&PID_082D&MI_00\7&3538A2BF&0&0000

So far, so good. I can pick out that I have two identical devices plugged into the PC and can parse against these unique values. But wait! When the OS sees these devices, it also loads anything the drivers offers for different 'interfaces' or modes of operation, so along with the above entries when I make a WMI query against Win32_PnPEntity, I also get these nice entries in the DeviceID field as well:

USB\VID_046D&PID_082D\195825EF

USB\VID_046D&PID_082D\36149BBF

So the problem is that without documentation that describes what this last part of the DeviceID is, I don't know to expect, and can't associate or separate these 'duplicate' entries from their brethren in the query results.

The goal is to be able to scan through the WMI result, identify ONE 'primary' entry for a given device and discard anything else. I could likely HACK the filtering by looking for "USB Composite Device" in the Description field, but this is rather ugly and would discard some devices that do not have an appropriate or vendor-specified 'description.'

MSDN only provides that the DeviceID is a "Unique identifier of the USB controller. This property is inherited from CIM_LogicalDevice." -- and CIM_LogicalDevice doesn't detail the makeup of this field either.

Anyone been down this path or know which hole to look in? Similar questions in here and in other forums remain unanswered. (Hey M$, Why is this so %$@#! mystical???)

Redgum
  • 388
  • 5
  • 14

1 Answers1

3

It looks like this webcam is a composite device.

I think the node with the ID of USB\VID_046D&PID_082D\36149BBF is the parent device. The part after the second slash in this case is most likely the serial number of the device. (I have made Windows software for composite devices for years and we always get the serial number by parsing that part). This node probably uses usbccgp.sys as the driver, which allows it to parse the interface descriptors of the device and produce child nodes.

The node with ID USB\VID_046D&PID_082D&MI_00\6&DB509D0&0&0000 is the child node corresponding to USB interface 0. From my experience, I believe that the part after the second slash is some kind of unique identifier that depends on what USB port the device is plugged in to.

For the WMI query, you should probably just ignore the child nodes altogether. Just discard anything with MI_ in it before the second slash. The parent node tells you everything you need to know about the identity of the device.

David Grayson
  • 84,103
  • 24
  • 152
  • 189
  • 1
    I did finally figure it out by looking at the Registry under HKLM\System\CurrentControlSet\Enum\USB and matching up the ID's. Interestingly, I found by trial and error that you are correct - that's the SERIAL NUMBER of the device, despite what (in this case Logitech) told me to the contrary. That value is persisted across different computers. Thanks for the note - I have successfully written the necessary code to weed out the secondary entries by evaluating what's stored in the registry. Would have been so much cleaner if WMI could filter it. Thanks Dave! – Redgum Jun 10 '14 at 19:23
  • I am about to start working with USB interfaces, so started researching. Came across [this](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/standard-usb-identifiers). Looks like it clarifies the issue. The docs call the last component formally *revision* code, instead of serial number. – Veverke Aug 27 '20 at 08:40
  • @Veverke nice to see they finally documented it. Thank you for the follow-up link! – Redgum Dec 03 '21 at 05:34