Partager via


USB Driver Registry Settings

This topic contains information on the following registry settings:

  • HCD Module Registry Settings
  • USB Printer Class Driver Registry Settings
  • USB Mass Storage Class Driver Registry Settings
  • USB Host Controller (HCD) Registry Settings
  • Human Interface Device (HID) Driver Registry Settings

Registry keys control how USB device drivers are loaded. When a USB device is attached, the USB driver module loads the appropriate USB device driver to control that device, based on the device's configuration and interface descriptor information. The USB driver 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, you may decide to include a generic class driver with your platform that can control a broad range of USB devices. However, you 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, your 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 table shows examples of the contexts that can cause specific USB device drivers to be loaded.

Example Description
To match every device that is 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 that is connected to the system. In this case, the driver could purposely fail the USBDeviceAttach call after obtaining the device information, in which case the USB driver module would continue looking for a driver to control the device. Only one driver of this type can 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 USB device. It is not recommended for general-purpose drivers that may be able to control devices from multiple developers.
To control devices of a specific device class. For example, you could write a USB device driver to control all HID class devices. The USB Implementers Forum 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 CD-ROMs, could have separate drivers for each interface. This method is the best for loading USB device drivers because it allows compound devices that require multiple drivers to operate without additional reconfiguration.

The registry key for a USB device driver should either be part of your platforms .reg file or be created when a USB device driver is installed on a 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 registry APIs. Installation by USBInstallDriver occurs when an unrecognized USB device is connected to the bus and the USB driver module queries a user for the name of the device driver DLL. The USB driver 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 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
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 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 mouse and the HID drivers are included in the registry, the HID driver is loaded first because it has the more general Group3_ID subkey.

HCD Module Registry Settings

If your platform contains UHCI–compliant host controllers, you will have a porting task similar to a platform with OHCI-complaint host controllers. OEMs need to include the following registry values under the HKEY_LOCAL_MACHINE\Drivers\Builtin\UHCI registry key so that the UHCD will be loaded when the system boots.

[HKEY_LOCAL_MACHINE\Drivers\Builtin\UHCI]
    "Prefix"="HCD"
    "Dll"="uhci.dll"
    "Index"=dword:1
    "Order"=dword:1
    "UseExistingSettings"=dword:0
    "Irq"=dword:<platform dependent>
    "MemBase"=dword:<platform dependent>
    "Priority"=dword:<platform dependent>

The UseExistingSettings key controls whether the values for Irq, MemBase, and Priority come from the system's BIOS settings, or whether they come from the registry. A value of 0 causes the BIOS setting to be used. Any other value causes the BIOS settings to be ignored in favor of the values specified in the Irq, MemBase, and Priority keys.

When the UHCD is loaded at boot time, it attempts to detect the presence of a UHCI-compliant USB host controller. The sample UHCD is only capable of detecting the Intel PIIX4 controller because of PCI bus values that are hard-coded into the UHCD. However, the detection function is available as source code to OEMs, who can change the function to detect other UHCI-compliant USB host controllers. The following table lists the values that the sample UHCD uses to identify the Intel PIIX4 controller.

PCI field Value Description
BaseClass 0x0C Serial Bus Controller
SubClass 0x03h USB subclass
VendorID 0x8086 Intel Vendor ID
DeviceID 0x7112 PIIX4 Device ID

The sample HCD included with Microsoft® Windows® CE 3.0 only supports one UHCI chip on a system. The UseExistingSettings key has no effect on Microsoft Windows CE 2.11 for the CEPC, for which the HCD module supplied by Microsoft has a pre-defined address hard coded into it for the host controller. In Windows CE 2.12 and later, the HCD module obtains the host controller interface settings dynamically according to the UseExistingSettings key as described above. The default value of the UseExistingSettings key can also be controlled on your development workstation through the environment variable CEPC_USB_USE_EXISTING; if you set this variable to a new value, you do not need to rebuild the HCD module; you only need to run the Makeimg utility to cause the new value to be incorporated into your operating system image. Fundamentally, Windows CE cannot reconfigure PCI devices dynamically; thus, if UseExistingSettings is set to 0, the USB host controller interface settings in the CEPC system's bios must match those in the CEPC system's registry, or else the HCD module will not load. If the two do not match, you can use another operating system on your CEPC, such as Microsoft Windows 95, to check the BIOS settings, and then update your Platform.reg file with the correct addresses and IRQ information. Alternately, you can watch the debug output while the CEPC system boots, which should report an error that contains the BIOS settings, as shown in the following code example.

!OHCD: Configuration different from registry: IRQ %u, PortBase: 0x%X (reg: %u, 0x%X)

USB Printer Class Driver Registry Settings

The OEM should create the following registry entries to properly load the USB printer driver on their target platform.

[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\Default\Default\7\Printer_Class]
    "DLL"="USBPRN.DLL"
    "Prefix"="LPT"
[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Printer_Class]
    "DLL"="USBPRN.DLL"
    "Prefix"="LPT" 

You can also change the timeout behavior on the loading of the driver by changing and adding the following registry values. The driver uses the default values if these entries are not present. You must remove and re-insert the device for the driver to get reloaded so it can read the new setting during initialization time.

