How are device interface strings guaranteed to be unique?

  • Article

When you register a device interface GUID, you get back a symbolic link name which is the link representing the instance of the device interface.  The symbolic link that is returned has to be unique to your device, otherwise 2 devices sharing the same link would be quite confusing!  For instance, if we had the following scenario

  • A device interface GUID of {d35f7840-6a0c-11d2-b841-00c04fad5171}
  • A device instance path of WdfRawBusEnumTest\RawEnumerator\1&2d12bed1&0&Instance0.  Remember to treat a device instance path as an opaque string!

The instance path identifies the device's location in the device tree so it must be unique, otherwise 2 devices would share the same location and not be distinct.  The uniqueness of the device instance path is key to making the symbolic link name unique as well. 

When I create a device interface for this stack in my driver, the symbolic link name is "\??\WdfRawBusEnumTest#RawEnumerator#1&2d12bed1&0&Instance0#{d35f7840-6a0c-11d2-b841-00c04fad5171}".  This string should also be treated as opaque, but we'll break it apart just to figure out how it is unique.  You can see that there are 3 parts to the string

  1. \?? - the base directory in the object manager in which the rest of the symbolic link name exists.  A couple of other base directories are \Device and \Driver.
  2. \WdfRawBusEnumTest#RawEnumerator#1&2d12bed1&0&Instance0# - the device instance path with all of the internal \'s converted to #'s.
  3. {d35f7840-6a0c-11d2-b841-00c04fad5171} - the device interface GUID

I will ignore the first part because it is not relevant to why the string is unique.  By using the device instance path, a unique identifier in the pnp tree, as the root for the symbolic link name, the pnp manager guarantees that the generated link name is also unique.  The GUID is also important because there can be mulitple device interfaces associated with a single device stack, so the pnp manager must be able to distinguish between each interface on the device stack when the interface state changes.

Tomorrow's entry will talk about the implications of using the device instance path as the basis of a unique identifier and how this abstraction leaks back to the driver writer.