USB Frequently Asked Questions: Intermediate Level

USB Frequently Asked Questions: Intermediate Level - 1

USB Frequently Asked Questions: Intermediate Level

WinHEC 2004 Version - April 23, 2004

Abstract

This paper presents frequently asked questions from developers who are knowledgeable about developing USB devices and drivers that work with Microsoft® Windows® operating systems. Unless otherwise specified, the information in this paper pertains to Windows 2000 and later operating systems.

The current version of this paper is maintained on the Web at:

Contents

Introduction

Windows Support and USB

Is my USB 2.0 hub single-TT or multi-TT?

What characters or bytes are valid in a USB serial number?

What language identifier (LANGID) is used to extract the device’s serial number?

What language identifier (LANGID) is used in a string request on a localized build of Windows?

Does IsDeviceHighSpeed() indicate if the device is capable of Hi-Speed or if it is even connected to an EHCI host controller?

What is the maximum size of USB transfers on various operating systems?

Does Windows have requirements or guidelines for assigning numbers to multiple interfaces on a composite device?

What driver should a USB composite device load?

How do I enable debugging for USB core binaries?

What does bugcheck 0xFE mean on Windows XP and Windows Server 2003?

What features of the USB EHCI specification are not yet implemented?

What are the major restrictions imposed by Usbccgp.sys?

Does Microsoft support the Interface Association Descriptor (IAD) in Windows XP?

Does the USB stack handle chained memory descriptor lists (MDLs) in a USB Request Block (URB)?

Can a driver have more than one USB request block (URB) in one I/O request packet (IRP)?

Microsoft OS Descriptor

What is the Microsoft OS Descriptor?

What operating systems support Microsoft OS descriptors?

Why does Windows XP issue a string descriptor request to index 0xEE?

References

Disclaimer

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.

© 2004 Microsoft Corporation. All rights reserved.

Microsoft, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Introduction

Microsoft® Windows® operating systems (Windows 98 and later) include native support for devices and systems that comply with the Universal Serial Bus (USB) specification. This article provides answers to frequently asked questions from driver developers who need intermediate level details about the USB stack and features supported in USB.

This particular FAQ is for developers who are knowledgeable about USB and writing USB drivers that work with Windows operating systems. An introductory level FAQ is available at

Unless otherwise specified, the information in this paper pertains to Windows 2000 and later operating systems.

Additional documentation for USB device and driver support is available in the current version of the Windows Driver Development Kit (DDK), through the MSDN® developer program library, and on the USB Architecture and Driver Support website at

Windows Support and 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 in the USB interface descriptor indicate whether a hub is single-TT or multi-TT:

• Single-TT. bDeviceProtocol == 0x01
• Multi-TT. bDeviceProtocol == 0x02

The driver Usbhub.sys uses this setting to enable multi-TT mode or single-TT mode. On Windows XP and later operating systems, 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

What characters or bytes are valid in a USB serial number?

A USB device has 2 choices for storing serial numbers in the iSerialNumber filed (in the USB device descriptor):

• iSerialNumber == 0x00 : The USB device has no serial number
• iSerialNumber != 0x00 : The USB device has a serial number and it is stored at the string index indicated in iSerialNumber.

If the device has a serial number, Microsoft requires that the serial number 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 will distinguish one from the other.

Windows Plug and Play requires that serial numbers across multiple buses follow specified rules. Every byte in a USB serial number is checked for correctness. If a single invalid byte is found, the serial number is discarded and the device is treated as if it had no serial number.

Invalid bytes in a serial numbers are indicated below:

• Byte value less than 0x20 are invalid.
• Byte value greater than 0x7F are invalid.
• Byte value 0x2C is invalid.

For additional details on the iSerialNumber field, see section 9.6.1 of the USB 2.0 specification, which is available from the USB website at

What language identifier (LANGID) is used to extract the 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 a nonzero value. To retrieve the serial number, Windows issues a string request with the language identifier (LANGID) set to 0x0409 (U.S. English). The LANGID 0x0409 is always used by Windows operating systems, irrespective of the language of the installed version of Windows.

What language identifier (LANGID) is used in a string request on a localized build of Windows?

On a localized build of Windows, the string request sent to the device contains the language identifier (LANGID) of the user’s context. If the device does not support that LANGID, the operating system will reissue the string request in U.S. English (LANGID = 0x0409).

