how to parse USB Device Instance ID (DIID)?

Question

I want to know how "Device Instance ID" is made or how to parse it.

Take the following string as an example:

USB\VID_093A&PID_2700&MI_00\6&2703A67B&0&0000

As per my knowledge:

• USB tells that this is a USB device
• VID_093A indicates its vendor ID
• similarly, PID_2700 is the product ID

However, I don't know about the rest.

Answer 1

Well, you really cant. This is the response from Microsoft regarding the same..

the device instance ID should be treated as opaque. if you want the VID/PID, query for the hardware and/or compa IDs and parse those. the hardware IDs are not considered opaque (but you still have to assume new hardware IDs will show up, so you need to detect the pattern you want to parse and have proactive code that handles other types of formats).

source: http://social.msdn.microsoft.com/Forums/en-US/4ff692bc-97c9-4943-b1ee-ec4f098e3b14/how-to-detect-sim-card-change-or-imsi-change-programatically-in-windows-phone-8?forum=wpdevelop

Answer 2

MI is for multiple interfaces. A composite device has several interfaces.

6&2703A67B&0&0000 is the Instance ID.

The 6 at the beginning corresponds to the device node depth.

• 0 are root devices (e.g. volmgr, acpi_hal, they have Root\ prefix)
• 1 are acpi_hal devices (e.g. acpi (uses PNP0C08\0 instead of vid/pid/1), they have ACPI_HAL\ prefix)
• 2 are acpi devices (e.g. root pci bus controller (uses PNP0A08\0 instead of vid/pid/2), they have ACPI\ prefix)
• 3 are pci devices (e.g. xhci controller, they have PCI\ prefix)
• 4 are xhci devices (e.g. root hub, they have IUSB3\ prefix)
• 5+ are hub devices (e.g. usbccgp FDOs for composite devices, ubstor for storage etc., they have USB\ prefix)
• 6+ are usbstor devices (disk FDOs, USBSTOR\ prefix) or usbccgp composite interfaces (e.g. hidusb FDOs for input devices, USB\ prefix and have an MI)
• 7+ are endpoints (kbdhid FDOs for keyboards, mouhid FDOs for mice, HID\ prefix and have an MI)

The ID 2703A67B is an ID assigned by the parent. The xhci controller assigns the same one to all its root hubs; the separate hubs are identified by the value after the final ampersand, which is a simple incremental value. The root hub gives its child devices an ID that is the same across all devices and reboots; the separate devices are identified by the value after the final ampersand, again an incremental value. A composite device gives its children an ID that changes based on what hub/port it is plugged into; the separate interfaces are identified by the value after the final ampersand. An interface gives its children endpoints an ID that changes based on what hub/port it is plugged into; the separate endpoints are identified by the value after the final ampersand.

I can confirm that the ID that a hub assigns to its children changes if the hub is plugged into a different port on the root hub or a different hub altogether. I wrote '+' to indicate the presence of possible nested hubs. The PCI bus could also be nested and have a child bus (via PCIe to PCI bridge or PCIe root port aka. a PCIe to PCIe bridge), but I decided to leave that out. A root port is just a PCI device, basically a bridge/controller to a bus with only one slot (or more slots if the lanes are configured on the port to be split up), with a PCI\ prefix, and the child device will also have a PCI\ prefix.

By that token, the ID that the xHCI controller assigns probably depends on the PCI slot, and the ID the PCI bus controller assigns is probably dependent on what port the subordinate bus controller is connected to or whether it is the root controller.

This is why it installs drivers again when you insert a device into another port (unless it has a serial number). The drivers are considered installed when there is a registry entry for the DIID. The USB device will have a separate entry for each port and root hub combination they're plugged into. The composite device interfaces will have a separate entry for each port and root hub as well, as will the endpoints.

If the device has a serial number, which is uncommon, then the instance ID will be the serial number, and this will be the same regardless of where it is plugged into the system. If a composite device has a serial number instance ID then its interfaces probably have the same instance ID as that because the MI in the Device ID tells them apart. The endpoints are unlikely to have their own serial numbers and probably use the regular instance ID scheme.

Answer 3

The Microsoft Device Instance ID page explains well how a Device Instance ID string is composed.

This page explains how a USB Identifier string (which composes the Device ID part of a Device Instance ID) is created.

Specifically, for your example:

• USB\VID_093A&PID_2700&MI_00 is the Device ID, and
• 6&2703A67B&0&0000 is the Instance ID

Moreover, the Device ID tells you that:

• USB\: this is a device under the USB enumerator
• VID_093A: Pixart, Inc. manufactured this USB Device (you can find the USB Vendor ID list here)
• PID_2700: this is the Product ID
• MI_00: This is a Multiple Interface USB Device