USB Device Registry Entries

This topic describes the device-specific registry entries.

Find device information after it enumerates on Windows

View the device interface GUID, Hardware Id, and device class information about your device

Find this registry key and note the DeviceInstance value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\

Find the device instance registry key and get the device interface GUID:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ \ \Device Parameters

Under the device instance key, note the device class, subclass, and protocol codes:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB

Registry settings for configuring USB driver stack behavior

The registry entries described in this topic are found under this key:

In the vvvvpppprrrrr key,

• vvvv is a 4-digit hexadecimal number that identifies the vendor
• pppp is a 4-digit hexadecimal number that identifies the product
• rrrr is a 4-digit hexadecimal number that contains the revision number of the device.

The vendor ID, product ID, and revision number values are obtained from the USB device descriptor. The following table describes the possible registry entries for the vvvvpppprrrrr key. The USB driver stack considers these entries as read-only values.

osvc

Supported on WindowsВ XP and later versions.

Indicates whether the operating system queried the device for Microsoft-Defined USB Descriptors. If the previously-attempted OS descriptor query was successful, the value contains the vendor code from the OS string descriptor.

0x0000: The device did not provide a valid response to the Microsoft OS string descriptor request.

0x01xx: The device provided a valid response to the Microsoft OS string descriptor request, where xx is the bVendorCode contained in the response.

IgnoreHWSerNum

Supported on WindowsВ Vista and later versions.

Indicates whether the USB driver stack must ignore the serial number of the device.

0x00: The setting is disabled.

0x01: Forces the USB driver stack to ignore the serial number of the device. Therefore, the device instance is tied to the port to which the device is attached.

ResetOnResume

Supported on WindowsВ Vista and later versions.

Indicates whether the USB driver stack must reset the device when the port resumes from a sleep cycle.

0x0000: The setting is disabled.

0x0001: Forces the USB driver stack to reset a device on port resume.

How to connect to a USB device (UWP app)

Summary

• How to use the DeviceWatcher object to detect devices
• How to open the device for communication
• How to close the device when you are finished using it

Important APIs

When you write a UWP app that interacts with a USB device, the app can send control commands, get device information, and read and write data to/from bulk and interrupt endpoints. Before you can do all that, you must find the device and establish connection.

Before you start.

• This is the first topic in a series. Before you start this tutorial, you must have created a basic Visual Studio project that you can extend in this tutorial. Read Getting started with UWP apps for more info.
• Code examples are based on the CustomUsbDeviceAccess sample. You can download the complete sample from this code gallery page.
• The USB device used in tutorial is the SuperMUTT device.
• In order to use the Windows.Devices.Usb namespace to write a Windows app that interacts with a USB device, the device must have the Winusb.sys driver loaded as its function driver. Winusb.sys is provided by Microsoft and is included with Windows in the \Windows\System32\drivers folder.

Flowchart: Finding the device

To connect to a USB device, you must first find the device based on various discovery patterns and then connect to it:

• Connect to any USB device with a specific device interface GUID.
• Connect to a USB device with a particular Vendor ID and Product ID and that has a specific device interface GUID.
• Connect to a USB device with a particular Vendor ID and Product ID without knowing the device interface GUID.
• Connect to a USB device which has known device class.

Key concepts

What is a device interface GUID?

A kernel-model driver, during its initialization, register and exposes a GUID called the device interface GUID. Typically, the app uses the exposed GUID to find the associated driver and its device, and then open a handle to the device. The retrieved handle is used for subsequent read and write operations.

However, in the case of Winusb.sys, instead of the driver exposing the device interface GUID, it can be provided in one of two ways:

• In the device’s MS OS descriptors. The device manufacturer sets DeviceInterfaceGUID as a custom property in the extended properties descriptor in the device. For more details, see the «Extended Properties Descriptors» document in Microsoft OS Descriptors.
• If you installed Winusb.sys manually through a custom INF, the INF registered a GUID in the INF. See WinUSB (Winusb.sys) Installation.

If a device interface GUID is found for the device, your UWP app can find all devices that match that device interface GUID.

How is USB device identification shown in Windows?

Every USB device must have two pieces of information: vendor ID and product ID.

USB-IF assigns those identifiers and the device manufacturer must expose them in the device. So how can you obtain that information?

