|This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
Registry keys control how USB device drivers are loaded. When a USB device is attached, the USBD module loads the appropriate USB device driver 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 track both the drivers and the devices. The registry keys are stored as subkeys of the HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\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 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 LoadClientskey 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:
The registry key for a USB device driver 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 USBInstallDriverfunction. USBInstallDrivershould create the keys indirectly, by calling the RegisterClientSettingsfunction, rather than by invoking the Windows CE registry APIs. Installation by USBInstallDriveroccurs when an unrecognized USB device is connected to the bus and the USBD module queries a user for the name of the device driver DLL. The USBD module then loads the driver and calls its USBInstallDriverfunction.
Subkeys for each driver have the form Group1_ID\ Group2_ID\ Group3_ID\ DriverName. Each of the group identifier subkeys can be named Defaultto indicate that the USB device driver 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|
The following code example shows a registry key setup for a hypothetical USB mouse device driver.
[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients] [Default] [Default] [3_1_2] [Generic_Sample_Mouse_Driver] "DLL"="USBmouse.dll"
This code example shows that the driver contained in Usbmouse.dll called Super_Mouse_Driveris 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]  [Generic_Sample_Hid_Class_Driver] "DLL"="USBHID.dll"
This example shows that the driver contained in Usbhid.dll is called Generic_Sample_Hid_Class_Driverand 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 mouse and the HID drivers are included in the registry, the HID driver is loaded first because it has the more general Group3_IDsubkey.
Last updated on Tuesday, July 13, 2004