Does IsDeviceHighSpeed() indicate if the device is capable of Hi-Speed or if it is even connected to an EHCI host controller?

The function IsDeviceHighSpeed() returns the actual operational mode of the device in its current tree topology. If a USB Hi-Speed capable device is connected to a USB 1.1 hub or a full speed host controller, then the function will indicate that the device is working at full speed.

What is the maximum size of USB transfers on various operating systems?

On Microsoft Windows 2000, the maximum size of a USB transfer is determined by the device driver that is loaded for the USB device. The maximum size of USB transfers is determined in one of the following ways:

• When the device driver selects the configuration of the device by calling the URB_FUNCTION_SELECT_CONFIGURATION function.
• When the device driver selects an alternative interface for the device by calling the URB_FUNCTION_SELECT_INTERFACE function.

In most cases, a USB transfer on Windows 2000 has no hard-coded size limit except the limit that is defined by the client driver.

On the Microsoft Windows XP and Microsoft Windows Server™ 2003 operating systems, the maximum size of a USB transfer is defined either by the miniport driver of the USB host controller or by the USB port driver (Usbport.sys). The maximum size of a USB transfer is not defined by the client driver of the device.

If you use more than the maximum size of a USB transfer, the transfer request may fail, or a stop error may appear on a blue screen.

On Windows XP and Windows Server 2003, when the maximum size of a transfer for a bulk endpoint is less than or equal to 4 KB, the port driver splits the transaction into multiple transfers. Theoretically, this behavior makes the maximum size of a USB transfer unlimited for these endpoints.