Even when the device doesn’t have a device driver loaded, that is, Windows detects it as an «Unknown Device», you can still view the identifiers in the Device Manager in the Hardware Id property value. That value is a combination of those two identifiers. For example, for the SuperMUTT device, the Hardware Id is «USB\VID_045E&PID_F001»; vendor id is «0x045E» and product id is «0xF001».

If there is an INF for the device, obtain that string from the Models section.

You can inspect various registry settings. The easiest way is to see the

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USB\

Hardware ID is used by the app manifest to identify the device.

Your UWP app can find all devices that match a specific vendor and product ids. You can narrow the search results by specifying the device interface GUID.

What are USB device classes?

Most USB devices conform to device class specifications approved by USB-IF. By using those specifications, devices of similar nature can exhibit their functionality in a standard way. The biggest advantage of this approach is that the device can use a Microsoft provided in-box class driver or the generic Winusb.sys driver.

Some devices might not follow a USB-IF specification. Instead they expose vendor-defined functionality. For such devices, either the vendor must provide the device driver or Winusb.sys can be used.

Whether a device is vendor-defined or conforms to a device class, it must describe this device class related information:

• Class code: Indicates the device class to which the device belongs.
• Subclass code: Within the device class, indicates the subclass of device.
• Protocol code: The protocol that the device uses.

For example, the SuperMUTT device is a vendor-defined device and that information is indicated by class code is FF. If your device shows class code as FEh, subclass code as 02h, and protocol code 00h, you can conclude that the device is a class-compliant IrDA bridge device. Your UWP app can communicate with devices that belong to these device classes:

• ActiveSync
• CdcControl
• DeviceFirmwareUpdate
• IrDA
• Measurement
• PalmSync
• PersonalHealthcare
• Physical
• VendorSpecific

Your UWP app can find all devices that match a specific set of class, subclass, and protocol codes.

Get the Advanced Query Syntax (AQS) string for the device

Generate an advanced query string (AQS) that contains identification information about the device that you want to detect. You can generate the string either by specifying the vendor/product IDs, device interface GUID, or by the device class.

If you want to provide the vendor ID/product ID or the device interface GUID, call any overload of GetDeviceSelector.

In the example of the SuperMUTT device, GetDeviceSelector retrieves an AQS string similar to this string:

«System.Devices.InterfaceClassGuid:=»» AND System.Devices.InterfaceEnabled:=System.StructuredQueryType.Boolean#True AND System.DeviceInterface.WinUsb.UsbVendorId:=1118 AND System.DeviceInterface.WinUsb.UsbProductId:=61441″

NoteВ В Notice that the device interface GUID that appears in the string is not the one you specified. That GUID is the actual device interface GUID registered by Winusb.sys for UWP apps.

If you know the device class of the device or its class, subclass, and protocol codes, call GetDeviceClassSelector to generate the AQS string.

Create a UsbDeviceClass object by specifying ClassCode, SubclassCode, and ProtocolCode property values. Alternatively, if you know the device class of the device, you can call the constructor by specifying a particular UsbDeviceClasses property.

Finding the device—The basic way

This is the simplest way to find a USB device. For details, see Quickstart: enumerating commonly used devices.

1. Pass the retrieved AQS string to FindAllAsync. The call retrieves a DeviceInformationCollection object.
2. Loop through the collection. Each iteration gets a DeviceInformation object.
3. Get the DeviceInformation.Id property value. The string value is the device instance path. For example, «\\\\?\\USB#VID_045E&PID_078F#6&1b8ff026&0&5#«.
4. Call FromIdAsync by passing the device instance string and get the UsbDevice object. You can then use the UsbDevice object to perform other operations, such as sending a control transfer. When the app has finished using the UsbDevice object, the app must release it by calling Close. NoteВ В When UWP app suspends, the device is closed automatically. To avoid using a stale handle for future operations, the app must released the UsbDevice reference.

Find the device—using DeviceWatcher

Alternatively, you can enumerate devices dynamically. Then, your app can receive notification if devices are added or removed, or if device properties change. For more information, see How to get notifications if devices are added, removed, or changed.

A DeviceWatcher object enables an app to dynamically detect devices as they get added and removed from the system.

