USB FAQ - Intermediate
This paper answers frequently asked questions from developers about developing USB devices and drivers for Microsoft Windows.
Introduction
Windows 98 and later versions of Windows include native support for Universal Serial Bus (USB) devices. This article provides answers to frequently asked questions from driver developers who need intermediate-level details about the USB stack and the USB features supported by Windows.
Additional documentation for USB device and driver support is available in an introductory level FAQ, the current version of the Windows Driver Kit (WDK), and on the USB Architecture and Driver Support webpage at http://www.microsoft.com/whdc/connect/usb/default.mspx.
Note: Unless otherwise specified, the information in this paper applies to Windows 2000 and later operating systems.
Windows Support and USB
This section of the FAQ answers general questions about how Windows supports USB.
Is my USB 2.0 hub single-TT or multi-TT?
A USB 2.0 hub can have one transaction translator (TT) for all downstream-facing ports on the hub (single TT), or it can have one TT for each downstream-facing port on the hub (multiple TT).
The value of the bDeviceProtocol field of the USB device descriptor and the bInterfaceProtocol field of the USB interface descriptor indicate whether a hub is single-TT or multi-TT:
| • | Single-TT. bDeviceProtocol == 0x01 |
| • | Multi-TT. bDeviceProtocol == 0x02 |
Usbhub.sys uses this setting to enable multi-TT mode or single-TT mode. On Windows XP and later, Usbhub.sys always enables multi-TT mode on a multi-TT hub.
For additional details about TT layout, see sections 11.14.1.3 and 11.23.1 of the USB 2.0 specification, which is available from the USB website at http://www.usb.org/developers/docs 
.
What characters or bytes are valid in a USB serial number?
The USB device descriptor's iSerialNumber field indicates whether the device has a serial number and where the number is stored, as follows:
| • | iSerialNumber == 0x00 : The USB device has no serial number. |
| • | iSerialNumber != 0x00 : The USB device has a serial number. The value assigned to iSerialNumber is the serial number's string index. |
If the device has a serial number, the serial number must uniquely identify each instance of the same device. For example, if two device descriptors have identical values for the idVendor, idProduct, and bcdDevice fields, the iSerialNumber field must be different, to distinguish one device from the other.
Plug and Play requires that every byte in a USB serial number be valid. If a single byte is invalid, Windows discards the serial number and treats the device as if it had no serial number.
The following byte values are not valid for USB serial numbers:
| • | 0x2C. |
| • | Values less than 0x20. |
| • | Values greater than 0x7F. |
For additional details on the iSerialNumber value, see section 9.6.1 of the USB 2.0 specification.
What LANGID is used in a string request on localized builds of Windows?
A USB device indicates the presence of a serial number by setting the iSerialNumber field of the USB device descriptor to the serial number's string index. To retrieve the serial number, Windows issues a string request with the language identifier (LANGID) set to 0x0409 (U.S. English). Windows always uses this LANGID to retrieve USB serial numbers, even for versions of Windows that are localized for other languages.
What LANGID is used to extract a device's serial number?
A USB device indicates the presence of a serial number by setting the iSerialNumber field of the USB device descriptor to the serial number's string index. To retrieve the serial number, Windows issues a string request with the language identifier (LANGID) set to 0x0409 (U.S. English). Windows always uses this LANGID to retrieve USB serial numbers, even for versions of Windows that are localized for other languages.
What does the IsDeviceHighSpeed function indicate?
The IsDeviceHighSpeed bus driver interface function returns the actual operational mode of the device in its current tree topology. If a device that supports high speed is connected to a USB 1.1 hub or a full-speed host controller, the function will indicate that the device is working at full speed. For more details, see the function's reference page in the WDK.
What is the maximum USB transfer size for different Windows versions?
See "Maximum size of USB transfers on various operating systems".
How should numbers be assigned to multiple interfaces on a composite device?
Windows treats USB devices with more than one interface on the first configuration as composite devices.
| • | For Windows XP Service Pack 1 and earlier versions of Windows:
| ||||
| • | For Windows XP Service Pack 2 and later versions of Windows, interface numbers are only required to be increasing, not consecutive. |
For additional information about interface numbers, see "Composite USB devices whose interfaces are not sequentially numbered do not work in Windows XP" listed in the Resources section below.
Alternate settings for an interface should be assigned as follows for all versions of Windows:
| • | The default value for an interface is always alternate setting zero. |
| • | Additional alternate setting numbers must be consecutive and increasing. |
For additional information on alternate settings, see Section 9.6.5 of the USB 2.0 specification.
Which parent driver should a USB composite device load?
Windows has supported USB composite devices since Windows 98. Usbhub.sys supports composite devices for:
| • | Windows 98 |
| • | Windows 98 SE |
| • | Windows 2000 |
A new driver for composite devices, Usbccgp.sys, was released with Windows Millennium Edition (Me). Usbccgp.sys supports composite devices for:
| • | Windows Me |
| • | Windows XP |
| • | Windows Server 2003 |
| • | Windows Vista |
| • | Windows Server 2008 |
Although it might still be possible to load Usbhub.sys as the parent driver for the composite device on these versions of Windows, Microsoft does not recommend it. You should instead use Usbccgp.sys. To ensure that you load the correct driver for your composite device, use the Include and Needs directives in your INF files, as follows:
Include = USB.INF
Needs = Composite.Dev
Important: An INF that refers to Usbhub.sys as the composite device driver might, in the future, fail hardware compatibility testing. If you have a composite device, it should be referring to Usbccgp.sys instead of Usbhub.sys.
For additional information, see "USB Common Class Generic Parent Driver" in the WDK.
What are the major restrictions imposed by Usbccgp.sys?
The major restrictions imposed on hardware devices and drivers by Usbccgp.sys are:
| • | Usbccgp supports only the default configuration, configuration 0. |
| • | Usbccgp does not support Selective Suspend in Windows XP and Windows Server 2003. This feature is supported only in Windows Vista and later versions of Windows. |
| • | Usbccgp supports the interface association descriptor (IAD) only in Windows XP Service Pack 2, Windows Server 2003 Service Pack 1, and later Windows versions. |
| • | Usbccgp supports nonconsecutive interface numbers only in Windows XP SP2, Windows Server 2003 SP1, and later Windows versions. |
How do I enable debug tracing for USB core binaries?
To enable kernel debugging:
| • | Obtain a checked build of Windows, or install checked USB modules on a free build of Windows. |
| • | Enable debug tracing for the various USB core binaries by setting the global variables shown in Table 1 and Table 2. |
Table 1. Kernel debug settings, Windows 2000
| Module name | Debug symbol | Range |
Uhcd.sys | UHCD_Debug_Trace_Level | 0-2 |
Openhci.sys | OHCI_Debug_Trace_Level | 0-2 |
Usbhub.sys | USBH_Debug_Trace_Level | 0-3 |
Usbd.sys | USBD_Debug_Trace_Level | 0-3 |
Table 2. Kernel debug settings, Windows XP and Windows Server 2003
| Module name | Debug symbol | Range |
Usbport.sys | USBPORT_Debug_Trace_Level | 0-4 |
Usbccgp.sys | DbgVerbose | 0-1 |
Usbhub.sys | USBH_Debug_Trace_Level | 0-3 |
Usbd.sys | USBD_Debug_Trace_Level | 0-3 |
For additional information about USB core stack debugging, see "How to enable verbose debug tracing in various drivers and subsystems".
What does bugcheck code 0xFE mean on Windows XP and later versions of Windows?
See http://msdn.microsoft.com/en-us/library/ms797153.aspx.
For additional information about USB core stack debugging, see the latest WDK and the documentation included with Debugging Tools for Windows.
What features of the EHCI specification are not yet implemented?
Windows XP supports a number of features in the Enhanced Host Controller Interface (EHCI) specification, but a few features have not been not implemented, as follows.
| • | Features added in or after EHCI version 0.95, including:
| ||||
| • | 64-bit host controller addressing support. The EHCI controller can still work in 32-bit mode on an x64 or Intel Itanium platform. | ||||
| • | Kernel Debugging over USB 2.0. This is supported in Windows Vista and later versions of Windows. | ||||
| • | EHCI BIOS handoff.
|
These features might be supported in future versions of Windows.
Does Windows support Interface Association Descriptors?
Yes. The USB 2.0 Interface Association Descriptor (IAD) Engineering Change Notification (ECN) introduced a new standard method for describing a grouping of interfaces and their alternate settings within a function. IAD can be used to identify two or more consecutive interfaces and alternate settings within one function.
Microsoft is currently working with IHVs to develop devices that support IAD. The following operating systems have support for IAD:
| • | Windows XP Service Pack 2 and later |
| • | Windows Server 2003 Service Pack 1 and later |
| • | Windows Vista |
For additional information on IAD, see "Support for USB Interface Association Descriptor in Windows" in the Resources section below.
Does the USB stack handle chained MDLs in a URB?
No. This functionality is not supported by the USB stack included with Windows.
Can a driver have more than one URB in an IRP?
No. This functionality is not supported by the USB stack included with Windows.
Does Windows Support USB Composite Hubs?
A composite USB device - also referred to as a multifunction USB device - exposes multiple functions, each of which can be treated as an independent device. The system loads the USB generic parent driver, Usbccgp.sys, to serve as the parent driver for eaech of the device's functions. The USB generic parent driver enumerates the composite device's functions as though they were separate USB devices and then creates a PDO and constructs a device stack for each function.
A composite USB device cannot expose a function that serves as a hub. Windows does not enumerate such hubs properly and attempting to install the device might cause a system crash.
Using a USB 2.0 Connection for Kernel Debugging
USB 2.0 provides an alternative to serial and 1394 communication links for connecting a debugging host to a target computer. This section of the FAQ answers questions about USB 2.0 kernel debugging.
Which versions of Windows support USB 2.0 kernel debugging?
USB 2.0 kernel debugging is currently supported by Windows Vista and later versions of Windows.
What system support is required for USB 2.0 kernel debugging?
USB 2.0 kernel debugging requires the following system support:
| • | The target computer must have an EHCI controller that is specifically implemented to support kernel debugging over a USB 2.0 connection. Only some EHCI controllers provide this support. Intel chipsets with EHCI controllers do implement support for kernel debugging. |
| • | The debug port must be externally accessible. On some systems, the EHCI controller supports kernel debugging, but cannot be used for for that purpose because the debug port is not connected to a USB connector that is accessible from the outside of the computer. System manufacturers that would like to support USB kernel debugging on their computers should not connect any internal devices to the debug port, and should ensure that the debug port is connected to an externally-accessible USB connector. On Intel chipsets, the debug port is typically PORT1 as reported by usbview.exe. |
Note: Usbview.exe is a utility that is included in Debugging Tools for Windows that allows you to view the USB controllers in a computer as well as what devices are connected to each port of the controller.
How do I determine whether an EHCI controller supports kernel debugging?
USB controllers that implement a debug port are supposed to report that they support this feature in the PCI configuration space of the controller. Unfortunately, there is no software available at this time that reports this information to the user.
All Intel EHCI controllers support USB kernel debugging on PORT1.
What if there is more than one EHCI controller in the target computer?
If there is more than one EHCI controller in the target computer, you should specify the controller that should be used for kernel debugging. Otherwise, you could have a situation where your USB debug cable is plugged into the debug port connector of one controller when the operating system on the target computer is attempting to use the debug port of a different EHCI controller. Failure to specify the controller to use for kernel debugging when there is more than one EHCI controller in the test computer typically results in USB kernel debugging not working.
To specify the EHCI controller to use for kernel debugging, type the following in a command prompt window with elevated privileges on the target computer:
bcdedit -set {current} loadoptions busparams=x.y.z
The x, y, and z values are computed from the bus, device, and function numbers for the EHCI controller that is to be used for kernel debugging. This information can be obtained from Device Manager as follows:
1. | Open Device Manager. |
2. | Expand Universal Serial Bus controllers. |
3. | Double click on the EHCI controller that is to be used for kernel debugging. |
4. | Note the bus, device, and function numbers that are indicated on the Location line. |
5. | Convert these three values to hexadecimal, and use the resulting hexadecimal values for x, y, and z in the bcdedit command, putting a period between each of the values. |
This will cause the operating system on the target computer to use the EHCI controller at that specific location in the computer for kernel debugging.
For example, if the location of the EHCI controller that is to be used for kernel debugging is shown in Device Manager as PCI bus 0, device 29, function 7, then the corresponding bcdedit command would be:
bcdedit -set {current} loadoptions busparams=0.1D.7
What cables can be used for USB 2.0 kernel debugging?
You must use a specially designed debug device for a USB 2.0 debugging connection. This device allows a standard USB cable to be connected between the host computer and the debug device, and another standard USB cable to be connected between the target computer and the debug device. It is not possible to do USB kernel debugging without this debug device installed between the host and target computers.
PLX Technology manufactures a USB debug device called the Net20DC. A link to their Web site is in the Resources section of this FAQ. Compatible devices may be available from other vendors, but Microsoft has not tested any debug devices other than the PLX Net20DC.
Where can I obtain the PLX debug device?
http://www.semiconductorstore.com/pages/search/searchinventory.asp?query=net20dc
Which debugging tools support USB 2.0 kernel debugging?
You must use an up-to-date version of the Debugging Tools for Windows package (version 6.10.3 or later). The driver that supports USB 2.0 debugging on the host machine, usb2dbg.sys, is installed with the debugging tools. The driver package can be found in the Program Files\Debugging Tools for Windows\Usb folder. The debugger will load the USB debug driver on the host computer when USB kernel debugging is specified. No additional USB debug driver needs to be installed on the target computer, as the necessary support is built into Windows Vista and later versions of Windows.
Microsoft Operating System Descriptors
Microsoft operating system (OS) descriptors provide a way for IHVs to store a variety of vendor-specific information in device firmware. This section of the FAQ answers questions about Microsoft OS descriptors.
For more information on Microsoft OS descriptors, see "Microsoft OS Descriptors Documentation".
What is a Microsoft OS Descriptor?
Microsoft OS descriptors provide a way for IHVs to store a variety of vendor-specific information in device firmware as OS feature descriptors, rather than distributing it to users separately from the device. Versions of Windows or Windows applications that are aware of Microsoft OS descriptors can use control requests to retrieve the descriptors from the device without requiring any user interaction. In particular, Windows can automatically retrieve the descriptors when the device is initially plugged in and use the information to give the user a smoother Plug and Play experience.
What types of OS feature descriptors are supported by Windows?
Any information to be stored as a feature descriptor must comply with one of the standard formats that Microsoft has defined. Additional feature descriptors cannot be defined or implemented without Microsoft consent. Microsoft has defined the following feature descriptors.
Extended Compat ID
Windows uses class and subclass codes to help locate the appropriate default driver for a USB device. However, the USB Device Working Group must allocate these codes. This means that devices that implement new types of features often do not yet have appropriate class and subclass codes, so Windows cannot use the codes to select a default driver. IHVs can circumvent this problem by storing the information in firmware as an extended compat ID OS feature descriptor. Windows can then retrieve this information when the device is plugged in and use it to help determine which default driver to load. For details, see "Extended Compat ID OS Feature Descriptor Specification," which is included in this package
Extended Properties
Currently, there are two levels at which properties can be declared for a USB device: class level or devnode level. The extended properties OS feature descriptor allows a vendor to store additional properties- such as help pages, URLs, and icons-in device firmware. For details, see "Extended Properties OS Feature Descriptor Specification," which is included in this package.
Genre
This descriptor is being considered for future versions of Windows, and no specification is currently available.
Which Windows versions support Microsoft OS descriptors?
The following table shows which versions of Windows support the various descriptors:
Microsoft OS Descriptor Support
| Descriptor | Windows Version |
OS string descriptor | Windows XP SP1 and later |
Extended compat ID OS feature descriptor | Windows XP SP2 and later |
Extended properties OS feature descriptor | Windows XP SP2 and later |
Genre OS feature descriptor | Might be supported by future Windows versions |
Why must the OS string descriptor be stored at index 0xEE?
A device that supports Microsoft OS descriptors must contain an OS string descriptor, stored at string index 0xEE. The OS string descriptor is a standard USB string descriptor that serves several purposes:
| • | Its presence indicates that the device contains one or more OS feature descriptors. |
| • | It contains the data that is required to retrieve the associated OS feature descriptors. |
| • | It contains a signature field that differentiates the OS string descriptor from other strings that IHVs might choose to store at 0xEE. |
| • | It contains a version number that allows for future revisions of Microsoft OS descriptors. |
If there is no string descriptor at 0xEE, or the string descriptor at that index is not a valid OS string descriptor, Windows assumes that the device does not contain any OS feature descriptors.
Where can I find more information about Microsoft OS descriptors?
See http://www.microsoft.com/whdc/connect/usb/os_desc.mspx.
Resources
The following resources provide additional information on Windows support for USB devices.
Composite USB devices whose interfaces are not sequentially numbered do not work in Windows XP
http://support.microsoft.com/default.aspx?scid=kb;en-us;814560
Debugging Tools for Windows
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
How to enable verbose debug tracing in various drivers and subsystems
http://support.microsoft.com/default.aspx?scid=kb;en-us;314743
IsDeviceHighSpeed
http://msdn2.microsoft.com/en-us/library/ms790724.aspx
Maximum size of USB transfers on various operating systems
http://support.microsoft.com/kb/832430
Microsoft OS Descriptors Documentation
http://www.microsoft.com/whdc/connect/usb/os_desc.mspx
PLX Technology USB Debugging Cable
http://www.plxtech.com/products/NET2000/NET20DC/default.asp
Support for USB Interface Association Descriptor in Windows
http://www.microsoft.com/whdc/connect/USB/IAD.mspx
USB resources on WHDC
http://www.microsoft.com/whdc/connect/usb/default.mspx
USB 2.0 Specification
http://www.usb.org/developers/docs
Windows Hardware Developer Central
Includes the Windows Driver Kit [WDK] and the Windows Logo Kit [WLK].
http://www.microsoft.com/whdc/default.mspx