For additional information, please refer to Microsoft Knowledge Base article 832430 (

Does Windows have requirements or guidelines for assigning numbers to multiple interfaces on a composite device?

A USB device with more than 1 interface on the first configuration is treated as a composite device. Windows XP (prior to Service Pack 2) mandates that interface numbers follow these rules:

• Interface numbers must be zero-based.
• Interface numbers must be consecutive and increasing.

Windows XP Service Pack 2 relaxed the requirement that interface numbers be consecutive by making changes to the driver Usbccgp.sys. Beginning with Service Pack 2, interface numbers need only be increasing.

For additional information about interface numbers, see Microsoft Knowledge Base article 814560 (

Alternate settings of an interface should be identified according to these rules:

• 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 is available from the USB website at

What driver should a USB composite device load?

Windows has provided support for USB composite devices since Windows 98. The driver Usbhub.sys supports composite devices on the following operating systems:

• Windows 98
• Windows 98 SE
• Windows 2000

A newer driver for composite devices, Usbccgp.sys, was released with Windows Millennium Edition (Me). Although it may still be possible to load Usbhub.sys as the parent driver for the composite device, we do not recommend it.

Usbccgp.sys supports composite devices on the following operating systems:

• Windows Me
• Windows XP
• Windows Server 2003

If you are developing drivers, you should ensure that the correct driver is loaded on the operating system for your composite device. You can do so by using the Include and Needs directives in your information file (.inf).

Include = USB.INF

Needs = Composite.Dev

An information file that incorrectly refers to Usbhub.sys as the composite device driver may, in the future, fail hardware compatibility testing.

For additional information, see the USB composite driver documentation in the Windows XP DDK or Windows Server 2003 DDK.

How do I enable debugging for USB core binaries?

To enable kernel debugging, you must:

• Obtain a checked build system or checked build USB modules
• Enable kernel debug settings per module, as 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 Microsoft Knowledge Base article 314743 (

What does bugcheck 0xFE mean on Windows XP and Windows Server 2003?

Windows XP Service Pack 1 and later operating systems provide a new bugcheck specific to USB. On a severe error, bugcheck 0xFE is generated by the USB stack to aid in quickly identifying the root cause.

Bugcheck 0xFE has four parameters. The first parameter indicates the type of error and determines how you should interpret the remaining three parameters, as shown in Table3.

Table 3. Parameters for bugcheck 0xFE

Value of parameter 1 / Meaning
INTERNAL_ERROR (0x01) / An internal error occurred in the USB stack. The Microsoft USB team must obtain the exact repro hardware to investigate the issue.
BAD_URB (0x02) / The USB client driver has submitted a USB request block (URB) that is still attached to another I/O request packet (IRP) that is still pending in the bus driver. This is the most common hardware error. USB Verifier will help identify and catch these issues.

• Parameter 2 is the IRP that is currently pending in Usbport.sys.
• Parameter 3 is a pointer to the “newest IRP,” the IRP that is currently being submitted by the client.
• Parameter 4 is a pointer to the URB that is attached to both IRPs.

MINIPORT_ERROR (0x03) / The miniport driver has generated a bugcheck. This error is usually caused by a catastrophic hardware (host controller) failure.
IRP_URB_DOUBLE_SUBMIT (0x04) / The Client driver submitted an IRP that is already pending in the bus driver. This is a common hardware error. This error can also be detected by Driver Verifier when the cancel routine is set by Usbport.sys for the transfer.
Parameter 2 is the address of the IRP that is being submitted.
Parameter 3 is the address of the URB that is attached to the IRP.
Parameter 4 not used. Its value is always zero.

For additional information about USB core stack debugging, see the latest Windows DDK and the kernel debugger documentation.

What features of the USB EHCI specification are not yet implemented?

Windows XP supports a number of features in the Enhanced Host Controller Interface (EHCI) specification, but there are a few features that are not implemented. These features may be supported in future releases:

• Features added to EHCI in or after version 0.95.
• Rebalance Lockout (I-Bit)
• Frame Span Traversal Nodes (FSTN)
• 64-bit host controller addressing support. EHCI controller can still work in 32 bit mode on an x64 or Intel Itanium platform.
• Kernel Debugging over USB 2.0.
• EHCI BIOS handoff.
• BIOS vendors should support the EHCI Bios handoff section in the EHCI Specification for all EHCI-aware BIOS
• Preliminary support for EHCI BIOS handoff will be available in Windows XP Service Pack 2. The Windows core team for USB would like to work with OEM partners and BIOS vendors to develop this functionality.

What are the major restrictions imposed by Usbccgp.sys?

Here are the major restrictions imposed on hardware devices and drivers by Usbccgp.sys:

• Usbccgp supports only the default configuration (config0).
• There is currently no support for Selective Suspend in Usbccgp. This feature may be supported in future versions of Windows.
• The interface association descriptor (IAD) in Usbccgp is supported only in Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1 and later.
• Nonconsecutive interface numbers are supported only in Windows XP SP2 and Windows Server 2003 SP1 and later.

Does Microsoft support the Interface Association Descriptor (IAD) in Windows XP?

Yes. The recent USB 2.0 Interface Association Descriptor (IAD) Engineering Change Notification (ECN) introduced a new standard method in the USB device framework for describing a grouping of interfaces and their alternate settings within a function. IAD can now 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 will have support for IAD:

• Windows XP Service Pack 2
• Windows Server 2003 Service Pack 1
• The next client version of Windows, codenamed “Longhorn”

For additional information on IAD, see “Support for USB Interface Association Descriptor in Windows” at

Does the USB stack handle chained memory descriptor lists (MDLs) in a USB Request Block (URB)?

No. This functionality is not supported in the USB stack.

Can a driver have more than one USB request block (URB) in one I/O request packet (IRP)?

No. This functionality is not supported in the USB stack.

Microsoft OS Descriptor

What is the Microsoft OS Descriptor?

The Microsoft OS descriptor is a set of data structures that IHVs can use to include extra information in device firmware, information that Microsoft OS Descriptor enabled applications and operating systems can extract. The data is extracted by vendor-specific USB requests to the device as indicated in the OS Descriptor specification. The information retrieved will provide the operating system and/or applications with additional information about the device and its special features.

The Microsoft OS descriptor is composed of two or more segments:

• One Microsoft OS string descriptor
• One or more Microsoft OS feature descriptors

The Microsoft OS string descriptor is a special string that is embedded at a fixed string index. The string descriptor informs the operating system of the presence of one or more Microsoft OS feature descriptors, along with details on how to extract these descriptors.

The Microsoft OS feature descriptors use a fixed format defined by Microsoft.

For additional information about the Microsoft OS descriptors, please visit

What operating systems support Microsoft OS descriptors?

The following is a list of Microsoft Windows operating systems that support the Microsoft OS Descriptor:

• Windows XP (starting with Service Pack 1)
• Windows Server 2003
• The next client version of Windows, codenamed “Longhorn”

Why does Windows XP issue a string descriptor request to index 0xEE?