Create a DeviceWatcher object to detect when the device is added to or removed from the system. You must create the object by calling CreateWatcher and specifying the AQS string.

Implement and register handlers for Added and Removed events on the DeviceWatcher object. Those event handlers are invoked when devices (with the same identification information) are added or removed from the system.

The app must start the DeviceWatcher object by calling Start so that it can start detecting devices as they are added or removed from the system. Conversely, the app must stop the DeviceWatcher by calling Stop, when it’s no longer necessary to detect devices. The sample has two buttons that allows the user to start and stop DeviceWatcher.

This code example shows how to create and start a device watcher to look for instances of the SuperMUTT device.

Open the device

To open the device, the app must start an asynchronous operation by calling the static method FromIdAsync and passing the device instance path (obtained from DeviceInformation.Id). That result of that operation obtain is a UsbDevice object, which is used for future communication with the device, such as performing data transfers.

After you are finished using the UsbDevice object, you must release it. By releasing the object, all pending data transfers are canceled. The completion callback routines for those operations are still invoked with canceled error or the operation completed.

C++ apps must release the reference by using the delete keyword. C#/VB apps must call the UsbDevice.Dispose method. JavaScript apps must call UsbDevice.Close.

The FromIdAsync fails if the device is in use or cannot be found.

USB device class drivers included in Windows

This topic is for programmers. If you are a customer experiencing USB problems, see Troubleshoot common USB problems

This topic lists the Microsoft-provided drivers for the supported USB device classes.

• Microsoft-provided drivers for USB-IF approved device classes.
• For composite devices, use USB Generic Parent Driver (Usbccgp.sys) that creates physical device objects (PDOs) for each function.
• For non-composite devices or a function of a composite device, use WinUSB (Winusb.sys).

If you are installing USB drivers: You do not need to download USB device class drivers. They are installed automatically. These drivers and their installation files are included in Windows. They are available in the \Windows\System32\DriverStore\FileRepository folder. The drivers are updated through Windows Update.

If you are writing a custom driver: Before writing a driver for your USB device, determine whether a Microsoft-provided driver meets the device requirements. If a Microsoft-provided driver is not available for the USB device class to which your device belongs, then consider using generic drivers, Winusb.sys or Usbccgp.sys. Write a driver only when necessary. More guidelines are included in Choosing a driver model for developing a USB client driver.

USB Device classes

USB Device classes are categories of devices with similar characteristics and that perform common functions. Those classes and their specifications are defined by the USB-IF. Each device class is identified by USB-IF approved class, subclass, and protocol codes, all of which are provided by the IHV in device descriptors in the firmware. Microsoft provides in-box drivers for several of those device classes, called USB device class drivers. If a device that belongs to a supported device class is connected to a system, Windows automatically loads the class driver, and the device functions with no additional driver required.

Hardware vendors should not write drivers for the supported device classes. Windows class drivers might not support all of the features that are described in a class specification. If some of the device’s capabilities are not implemented by the class driver, vendors should provide supplementary drivers that work in conjunction with the class driver to support the entire range of functionality provided by the device.

For general information about USB-IF approved device classes see the USB Common Class Specification

The current list of USB class specifications and class codes is documented in the USB-IF Defined Class Code List.

Device setup classes

Windows categorizes devices by device setup classes, which indicate the functionality of the device.

Microsoft defines setup classes for most devices. IHVs and OEMs can define new device setup classes, but only if none of the existing classes apply. For more information, see System-Defined Device Setup Classes.

Two important device setup classes for USB devices are as follows:

USBDevice <88bae032-5a81-49f0-bc3d-a4ff138216d6>: IHVs must use this class for custom devices that do not belong to another class. This class is not used for USB host controllers and hubs.

USB <36fc9e60-c465-11cf-8056-444553540000>: IHVs must not use this class for their custom devices. This is reserved for USB host controllers and USB hubs.

The device setup classes are different from USB device classes discussed earlier. For example, an audio device has a USB device class code of 01h in its descriptor. When connected to a system, Windows loads the Microsoft-provided class driver, Usbaudio.sys. In Device Manager, the device is shown under is Sound, video and game controllers, which indicates that the device setup class is Media.

Microsoft-provided USB device class drivers

Registry entry	Description	Possible values

