Registry Keys for USB Device Drivers

Registry keys control how USB device drivers are loaded. When a USB device is attached, a USBD module loads the appropriate USBD to control that device, based on the device’s configuration and interface descriptor information. The USBD module locates the correct driver by using a set of registry keys, which tracks both the drivers and the devices. The registry keys are stored as subkeys of the HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\. registry key

This loading method provides a flexible framework that allows drivers to be loaded in different contexts, depending on the range of devices that they are able to control. For example, OEMs may decide to include a generic class driver with their Windows CE–based platform that can control a broad range of USB devices. However, an IHV may have a driver for the a specific USB device within that class that is more efficient or works better than the generic class driver. In this case, the IHV’s driver could control a subset of the devices that the generic class driver controls, while allowing other devices to continue to be controlled by the generic driver. The structure of the LoadClients key defines a framework in which programmers can specify driver precedence in great detail. The following are examples of the contexts that can cause specific USB device drivers to be loaded:

To match every device connected to the bus. For example, a driver that displays an icon in the system’s taskbar can be loaded to control each USB device connected to the system. In this case, the driver could purposely fail the USBDeviceAttach call after obtaining the device information, in which case the USBD module would continue looking for a driver to control the device. Only one driver of this type may be registered in the system.
To match a vendor-specific identifier. This is used for USB devices that do not fall into any currently defined class, or to provide an enhanced driver for a particular IHV’s USB devices. It is not recommended for general-purpose drivers that may be able to control devices from multiple IHVs.
To control devices of a specific device class. For example, you could write a USB device driver to control all human interface device (HID) class devices. The USB Working Group has defined other device classes, including communications, audio, and mass storage.
To control each interface on a device. For example, a USB CD-ROM drive that has an audio interface, as is common with CD-ROM drives that can play audio CDs, could have separate drivers for each interface. This method is the best for loading USB device drivers since it allows compound devices that require multiple drivers to operate without additional reconfiguration.

The registry key for a USBD should either be part of an OEM’s platform .reg file or be created when a USB device driver is installed on a Windows CE–based platform. At installation time, the key can be created either by a setup application or by the driver’s USBInstallDriver function. USBInstallDriver should create the keys indirectly, by calling the RegisterClientSettings function, rather than by invoking the Windows CE registry APIs. Installation by USBInstallDriver occurs when an unrecognized USB device is connected to the bus and the USBD module queries the user for the name of the device driver DLL. The USBD module then loads the driver and calls its USBInstallDriver function.

Subkeys for each driver have the form Group1_ID\Group2_ID\Group3_ID\DriverName. Each of the group identifier subkeys can be named Default to indicate that the USBD should be loaded if the remaining group identifier subkey names match the USB device. Otherwise, the group identifier subkey names are formed from combinations of vendor, device class, and protocol information, separated by underscores. This information comes from the USB device descriptor. The following table shows the allowable combinations.

Group key	Allowable forms
*Group1_ID*	DeviceVendorID, DeviceVendorID_DeviceProductID, DeviceVendorID_DeviceProductID_DeviceReleaseNumber
*Group2_ID*	DeviceClassCode, DeviceClassCode_DeviceSubclassCode, DeviceClassCode_DeviceSubclassCode_DeviceProtocolCode
*Group3_ID*	InterfaceClassCode, InterfaceClassCode_InterfaceSubclassCode, InterfaceClassCode_InterfaceSubclassCode_InterfaceProtocolCode

The following example shows the registry key setup for the sample mouse driver.

[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients]
  [Default]
    [Default]
      [3_1_2]
         [Generic_Sample_Mouse_Driver]
           “DLL”=“USBmouse.dll”

This example shows that the driver contained in Usbmouse.dll called Generic_Sample_Mouse_Driver is loaded by default for any interface on a USB device with an InterfaceClassCode of 3 (HID class), InterfaceSubclassCode of 1 (boot interface subclass), and InterfaceProtocolCode of 2 (mouse protocol). These values are defined in the USB HID specification.

The following example shows the settings for the sample HID driver.

[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients]
  [Default]
    [Default]
      [3]
         [Generic_Sample_Hid_Class_Driver]
           “DLL”=“USBHID.dll”

This example shows that the driver contained in Usbhid.dll is called Generic_Sample_Hid_Class_Driver and is loaded for any interface with an InterfaceClassCode of 3.

According to the precedence rules for loading USB device drivers, if the settings for both the sample mouse and the HID drivers are included in the registry, the HID driver is loaded first since it has the more general Group3_ID subkey.

Registry Keys for USB Device Drivers

Group key

Allowable forms