[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Printer_Class]
    PortStatusTimeout:DWORD:2000 // time in msec
    DeviceIdTimeout:2000
    SoftResetTimeout:2000
    ReadTimeoutMultiplier:10
    ReadTimeoutConstant:100
    WriteTimeoutMultiplier:50
    WriteTimeoutConstant:1000

USB Mass Storage Class Driver Registry Settings

The OEM should create the following registry entries to properly load the USB storage driver on their target platform.

[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\Default\Default\8\Mass_Storage_Class]
    "DLL"="USBMSC.DLL"
    "Prefix"="DSK"
[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Mass_Storage_Class]
    "DLL"="USBMSC.DLL"
    "Prefix"="DSK"
[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Mass_Storage_Class\2]
    "DLL"="USBDISK6.DLL"
    "Prefix"="DSK"
    "FSD"="UDFS.DLL"
    "Folder"="USB Disk"
    "IOCTL"=dword:4
[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Mass_Storage_Class\6]
    "DLL"="USBDISK6.DLL"
    "Prefix"="DSK"
    "FSD"="FATFS.DLL"
    "Folder"="USB Disk"
    "IOCTL"=dword:4

You can also change the timeout behavior on the loading of the driver by changing or adding the following registry values. The driver uses the default values if these entries are not present.

Note   You must remove and re-insert the device for the driver to get reloaded so it can read the new setting during initialization time.

[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Mass_Storage_Class]
    ResetTimeout:4000 // msec
    CommandBlockTimeout:4000
    CommandStatusTimeout:4000
[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Mass_Storage_Class\6]
    MediaPollInterval:1250 // msec
    ReadSectorTimeout:2000
    WriteSectorTimeout:2000
    ScsiCommandTimeout:5000
    UnitAttnRepeat:10

USB Host Controller Registry Settings

The following registry keys show USB host controller registry keys.

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\OHCI]
    "Prefix"="HCD"
    "Dll"="ohci.dll"
    "Index"=dword:1
    "Order"=dword:1
    "Irq"=dword:0F 
    "MemBase"=dword:FFBFE000
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\UHCI]
    "Prefix"="HCD"
    "Dll"="uhci.dll"
    "Index"=dword:1
    "Order"=dword:1
    "Irq"=dword:0A
    "MemBase"=dword:D801

Human Interface Device (HID) Driver Registry Settings

The following registry keys show HID registry keys.

IF BSP_NOUSB !
; @CESYSGEN IF CE_MODULES_USBHID 
; USB - Human Interface Device (HID) class Driver
[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\Default\Default\3\Hid_Class]
   "DLL"="USBHID.DLL"

[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Hid_Class]
   "DLL"="USBHID.DLL"
   "Prefix"="HID"
; @CESYSGEN ENDIF

; @CESYSGEN IF CE_MODULES_USBPRN && CE_MODULES_USBD
; USB - Printer Class Driver
[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\Default\Default\7\Printer_Class]
   "DLL"="USBPRN.DLL"
   "Prefix"="LPT"

[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Printer_Class]
   "DLL"="USBPRN.DLL"
   "Prefix"="LPT"
; @CESYSGEN ENDIF

; @CESYSGEN IF CE_MODULES_USBMSC && CE_MODULES_USBD
; USB - Mass Storage Class Driver
[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\Default\Default\8\Mass_Storage_Class]
   "DLL"="USBMSC.DLL"
   "Prefix"="DSK"

[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Mass_Storage_Class]
   "DLL"="USBMSC.DLL"
   "Prefix"="DSK"

[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Mass_Storage_Class\2]
   "DLL"="USBDISK6.DLL"
   "Prefix"="DSK"
   "Folder"="USB Disk"
   "IOCTL"=dword:4
   "IClass"="{A4E7EDDA-E575-4252-9D6B-4195D48BB865}"

[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Mass_Storage_Class\6]
   "DLL"="USBDISK6.DLL"
   "Prefix"="DSK"
   "Folder"="USB Disk"
   "IOCTL"=dword:4
   "IClass"="{A4E7EDDA-E575-4252-9D6B-4195D48BB865}"
; @CESYSGEN ENDIF

; @CESYSGEN IF CE_MODULES_STCUSB
; SCM Microsystems USB Smart Card Reader
[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\102_4097\Default\Default\STCUSB]
   "DLL"="STCUSB.DLL"

; stream driver settings for STCUSB.DLL
[HKEY_LOCAL_MACHINE\Drivers\USB\StcUsb]
    "Prefix"="SCR"
    "Dll"="stcusb"
; @CESYSGEN ENDIF

Schlumberger Reflex USB Smart Card Reader Registry Settings

The following registry keys show Schlumberger Reflex USB Smart Card Reader registry keys.

[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\1254_8196\Default\Default\STCUSB]
    "Dll"="stcusb.dll"

See Also

USB Driver Samples | USB Driver Architecture | USB Driver Registry Settings

 Last updated on Tuesday, May 18, 2004

© 1992-2003 Microsoft Corporation. All rights reserved.