Installing, Attaching, and Detaching USB Drivers (Windows CE 5.0)

Send Feedback

The HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients key must be set up correctly so that the USB driver module can load the appropriate driver for a device when a device is attached to the bus. Each installed USB device driver must have a subkey within the LoadClients key for the USB driver module to load it.

If you supply a USB device driver, you should configure the hardware platform's LoadClients key in the registry to include subkeys for the driver. For third-party peripherals, the driver does not have appropriate subkeys when it is first connected to the hardware platform. In this case, the USB driver module fails to locate an appropriate USB device driver when the peripheral is attached to the bus. The USB driver module instead displays a dialog box prompting a user to enter the name of the appropriate USB device driver DLL. The USB driver then loads the specified driver to control the peripheral and calls the driver's USBInstallDriver function.

The USB device driver's USBInstallDriver function sets up the driver's subkey correctly within the LoadClients key so that the USB driver module can load the driver the next time that the peripheral is attached to the bus. The driver does this by creating a USB_DRIVER_SETTINGS structure and passing it to the LPREGISTER_CLIENT_SETTINGS function. The format of the USB_DRIVER_SETTINGS structure parallels that of the LoadClients key. If all the fields in a group have USB_NO_INFO value, the corresponding GroupX_ID is set to Default in the registry. For example, the following example shows the USB_DRIVER_SETTINGS for the HID class sample driver.

USB_DRIVER_SETTINGS DriverSettings;
DriverSettings->dwVendorId          = USB_NO_INFO;
DriverSettings->dwProductId         = USB_NO_INFO;
DriverSettings->dwReleaseNumber     = USB_NO_INFO;

DriverSettings->dwDeviceClass       = USB_NO_INFO;
DriverSettings->dwDeviceSubClass    = USB_NO_INFO;
DriverSettings->dwDeviceProtocol    = USB_NO_INFO;

DriverSettings->dwInterfaceClass    = USB_DEVICE_CLASS_HUMAN_INTERFACE;
DriverSettings->dwInterfaceSubClass = USB_NO_INFO;
DriverSettings->dwInterfaceProtocol = USB_NO_INFO;

The following example shows how calling RegisterClientSettings with this USB_DRIVER_SETTINGS structure is equivalent to having set up this registry key.

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

In general, the client driver performs the following operations in USBInstallDriver:

  1. Registers a unique client driver identifier string by calling the LPREGISTER_CLIENT_DRIVER_ID function.

  2. Sets up the LoadClients registry key correctly by calling the RegisterClientSettings function.

  3. Creates any driver-specific registry keys under the registry key that is returned by the LPOPEN_CLIENT_REGISTRY_KEY function.

    This is optional because many client drivers might not have any driver-specific registry settings. The registry key for driver-specific settings is HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\Client Driver Id String. Client Driver ID String is the same string that was registered using LPREGISTER_CLIENT_DRIVER_ID. OpenClientRegistryKey and RegisterClientDriverID work together to enable USB drivers to have custom purpose registry keys. USB device drivers should always use OpenClientRegistryKey to manipulate the settings, rather than opening the registry key directly, to avoid the problems if the location for driver-specific keys ever changes.

  4. The USBInstallDriver returns control to the USB driver module.

  5. The USB driver module once again attempts to load a driver for the device, using the algorithm described in Loading USB Device Drivers.

  6. The USB driver module calls the USB device driver's attach routine.

Attaching USB Drivers

After the USB driver module loads a USB device driver for a peripheral, it calls the driver's USBDeviceAttach function. In this function, the USB device driver performs the following operations:

  1. The driver determines whether it can control the peripheral.

  2. If the driver can control the peripheral, the driver returns TRUE to accept control or FALSE to decline control.

    In the latter case, the USB driver module continues to search for other drivers to control the peripheral.

  3. The driver loads additional USB device drivers for other interfaces that might be present on the peripheral by calling the LPLOAD_GENERIC_INTERFACE_DRIVER function.

  4. If the driver accepts control of a peripheral, the USB driver module stops searching for drivers to control the peripheral.

    The driver that accepts control must then load any other USB device drivers for other interfaces present on the peripheral.

  5. The driver registers a callback function that is called when the peripheral is disconnected from the bus.

    USB device drivers use the LPREGISTER_NOTIFICATION_ROUTINE function to register callback functions.

Detaching USB Drivers

While attaching a USB driver, the driver might register a callback function. When a user detaches a peripheral from the bus, the USB driver module calls the callback function.

The callback function also has the option of calling other functions in the USB device driver, such as USBUnInstallDriver. USBUnInstallDriver removes all registry keys that were created by the driver's USBInstallDriver function and releases any other resources that are held by the driver. In this way, a user can remove any old registry settings for a particular device when a new or updated driver for that device is available. The USB driver module never calls USBUnInstallDriver directly.

See Also

USB Device Driver Implementation | Loading USB Device Drivers | Implementing USB Host Controller Drivers

Send Feedback on this topic to the authors

Feedback FAQs

© 2006 Microsoft Corporation. All rights reserved.