{"id":514,"date":"2023-06-06T15:53:49","date_gmt":"2023-06-06T22:53:49","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/windows-music-dev\/?p=514"},"modified":"2023-06-06T15:53:49","modified_gmt":"2023-06-06T22:53:49","slug":"the-importance-of-including-a-unique-iserialnumber-in-your-usb-midi-devices","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/windows-music-dev\/the-importance-of-including-a-unique-iserialnumber-in-your-usb-midi-devices\/","title":{"rendered":"The importance of including a unique iSerialNumber in your USB MIDI Devices"},"content":{"rendered":"

The importance of including a unique iSerialNumber in your USB MIDI Devices<\/h2>\n

Uniquely identifying connected devices is something all operating systems must do in order to function. But persistently identifying them, across moves, reboots, and more, can be more challenging. This post covers why this topic is so important to Windows MIDI Services and what manufacturers and customers can expect to see in Windows MIDI Services.<\/p>\n

\n

Please note that the scope of this post is just USB MIDI devices. Other devices, like storage, have different requirements and different approaches to identification.<\/p>\n<\/blockquote>\n

TLDR; Please provide a valid and unique iSerialNumber<\/code> string descriptor for your USB devices. If you cannot provide that value, do not provide any string descriptor for that (set the iSerialNumber<\/code> field value to 0x00<\/code> so it does not point to any string descriptor). If you want to learn more, please read on.<\/p>\n

\n

Note: When I mention the iSerialNumber<\/code> field in the rest of this post, I’m generally referring to the string descriptor the iSerialNumber<\/code> field points to.<\/p>\n<\/blockquote>\n

How Windows identifies USB devices<\/h2>\n

Have you ever noticed that when you unplug a device from one USB port, and then plug it into a different USB port, you’ll sometimes see it pop up as a new device, and maybe even get a driver installed?<\/strong><\/p>\n

That can happen when a USB device doesn’t include the iSerialNumber<\/code> field, and you plug it into a port which shows up as a different parent device, impacting the calculated unique id for that USB device. When a device doesn’t include an iSerialNumber<\/code>, operating systems use various techniques to uniquely identify the device, as best as they can.<\/p>\n

\n

Although implementations vary, this process isn’t unique to Windows. macOS, Linux, and other operating systems have similar algorithms to try to smartly identify a device in the absence of a serial number. They also have similar limitations.<\/p>\n<\/blockquote>\n

Here are some low-level details about how devices are uniquely identified in Windows. This is quoted from our MS Learn docs (links below):<\/p>\n

\n

… For BusQueryInstanceID, a bus driver should supply a string that contains the instance ID for the device. Setup and bus drivers use the instance ID, with other information, to differentiate between two identical devices on the computer. The instance ID is either unique across the whole computer or just unique on the device’s parent bus.<\/p>\n

If an instance ID is only unique on the bus, the bus driver specifies that string for BusQueryInstanceID<\/code> but also specifies a UniqueID<\/code> value of FALSE in response to an IRP_MN_QUERY_CAPABILITIES<\/code> request for the device. If UniqueID<\/code> is FALSE, the PnP manager enhances the instance ID by adding information about the device’s parent and thus makes the ID unique on the computer. In this case the bus driver should not take extra steps to make its devices’ instance IDs globally unique; just return the appropriate capabilities information and the operating system takes care of it.<\/p>\n

If a bus driver can supply a globally unique ID for each child device, such as a serial number, the bus driver specifies those strings for BusQueryInstanceID<\/code> and specifies a UniqueID<\/code> value of TRUE in response to an IRP_MN_QUERY_CAPABILITIES<\/code> request for each device. …<\/p>\n<\/blockquote>\n

So you can see in the above description, that if an iSerialNumber<\/code> is not supplied, Windows will use the device’s parent information as part of the differentiator to uniquely identify the device. If a device is moved to a new parent (plugged into a different port, plugged into a USB hub, etc.), that id changes and the device appears as a new device. Any link to its past is effectively lost.<\/strong><\/p>\n

Just as a reminder, storage and some other device classes have additional mechanisms for unique identification (a storage device can, well, store a supplied id). We’re talking about MIDI devices here.<\/p>\n

References<\/p>\n