USB-IF class code	Device setup class	Microsoft-provided driver and INF	Windows support	Description
Audio (01h)	Media	Usbaudio.sys

WindowsВ 10 for desktop editions (Home, Pro, Enterprise, and Education) WindowsВ 10 Mobile WindowsВ 8.1 WindowsВ 8 WindowsВ 7 Windows ServerВ 2008 WindowsВ Vista Microsoft provides support for the USB audio device class by means of the Usbaudio.sys driver. For more information, see «USBAudio Class System Driver» in Kernel-Mode WDM Audio Components. For more information about Windows audio support, see the Audio Device Technologies for Windows website. Communications and CDC Control (02h) Ports

Usbser.sys Usbser.inf WindowsВ 10 for desktop editions WindowsВ 10 Mobile In WindowsВ 10, a new INF, Usbser.inf, has been added that loads Usbser.sys automatically as the function driver.

Note Supports Subclass 02h (ACM) Usbser.sys Custom INF that references mdmcpq.inf WindowsВ 10 for desktop editions WindowsВ 8.1 WindowsВ 8 WindowsВ 7 Windows ServerВ 2008 WindowsВ Vista In WindowsВ 8.1 and earlier versions, Usbser.sys is not automatically loaded. To load the driver, you need to write an INF that references the modem INF (mdmcpq.inf) and includes \[Install\] and \[Needs\] sections.

Starting with Windows Vista, you can enable CDC and Wireless Mobile CDC (WMCDC) support by setting a registry value, as described in Support for the Wireless Mobile Communication Device Class.

When CDC support is enabled, the USB Common Class Generic Parent Driver enumerates interface collections that correspond to CDC and WMCDC Control Models, and assigns physical device objects (PDO) to these collections. Net <4d36e972-e325-11ce-bfc1-08002be10318>Note Supports Subclass 0Dh (NCM) UsbNcm.sys UsbNcm.inf Windows Insider Preview Microsoft provides the UsbNcm.sys driver to operate devices that comply with Usb NCM. The source code for this driver is available at NCM-Driver-for-Windows. Net <4d36e972-e325-11ce-bfc1-08002be10318>Note Supports Subclass 0Eh (MBIM) wmbclass.sys Netwmbclass.inf WindowsВ 10 for desktop editions WindowsВ 8.1 WindowsВ 8 Starting in WindowsВ 8, Microsoft provides the wmbclass.sys driver, for mobile broadband devices. See, MB Interface Model. HID (Human Interface Device) (03h) HIDClass

Hidclass.sys Hidusb.sys Input.inf WindowsВ 10 for desktop editions WindowsВ 10 Mobile WindowsВ 8.1 WindowsВ 8 WindowsВ 7 Windows ServerВ 2008 WindowsВ Vista Microsoft provides the HID class driver (Hidclass.sys) and the miniclass driver (Hidusb.sys) to operate devices that comply with the USB HID Standard. For more information, see HID Architecture and Minidrivers and the HID class driver. For further information about Windows support for input hardware, see the Input and HID — Architecture and Driver Support website. Physical (05h) — — — Recommended driver: WinUSB (Winusb.sys) Image (06h) Image Usbscan.sys Sti.inf WindowsВ 10 for desktop editions WindowsВ 8.1 WindowsВ 8 WindowsВ 7 Windows ServerВ 2008 WindowsВ Vista Microsoft provides the Usbscan.sys driver that manages USB digital cameras and scanners for WindowsВ XP and later operating systems. This driver implements the USB component of the Windows Imaging Architecture (WIA). For more information about WIA, see Windows Image Acquisition Drivers and the Windows Imaging Component website. For a description of the role that Usbscan.sys plays in the WIA, see WIA Core Components. Printer (07h) USB

NoteВ В Usbprint.sys enumerates printer devices under the device set up class: Printer

<4d36e979-e325-11ce-bfc1-08002be10318>. Usbprint.sys Usbprint.inf WindowsВ 10 for desktop editions WindowsВ 8.1 WindowsВ 8 WindowsВ 7 Windows ServerВ 2008 WindowsВ Vista Microsoft provides the Usbprint.sys class driver that manages USB printers. For information about implementation of the printer class in Windows, see the Printing — Architecture and Driver Support website. Mass Storage (08h) USB Usbstor.sys WindowsВ 10 for desktop editions WindowsВ 10 Mobile WindowsВ 8.1 WindowsВ 8 WindowsВ 7 Windows ServerВ 2008 WindowsВ Vista Microsoft provides the Usbstor.sys port driver to manage USB mass storage devices with Microsoft’s native storage class drivers. For an example device stack that is managed by this driver, see Device Object Example for a USB Mass Storage Device. For information about Windows storage support, see the Storage Technologies website. SCSIAdapter

SubClass (06) and Protocol (62) Uaspstor.sys Uaspstor.inf WindowsВ 10 for desktop editions WindowsВ 10 Mobile WindowsВ 8.1 WindowsВ 8 Uaspstor.sys is the class driver for SuperSpeed USB devices that support bulk stream endpoints. For more information see:

• Loading a UASP Storage Driver as a Class Driver on xHCI
• USB Attached SCSI (UAS) Best Practices for Windows 8

Hub (09h) USB Usbhub.sys Usb.inf WindowsВ 10 for desktop editions WindowsВ 10 Mobile WindowsВ 8.1 WindowsВ 8 WindowsВ 7 Windows ServerВ 2008 WindowsВ Vista Microsoft provides the Usbhub.sys driver for managing USB hubs. For more information about the relationship between the hub class driver and the USB stack, see USB host-side drivers in Windows. Usbhub3.sys Usbhub3.inf WindowsВ 10 for desktop editions WindowsВ 8.1 WindowsВ 8 Microsoft provides the Usbhub3.sys driver for managing SuperSpeed (USB 3.0) USB hubs.

The driver is loaded when a SuperSpeed hub is attached to an xHCI controller. See USB host-side drivers in Windows. CDC-Data (0Ah) — — — Recommended driver: WinUSB (Winusb.sys) Smart Card (0Bh) SmartCardReader

Usbccid.sys (Obsolete) WindowsВ 10 for desktop editions WindowsВ 7 Windows ServerВ 2008 WindowsВ Vista Microsoft provides the Usbccid.sys mini-class driver to manage USB smart card readers. For more information about smart card drivers in Windows, see Smart Card Design Guide.

Note that for Windows Server 2003, Windows XP, and Windows 2000, special instructions are required for loading this driver because it might have been released later than the operating system.

Note Usbccid.sys driver has been replaced by UMDF driver, WUDFUsbccidDriver.dll. WUDFUsbccidDriver.dll WUDFUsbccidDriver.inf WindowsВ 8.1 WindowsВ 8 WUDFUsbccidDriver.dll is a user-mode driver for USB CCID Smart Card Reader devices. Content Security (0Dh) — — — Recommended driver: USB Generic Parent Driver (Usbccgp.sys). Some content security functionality is implemented in Usbccgp.sys. See Content Security Features in Usbccgp.sys. Video (0Eh) Image

Usbvideo.sys

Usbvideo.inf WindowsВ 10 for desktop editions

WindowsВ Vista Microsoft provides USB video class support by means of the Usbvideo.sys driver. For more information, see «USB Video Class Driver» under AVStream Minidrivers.

Note that for Windows XP, special instructions are required for loading this driver because it might have been released later than the operating system. Personal Healthcare (0Fh) — — — Recommended driver: WinUSB (Winusb.sys) Audio/Video Devices (10h) — — — — Diagnostic Device (DCh) — — — Recommended driver: WinUSB (Winusb.sys) Wireless Controller (E0h)

Note В В Supports Subclass 01h and Protocol 01h Bluetooth

Bthusb.sys

Bth.inf WindowsВ 10 for desktop editions WindowsВ 10 Mobile WindowsВ 8.1 WindowsВ 8 WindowsВ 7 WindowsВ Vista Microsoft provides the Bthusb.sys miniport driver to manage USB Bluetooth radios. For more information, see Bluetooth Design Guide. Miscellaneous (EFh) Net

NoteВ В Supports SubClass 04h and Protocol 01h Rndismp.sys Rndismp.inf WindowsВ 10 for desktop editions WindowsВ 8.1 WindowsВ 8 WindowsВ 7 WindowsВ Vista

Note Microsoft recommends that hardware vendors build USB NCM compatible devices instead. USB NCM is a public USB-IF protocol that offers better throughput performance.