Microsoft Windows USB Core Team Blog

List of the latest USB hotfixes for each Windows version

Hello, my name is Don Miller.  I am a software developer on the Windows USB team.  In this post my goal is to provide a USB end-user with a way to view the most recent USB public hotfixes for the below Windows releases:

Windows 2000 Service Pack 4

Windows XP Service Pack 3

Windows 2003 Service Pack 2

Windows Vista Service Pack 2

Windows 7 RTM

As most Windows users know, Microsoft releases public hotfixes for various Windows components after a new Windows version or service pack is released.  A hotfix will contain a fix to a specific problem found in that Windows component.  Multiple hotfixes can occur to the same Windows component over a period of time and it can be confusing to know what fixes have occurred for a specific Windows USB component.   Each Windows hotfix has a version assigned to it in order for the hotfix installer to not install older versions of a Windows USB component over the top of a newer version.  A newer version hotfix will contain all the previous version's fixes meaning that a USB end-user will only have to install the latest hotfix version for a Windows component and have all the fixes done for that Windows component relative to the Windows OS version. 

If a USB end-user is experiencing a USB issue, he/she can look at the below list and see if any of the KB's description of the issue is similar to what he/she is experiencing.  If a KB description matches then a USB end-user can download the hotfix the KB references and see if the issue is resolved.  The below list will list all the public hotfixes to each USB core component in release date order for the above Windows releases.  Note that for best results, for example, if you are running Vista Service Pack 1, you will need to download install Vista Service Pack 2 from http://www.microsoft.com/downloads/en/default.aspx before installing any of the Vista Service Pack 2 hotfixes.  The same recommendation applies to all the other above Windows releases.  Also, the best time to use the below list is when a USB end-user is troubleshooting a USB issue.  If a USB end-user's system is running fine it is recommended that the USB end-user not install any USB hotfixes.

Note: WINUSB.SYS became a Windows inbox driver starting with Vista.

Why is my USB device not detected or comes up as "Unknown Device"?

Hi, this is Martin Borve from the USB team. In the previous blog, I gave a detailed description on how the device gets enumerated by the core USB stack and reported to the OS. In this post, I'm going to summarize which incorrect hardware behaviors during enumeration causes the core stack to abandon the device and which ones lead to reporting the device as "Unknown Device". 

Device is not enumerated

There are several reasons why a USB device may not enumerate at all when it is attached to a USB port.  Assuming the connect change was detected by the USB hub driver, the following events will cause the device to not be enumerated at all:

• The USB device failed to stabilize during the debounce period.
• An overcurrent event occurred during enumeration.
• A port disconnect event occurred during enumeration.
• The port is reported as suspended after a successful port reset.

“Unknown Device” in Device Manager due to Enumeration failure

In most cases when enumeration fails the hub driver will still report the arrival of a device to Windows.  In these cases the USB device will appear as “Unknown Device” in Device Manager, and will have a Device ID of “USB\VID_0000&PID_0000” and a Hardware ID and Compatible ID of “USB\UNKNOWN”.   The following events will cause the USB hub driver to enumerate a USB device as an “Unknown Device”:

• A port reset request timed out during enumeration.
• The Set Address request for the USB device failed.
• The request for the USB device’s Device Descriptor request failed.
• The USB Device Descriptor was malformed and failed validation.
• The request for the Configuration Descriptor failed.
• The USB Configuration Descriptor was malformed and failed validation.

On Windows 7, devices that failed enumeration will be marked with failure Code 43 in the device manager. 

On downlevel OS, namely Vista, the device manager may not have a failure code. So the way to detect enumeration failure is to look at the Hardware ID in the detail property page (right click on the device and select Properties and then look click on Details tab) of the device in the device manager. If the ID is USB\VID_0000&PID_0000 then the failure is during enumeration.

“Unknown Device” in Device Manager due to Unavailable driver

There is a second reason why a device would come up as "Unknown Device" in the device manager even if the enumeration was successful. This happens when the device doesn't provide a Product ID string during enumeration and the system is not able to find a matching INF for the device to install a driver. In this case, the device will be marked with failure Code 28 in the device manager.

You may be able to get the driver downloaded and installed from the Windows Update site by right clicking on the device in the device manager and selecting "Update Driver Software" option and then selecting "Search automatically for updated driver software."

How does USB stack enumerate a device?

Hello, my name is Martin Borve.  I am a software developer on the Windows USB team.  In this post I will provide a detailed description of the enumeration process used by the Windows 7 core USB driver stack - from the point the stack detects a presence of device to the point it indicates to the PnP manager that a new device has arrived.

Device enumeration for a USB port begins when the hub indicate a connect status change via the hub’s interrupt endpoint.  If the port status indicates a newly connected device, the USB hub driver will use the following sequences of steps to enumerate the device:

1. Port Stabilization Debounce
2. First Port Reset
3. First Device Descriptor Request
4. Second Port Reset
5. Set USB Address
6. Second Device Descriptor Request
7. Configuration Descriptor Request
8. MS OS Descriptor Query
9. Serial Number String Descriptor Query
10. MS OS Extended Configuration Descriptor Request
11. MS OS Container ID Descriptor Query
12. Language ID Query
13. Product ID String Query
14. Device Qualifier Descriptor Query
15. Duplicate Device Detection
16. Report New Device to PnP Manager

Let us find out in detail how the software stack interacts with the device in each of these steps by describing which hardware events are handled, which ones are ignored, how long the software waits for the next event to occur, when does the software attempt reenumeration, how many times it reattempts, what constitutes a broken device, what leads to enumeration failure, etc.

The steps 1 through 7 are required for the device to be enumerated and reported to the system. In the next blog post, I will summarize all the hardware issues during enumeration that can either cause the software stack to not report the device at all or report to the system as “Unknown Device” by providing  “USB\VID_0000&PID_0000” as the Device ID.

NOTE: Enumeration information provided here applies to 1.1 and 2.0 devices. The sequence and timing of various operations may change for 2.1+ and 3.0+ devices.

Port Stabilization Debounce

The hub driver must observe a period of at least 100ms where there are no port connect changes (USB 2.0 spec, 7.1.7.3, TATTDB).  If the port has not stabilized after 200ms, the hub driver will disable the port and cancel enumeration.  No device will be reported to PnP.

First Port Reset

Once the port debounce has completed successfully, the hub driver will issue a reset request for the port.  In normal operation this will result in the port status transitioning to a connected and enabled state, and the device itself will respond to the default USB address of 0.

Port resets of all USB devices are serialized via an “enumeration lock” on a per host controller basis, as only one USB device can be enabled with the default USB address 0 at a any one time.  The hub driver will acquire the enumeration lock prior to issuing the first port reset request, and will release it when the device has been assigned a non-default USB address, or when enumeration has been cancelled.  The hub driver uses a 5 second timeout for the port reset request in case it never completes.

While waiting for the first port reset to complete, the hub driver must be able to deal with the following events:

Device Disconnect

Enumeration is cancelled.   No device is reported to PnP.

Overcurrent Change

Enumeration is normally cancelled in this case, unless the over-current is determined to be spurious.  No device is reported to PnP.

Timeout of Port Reset

In the case of a timeout of the first reset request, the hub driver will attempt to retry enumeration up to 3 times by returning to the beginning of the “First Port Reset” state.  A delay of 500ms occurs between each retry to allow the device to settle.  If the port reset times out on the 3rd retry, enumeration will be cancelled and an “Unknown Device” will be reported to PnP.

If the port reset request completes successfully, the hub driver will proceed based on the current port state as follows:

Device Disconnected

Enumeration is cancelled.  No device is reported to PnP.

Port Connected and Disabled

Port reset completion is ignored.  Reset timeout will be allowed to run, and port reset will be retried as appropriate.

Port Connected and Suspended

Enumeration is cancelled. No device is reported to PnP.

Port Overcurrent

Port reset completion is ignored. Reset timeout will be allowed to run, and port reset will be retried as appropriate.

Port Enabled and Connected

This indicates a successful reset of the port.  The hub driver delays at least 10ms to allow for reset recovery (USB 2.0 spec, 7.1.7.3, TRSTRCY).  The hub driver moves to the “First Device Descriptor Request" state.   

First Device Descriptor Request

The USB driver stack issues a request for the USB Device Descriptor (GET_DESCRIPTOR for Descriptor Type DEVICE), using the default USB address of 0, and a maximum packet size of 8 bytes for low-speed devices and 64 bytes for full and high-speed devices.

This descriptor request is used solely to determine the correct maximum packet size for the default control endpoint, as specified in the Device Descriptor’s bMaxPacketSize0 field at offset 7.  USB devices are required to return at least the first 8 bytes of the Device Descriptor when they are at the default USB address (USB 2.0 spec, 5.5.3).

When requesting the device descriptor the hub driver will specify a transfer size of 64 bytes.  This is done because some older USB devices will behave badly if the request size is smaller.  We’ve also found some USB devices will babble when returning the device descriptor, but will still return valid data in at least the first 8 bytes.  For this reason transfer errors will be ignored if at least 8 bytes of data were returned by the device. 

If the request for the device descriptor fails, the hub driver will retry enumeration up to three times by returning to the “First Port Reset” state.  If the hub driver has already retried enumeration 3 times, enumeration will be cancelled and an “Unknown Device” will be reported to PnP.

If the device descriptor request succeeds, the hub driver will move to the “Second Port Reset” step.  All further control transfers for the default endpoint will use the maximum packet size specified in the Device Descriptor. 

Second Port Reset

In the early days of USB some USB devices would become confused by a second request for the Device Descriptor if they did not return the complete Device Descriptor for the first request.  To allow these devices to enumerate successfully it was necessary to reset the port between the first and second requests for the Device Descriptor.

The hub driver uses a 5 second timeout for the second port reset request in case it never completes.  While waiting for the second port reset to complete, the hub driver must be able to deal with the following events (this is essentially identical to the handling in the first reset request):

Device Disconnect

Enumeration is cancelled.   No device is reported to PnP.

Overcurrent Change

Enumeration is cancelled.  No device is reported to PnP. 

Timeout of Port Reset

In the case of a timeout of the second reset request, the hub driver will attempt to retry enumeration up to 3 times by returning to the beginning of the “First Port Reset” state.  If the port reset times out on the 3rd retry, enumeration will be cancelled and an “Unknown Device” will be reported to PnP. 

If the port reset request completes successfully, the hub driver will proceed based on the current port state as follows:

Device Disconnected

Enumeration is cancelled.  No device is reported to PnP.

Port Connected and Disabled

Port reset completion is ignored.  Reset timeout will be allowed to run, and port reset will be retried as appropriate.

Port Connected and Suspended

Enumeration is cancelled. No device is reported to PnP.

Port Overcurrent

Port reset completion is ignored. Reset timeout will be allowed to run, and port reset will be retried as appropriate.

Port Enabled and Connected

This indicates a successful reset of the port.  The hub driver delays at least 10ms to allow for reset recovery (USB 2.0 spec, 7.1.7.3, TRSTRCY).  The hub driver moves to the next enumeration state “Set USB Address".  The hub driver will delay 100ms after successfully resetting the port if enumeration had to be retried at least once. 

Set USB Address

The USB driver stack allocates a unique (per-controller) USB device address and issues a SET_ADDRESS request to the device.  If the SET_ADDRESS request fails or times out, enumeration is cancelled and an “Unknown Device” is reported to PnP.

If the SET_ADDRESS is successful, the hub driver will wait for at least 10ms to allow for device stabilization before moving to the “Second Device Descriptor Request” state. 

Second Device Descriptor Request

The USB driver stack will issue a second request for the full USB Device Descriptor (GET_DESCRIPTOR for Descriptor Type DEVICE).  If the request fails or times out, the port is disabled and enumeration is retried by returning to the “First Port Reset” state.  If the hub driver has already retried enumeration 3 times, enumeration is cancelled and an “Unknown Device” is reported to PnP.

Upon successful completion of the second request for the Device Descriptor, the hub driver will validate the Device Descriptor as follows:

• The bLength field is equal to or greater than the size of a USB Device Descriptor, as defined in the USB 2.0 specification.
• The bDescriptorType field is equal to descriptor type DEVICE (1).

If the validation fails, the port is disabled and enumeration is retried by returning to the “First Port Reset” state.  If the hub driver has already retried enumeration 3 times, enumeration is cancelled and an “Unknown Device” is reported to PnP.

Upon successful validation of the Device Descriptor, the hub driver will cache the descriptor, release the enumeration lock, and move to the “Configuration Descriptor Request” state. 

Configuration Descriptor Request

The USB driver stack will issue a request for the device’s USB Configuration Descriptor (GET_DESCRIPTOR for Descriptor Type CONFIGURATION).  For compatibility reasons the configuration descriptor request will specify a length of 255 bytes.

If the Configuration Descriptor request completes with an error or times out, the hub driver will disable the port and retry enumeration by returning to the “First Port Reset” state.  If the hub driver has already retried enumeration 3 times, enumeration is cancelled and an “Unknown Device” is reported to PnP.

If the Configuration Descriptor request completes successfully, the hub driver will verify that the number of bytes returned for the request is greater than or equal to the Configuration Descriptor’s wTotalLength value.  If it is not greater than or equal to wTotalLength, the hub driver will retry the Configuration Descriptor request once to insure the device is not returning invalid data in the descriptor.

Upon successful completion of the Configuration Descriptor request, the USB driver stack will validate the descriptor as follows:

• The bLength field is equal to or greater than the size of a USB Configuration Descriptor, as defined in the USB 2.0 specification.
• The bDescriptorType field is equal to descriptor type CONFIGURATION (2).

If the validation fails the hub driver will disable the port and retry enumeration by returning to the “First Port Reset” state.  If the hub driver has already retried enumeration 3 times, enumeration is cancelled and an “Unknown Device” is reported to PnP.

If the validation is successful, the Configuration Descriptor is cached and the hub driver moves on to the “MS OS Descriptor Query” state. 

MS OS Descriptor Query

Microsoft has defined a set of vendor specific USB descriptors called Microsoft OS Feature Descriptors, which are queried for at the time of device enumeration. 

If the USB Device Descriptor’s bcdUSB field is equal to 0x0100 or 0x0110, the hub driver will skip the query for the MS OS Descriptor and move to the “Serial Number String Descriptor Query” state.

If the hub driver has never before enumerated a device with the same VID/PID/Revision as the device being enumerated, it will query the device for the MS OS String Descriptor (GET_DESCRIPTOR for Descriptor Type STRING), which uses index 0xEE.  It will specify a language ID of 0x00.

If the device returns an MS OS Descriptor, the hub driver will validate the descriptor as follows:

• The MicrosoftString field must be equal to “MSFT100”.

Once validated, the value in the descriptor’s bVendorCode field will be stored in the registry on a per VID/PID/Revision basis, under the USBFLAGS registry subkey in the “osvc” registry value.  Subsequent enumerations of any device with the same VID/PID/Revision will read the bVendorCode from this registry value rather than querying the device.
The hub driver will then move to the “Serial Number String Descriptor Query” state. 

Serial Number String Descriptor Query

If the USB Device Descriptor reports a non-zero serial number string index, the hub driver will query for the serial number string descriptor (GET_DESCRIPTOR for Descriptor Type STRING) using the American English language ID (0x409) and the serial number string index.  
The hub driver performs the following validation on all string descriptors:

• The number of bytes returned for the request must be greater than or equal to the bLength field.
• The number of bytes returned for the request must be greater than or equal to the bLength field.
• The bLength field must be larger than 2 bytes.
• The bDescriptorType field must be equal to descriptor type STRING (3).
• The bLength field must be an even number, as the string is a Unicode string.

If this validation passes, the hub driver performs the following validation specifically for the serial number string descriptor:

• The string is non-NULL.
• The string is not longer than 255 bytes.
• The descriptor type returned in the descriptor is type STRING.
• The number of bytes in the string is an even number, as it’s a Unicode string.
• The string does not contain any invalid characters:
  • The character must have a value greater than or equal to 0x20.
  • The character must have a value less than or equal to 0x7F.
  • The character must not be a comma (‘,’=0x2C).

If any of the above validation fails the serial number will be discarded, otherwise it will be cached.

Regardless of the results of the serial number query and validation, the hub driver will move on to the “MS OS Extended Configuration Descriptor Request” state if the device supports the MS OS Descriptor, otherwise it will move to the “Language ID Query”. 

MS OS Extended Configuration Descriptor Request

If the device is not a composite device the hub driver will issue a request for the MS OS Extended Configuration Descriptor.

Software will issue an initial request for this descriptor by specifying a data size equal to the descriptor’s header.  This will be used to determine the existence of the descriptor, and to determine its size.  If the request is successful the hub driver will validate the header as follows:

• The returned number of bytes must be equal to the defined size of the header.
• The binary-coded decimal header version field must be 1.00.
• The header’s wIndex field must be set to 4.
• The header’s bCount field must be non-zero.
• The header’s dwLength field must be equal to the size of the header, plus the value of the bCount field times the size of the configuration descriptor’s function structure.

Once the descriptor header is validated, the hub driver will re-issue the request for the descriptor using the size of the entire descriptor as returned by the device in the descriptor’s header.

If a device successfully returns an MS OS Extended Configuration Descriptor, the hub driver will validate the descriptor as follows:

• The standard USB configuration descriptor will be parsed for functions described by Interface Association Descriptors and single-interface functions to determine the total number of functions on the device.
• The following validation will be performed on the MS OS Extended Configuration Descriptor Header:
  • The header’s dwLength value must be greater than or equal to the size of the header structure.
  • The header’s dwLength value must be less than or equal to the size of the header plus 256 Extended Configuration Descriptor functions.
  • The header’s dwLength value must be less than or equal to the number of bytes returned by the device for the descriptor.
  • The header’s wIndex value must equal 4, the MS Extended Configuration Descriptor Index.
  • The header’s bCount value must be less than or equal to the number of functions that were found in the USB Configuration Descriptor.
  • The header’s dwLength value must be greater than or equal to the size of the header structure plus the header’s bCount times the size of the Extended Configuration Descriptor Function structure.
• The following validation will be performed on each function descriptor:
  • bFirstInterfaceNumber is less than or equal to 256.
  • bFirstInterfaceNumber corresponds to the first interface of a function described by an Interface Association Descriptor or a single-interface function in the device’s USB Configuration Descriptor.
  • The CompatibleID string only contains upper-case ASCII characters(“A”-“Z”), numbers(“0”-“9”), and/or  the underscore character (“_”).
  • The SubCompatibleID string only contains upper-case ASCII characters(“A”-“Z”), numbers(“0”-“9”), and/or  the underscore character (“_”).
  • The number of function descriptors must be equal to the bCount value in the header.

Software will move to the “MS OS Container ID Descriptor Query” state. 

MS OS Container ID Descriptor Query

Windows 7 introduces the concept of a Container ID, which is used to group all functions that are part of a physical device.  For details on how USB generates Container IDs, please refer to this whitepaper.

If the VID/PID/Revision of the device has been previously flagged as not supporting the Container ID Descriptor via the registry, the hub driver will move to the “Language ID Query” state.

If neither the hub descriptor nor the ACPI namespace describes the device as non-removable, and the device supports the MS OS Descriptor, the USB stack will query the device for the MS OS Container ID, otherwise the hub driver will move to the “Language ID Query” state.

A device must indicate support for the container ID by setting bit 1 of the bFlags flag of the MS OS Descriptor.  If this bit is set, software will issue a request for the MS OS Container ID Descriptor header.  The setup packet will specify a wIndex of 6, and the Device as the recipient.  If a descriptor is successfully returned, the hub driver will validate the descriptor as follows:

• The returned number of bytes must equal the size of the MS OS Container ID Descriptor header.
• The MS OS Container ID Descriptor header’s bcdVersion must be 0x100.
• The MS OS Container ID Descriptor header’s wIndex must be 6.
• The MS OS Container ID Descriptor header’s dwLength must be equal to the size of a MS OS Container ID Descriptor.

If the header is successfully validated, software will issue a request for the entire MS OS Container ID Descriptor.  The setup packet will again specify a wIndex of 6, and the Device as the recipient.

If the descriptor is successfully returned, the hub driver will validate the descriptor as follows:

• The returned number of bytes is equal to the defined size of the MS OS Container ID Descriptor
• The Container ID is not all zeros.

If the request for the Container ID Descriptor fails for any reason, a registry value will be set to indicate the hub driver should skip this request in future enumerations of devices with the same VID/PID/Revision.  The hub driver will then disable the port and retry enumeration by returning to the “First Port Reset” state.  If the hub driver has already retried enumeration 3 times, enumeration is cancelled and an “Unknown Device” is reported to PnP. 

Language ID Query

The USB hub driver will query the device for the array of supported language IDs.  The hub driver will issue a query for the string descriptor at index 0, which is an array of 2-byte LANGID codes supported by the device, as defined in section 9.6.7 of the USB 2.0 specification.

The hub driver will perform standard string descriptor validation on the Language ID string descriptor, as described previously in the description of the “Serial Number String Descriptor Query” state.  If the string is found to be valid, the hub driver will cache the data returned in the string.  It will then move to the “Product ID String Query” state. 

Product ID String Query

If the USB Device Descriptor’s iProduct field is non zero the hub driver will issue a request for the Product ID string using the string index specified in the iProduct field and the English language ID of 0x409.

If the string descriptor request completes successfully, the hub driver will perform standard string descriptor validation on the Product ID string descriptor.  If the validation is successful, the hub driver will cache the string. It will then move to the “Device Qualifier Descriptor Query” state. 

Device Qualifier Descriptor Query

If the device is attached to a USB 1.1 hub, is operating at Full-Speed, and its USB Device Descriptor bcdUSB field is greater than or equal to 0x200, the hub driver will issue a GET_DESCRIPTOR for descriptor type DEVICE_QUALIFIER (6). 

The successful completion of the request indicates the device can support USB 2.0 high-speed operation.   

Duplicate Device Detection

The USB driver stack must deal with an artifact of the EHCI companion controller design where a device can move quickly between the USB 2.0 EHCI host controller and a companion USB 1.1 controller when the USB 2.0 controller is enabled or disabled.  This creates a scenario where the new instance of a USB device can be reported to the PnP Manager before its previous instance on the other host controller had been reported as removed to PnP Manager.  This results in a bugcheck if the device has a serial number, as PnP Manager would see two device nodes reporting the same unique instance IDs.  This behavior can also occur when a USB device is moved to a different port while the system is suspended.

The USB hub driver maintains a list of all USB devices currently attached to the system and have been reported to the PnP Manager. If the currently enumerating device has a serial number, software will search this list for any device that has the same vendor ID, product ID, revision number, and serial number.  If no matching device is found, the hub driver will move to the “Report New Device To PnP Manager” state.

If a matching device is found the hub driver will handle it based the following logic:

1. If the matching device and enumerating device are on the same port, it is a case where the device quickly detached/re-attached (possible a spurious connect change).  No action is taken, as the previous instance will be reported as removed at the same time the new instance is reported as arrived to PnP Manager.
2. If the matching device is detected as being no longer physically present, software will delay 5 seconds, waiting for the matching device to be reported to PnP Manager as removed.  If the matching device is not reported as removed at the end of the delay, the port is disabled and enumeration is retried by returning to the “First Port Reset” state.  If software has already retried enumeration 3 times, the port is disabled and enumeration is cancelled.  No device will be reported to PnP Manager.
3. If the matching device is still physically present, it is a case of two identical devices with the same serial number.  In this case the serial number for newly enumerated device will be discarded, to prevent PnP Manager from triggering a bugcheck.

Report New Device to PnP Manager

At this point the USB device has been successfully enumerated and the hub driver will report the new device to PnP.  This involves calling IoInvalidateDeviceRelations and reporting then new device when handling IRP_MN_QUERY_DEVICE_RELATIONS/BusRelations.

How can I fix a device that doesn't work after system resume?

Hi, this is Vivek Gupta again from the USB team. In my last post on whether devices get reset on system resume, I talked about how some devices might get negatively impacted by the behavioral changes in USB core stack in Windows7. To make it easier for users to fix such devices, we have extended the new Windows7 device stage troubleshooting functionality. Let us find out how to use the troubleshooter.

This USB Troubleshooter is built on the Windows Troubleshooting Platform. If a user is having a problem with a USB device after the system resumes from sleep, he or she can choose to troubleshoot the device through the Devices and Printers UI (Detailed steps provided at the end). This will invoke our USB Troubleshooter which will, based on some heuristics, put the device on the list of devices that need reset on resume. From that point on, whenever the system resumes from sleep, the device will be always be reset and should start working. It should be noted that the decision to apply the reset behavior on a device is based on a certain heuristic method. Therefore it is recommended that the user should troubleshoot a device only if he or she is actually experiencing problems with the device.

To launch USB Troubleshooter on a device, Open Devices and Printers by clicking the Start button and then, on the start menu, clicking Devices and Printers. Then right-click on the target USB device, and click Troubleshoot. USB Troubleshooter, along with any other applicable device troubleshooters, will automatically get downloaded and launched; wait for the Troubleshooter to finish. When it finishes, it will inform you if it applied the reset on resume behavior change on the device. Note that the system needs to be online and configured to get the latest online troubleshooters. By default, the system should already be configured in this manner. This can be verified by clicking the start button and then, on the start menu, searching and clicking Troubleshooting. On the bottom of the page, the checkbox to get the latest troubleshooters should be set.

Do USB devices get reset on system sleep resume?

Hi, my name is Vivek Gupta. I am a developer on the USB team. In this article, I am going to discuss a behavioral change introduced in Windows7 USB core stack and how it affects USB devices.

Old behavior: In Vista RTM, when the system resumed from sleep, the USB stack used to reset the host controller, thereby resetting the whole bus. All USB devices went through the process of USB re-enumeration that involves resetting the device and configuring it again. This behavior has certain disadvantages. Since there could be only one device at address 0 at a time, this enumeration has to be serialized for all USB devices on the bus. This significantly increases the time it takes for USB devices to be available after system resume. We have also seen that resetting the host controller can also lead to an illegal SE1 signal state on some host controllers, which in turn can cause some USB devices to hang or drop off the bus. Moreover, devices cannot maintain any private state across sleep resume as that state will be lost on reset.

New behavior: Because of these disadvantages, it was decided to change the stack behavior so as to not do the bus wide reset on system resume, except in some special circumstances. In Vista SP1, the new behavior was implemented but was configurable by OEMs and most of the OEMs chose the old behavior. In Windows7, the requirement to support the new behavior was hardened. Consequently USB devices in Windows7 will not be reset on system resume, unless the device lost power during sleep cycle.

Testing devices for new behavior: Therefore it is very important that IHVs and OEMs should test their devices for the new stack behavior, in addition to the old behavior. One thing to note is that on upgrade from Vista SP1 to Windows7, the old behavior is maintained. So if a system was configured for bus wide reset on Vista SP1, it will still be configured to do the bus reset after the upgrade. Therefore for testing the new behavior, the system should have a clean install of Windows7. The device should be tested on resume from S3 as well as resume from hibernation. When I say device should be tested, I mean testing the actual end-to-end functionality of the device. Looking at just the PNP state of the device is not sufficient; we have seen cases where the device is not operational even though the device manager does not report a problem. We have also seen devices where their control endpoint is working after system resume but their other endpoints are not - therefore devices should be thoroughly tested after sleep resume cycle. Also note that even though the new behavior allows devices to maintain private state across sleep resume, devices (and their drivers) should use any such state only as an optimization and should always be able to deal with the loss of that state.

Existing devices needing reset: Even though the new behavior will be good for the ecosystem in the long term, it might have a negative impact on a small set of existing devices that have started depending on always getting a reset on system resume. In our extensive testing, we have found only a handful of such devices. These devices might stop working after system resumes from sleep and will only start working after user plugs them out and plugs them back in. To work around this problem, the USB stack maintains a list of such devices i.e. devices that are known to not work on system resume without a reset. These devices are selectively reset on system resume. But we do realize that this list may not be exhaustive; there might be devices that are not on the list but require a reset on system resume. To provide a way to mitigate the effect of this behavior on user experience, we just released the first version of USB Troubleshooter. I will talk about it more in my next post.

What's the difference between USBSAMP and OSRUSBFX2 sample?

Hi, this is Qiang Qiu again from USB core test team. Last week, I wrote about how to get started with USB driver development and gave an overview of highly used samples in the WDK. In this article, I'm going to list out the features side-by-side of two most important KMDF based USB samples, namely USBSAMP and OSRUSBFX2. My hope is that this will enable you to decide which sample to follow as a reference for your driver development.  I have listed couple of frequently asked questions about these samples at the end of this article.

FAQ: 

Question: What is Maximum Transfer Size of USBSAMP and OSRUSBFX2 sample driver? Is it possible to change their sizes?

Answer: Technically, from the device point of view, you could submit reads of any size. For writes, you can also submit larger as long as the reads are submitted before the writes complete, otherwise the writes will block as device NAKs when its buffer is full.

The maximum transfer size of USBSAMP is set by 65536 because it was originally designed with the i82930 test board's which is limited by a 64KB circular buffer. You can change the size of "MaximumTransferSize" for your device in usbsamp.inf as below and rebuild your driver package.

[usbsamp.AddReg]

HKR,"Parameters","MaximumTransferSize",0x10001,65536

The maximum transfer size of OSRUSBFX2 is also 65536 (64*1024). It is set in the file orusbfx2.h:

#define TEST_BOARD_TRANSFER_BUFFER_SIZE (64*1024)

You can change this value as you expected.

Question: What I/O types are supported in USBSAMP? How do I change the I/O types? Is bulk and isochronous transfer supported in both direct and buffered I/O types in this sample?

Answer: There is a compile switch "-DBUFFERED_READ_WRITE = 1" for buffered I/O in USBSAMP's build source file as below:

C_DEFINES= $(C_DEFINES)

#-DBUFFERED_READ_WRITE=1

It is commented out so that USBSAMP is doing direct I/O for Reads and Writes by default. Developer can uncomment this switch to do buffered I/O for Reads and Writes.

Please NOTE that USBSAMP can do isochronous transfer only if the I/O type is set as direct I/O in this sample.

Getting Started with USB Driver Development

Hi, my name is Qiang Qiu. I work for USB core test team. I write USB device drivers and services to test USB core stack with DSF simulated EHCI controller, hub and different types of devices. I enjoy working on device drivers. In this article, I'm going to provide a roadmap to getting started with USB driver development.

1. Obtain and Install the latest WDK and debugging tools

To build a driver, you must install WDK which contains the resources, libraries, tools, documentation that you need to develop WDF driver. Go to WHDC web site to obtain and install latest version of WDK and debugging tools.

To debug WDM and KMDF kernel drivers, two computers are needed: One to host the debugger and another to host the driver that is being debugged. This page will tell you how to setup kernel mode debug environment.

To debug UMDF drivers, the debugger and driver can be run either on the same computer or on two separate computers. This page will tell you how to setup user mode debug environment.

2. Choose which framework to use for your driver: WinUSB, UMDF, KMDF or WDM

There are several different ways to interact with a USB device. You can either write your own driver or use Microsoft provided generic USB driver called WinUSB.

WinUSB includes the WinUSB kernel-mode driver winusb.sys, which is an integral part of WDF user-mode driver framework (UMDF) support for USB drivers, and the WinUSB user-mode dynamic link library Winusb.dll. For USB devices that are accessed by only a single application, developers can often install WinUsb.sys as their device's function driver instead of implementing a custom driver. If you manage your device with user-mode software, WinUSB will cost you less time, effort and expense devoted to driver development. Driver with WinUSB is likely to cause less system errors which improve the customer experience, is easier to manage power, brings less security threat because user mode driver can not sniff data at kernel level, and is easier and smaller to update driver package. WinUSB would be the easiest and best approach except if your driver want to do data streaming through isochronous endpoints or the functions you want to implement already have kernel-mode support in the Windows operating system (such as modem functions which is supported by TAPI or LAN functions which is supported by NDIS).

The new Windows Driver Framework provides User-Mode Driver Framework (UMDF) library for user mode driver development and Kernel-Mode Driver Framework (KMDF) library for kernel mode driver development. UMDF and KMDF implement the same conceptual driver programming model with different components, device driver interfaces (DDIs), and data structures.

If the WinUSB driver can not meet your driver requirement, try UMDF next. UMDF provides a unified model that can work across device classes and integrates tasks handling for installation, Plug and Play (PnP) and power management. It supports protocol device classes such as cameras and portable music players.

KMDF should be used only if UMDF or WinUSB don't solve your purpose. KMDF framework is a library communicating with the operating system by using WDM interfaces. It provides interfaces simpler than WDM interface and handles many operations such as Plug and Play (PnP) and power management that must be handled by WDM drivers themselves. It also provides much of the synchronization code that is required for multiprocessor environments.

There is a common misunderstanding that miniport drivers such as NDIS or AVSTREAM cannot be written using KMDF. This WinHEC presenation provides more detail on how to use KMDF in miniports. Using KMDF provided USB I/O Target interfaces to interact with your USB device from an NDIS or AVSTREAM miniport is the best way to create a simple, robust driver.

WDM driver uses a set of interfaces to communicate directly with kernel-mode Windows components such as I/O manager and the Plug and Play (PnP) manager. WDM drivers are difficult to write, complex, less robust, and should not be written unless absolutely necessary.

This page will further help you choose a driver model based on the device class.

3. Check system requirements for your driver

You can develop WinUSB and UMDF drivers for Windows XP and later versions of Windows (not including Windows Server 2003). You can develop and build KMDF drivers for Windows 2000 with Service Pack 4 and later versions of Windows. You can develop WDM drivers for any version of Windows.

4. Obtain a test device

• In most cases, the developer for a new driver will be given a device and/or a specification for a device and told to write a driver for it. If the device is just in prototype development phase, it will be helpful to use below Device Simulation Framework (DSF) to build a simulator following the specification for development and testing purposes.
• OSR Learning Kits has all the required hardware specifications to implement a driver. It can be obtained from http://www.osronline.com/. OSR Learning Kits is the best actual hardware to study USB samples in WDK.
• You can use the Device Simulation Framework (DSF) which is a part of WDK for USB Devices to test your driver (Choose install it during WDK installation). DSF only uses software to simulate USB devices, so that you do not need any special hardware. DSF has already created some sample USB Device Simulators such as HID Generic Device, Loopback Device, Audio Device and Keyboard Device. You can use them directly if you install DSF on your computer. There is an instruction to guide you to test your USB driver with a USB Device Simulator.

5. Reference samples from the WDK

• WinUSB Samples

The most comprehensive documentation for how to use WinUSB to access a USB device is this whitepaper "How to USB WinUSB to communication with a USB Device". For sample code, refer below UMDF Fx2_Driver sample.

• UMDF Samples

UMDF Driver Skeleton Sample: This sample demonstrates how to use UMDF to write a basic driver. It is a starting point for implementing a function driver.

Fx2_Driver: This sample demonstrates how to use UMDF to create a driver to perform bulk and interrupt data transfers with OSR USB Fx2 Learning Kit.

• KMDF Samples

OSRUSBFX2: This sample is a step by step tutorial to demonstrate how to create a KMDF driver to perform bulk and interrupt data transfers to an USB device with OSR USB Fx2 Learning Kit. If you are new to KMDF driver, this sample is the best one to start with.

USBSAMP: This sample demonstrates how to perform bulk and isochronous data transfers to a generic USB device.

In the next blog post, I will describe the difference between OSRUSBFX2 and USBSAMP samples.

HIDUSBFX2: This sample demonstrates how to write a HID minidriver in which a non-HID USB device is mapped to a HID device.

Toaster -WDF Version: This sample is a rewrite of the WDM toaster driver and is great starting point for understanding KMDF. It illustrate the functionality for bus driver, function driver and filter drivers for a hypothetical bus and its devices.

• WDM Samples

Toaster - WDM Version: This sample demonstrates how to write a bus driver, a function driver, assorted class, device and bus filter drivers, a class installer, and a device-specific co-installer for a hypothetical bus and its devices.

USBView Sample Application: This sample provides a GUI application to browse all connected controllers and USB devices on your computer. It is able to dump USB device's descriptors, query information about the devices from the registry via USB requests to the device. This is a useful tool but not a driver sample. 

We STONGLY DISCOURAGE you from using WDM Isochronous client driver sample (isousb.sys), Bulk transfer client driver sample (bulkusb.sys) and Selective suspend client driver sample (selsusp.sys) from old WDKs. These samples do not exist in the latest Windows 7 WDK installation package.

Why doesn't my driver unload?

Introduction to the Microsoft Windows USB Core Team Blog

Introduction to our team

Hello and welcome to the Microsoft Windows USB core team blog. Microsoft Windows USB core team has the mission to design, develop and test the software stack that drives the USB Host Controllers and USB Hubs present on the Windows PC.  This software stack helps the Client Device driver software in discovering and driving their devices.

Our team has also contributed and continues to contribute in defining Industry standards like the USB 1.1/2.0/3.0 specifications and the Host Controller standards like the EHCI,OHCI,XHCI specifications.

Our team owns the following components that many of our readers might be familiar with:

·         USB miniports – USBEHCI, USBUHCI, USBOHCI. These drivers interface with the corresponding host controllers.

·         USBPORT driver

·         USBHUB driver – Drives the USB Hubs

·         USBCCGP – Common Composite Generic Parent Driver that drives a USB Composite device as a whole

·         USBUI – User Interface for USB

·         USB WDK Samples

·         WinUSB

What to expect in the future

In this blog various members of the USB Core team might blog about the following in future:

• Common USB hardware issues we have found.
• Common driver bugs we see in the USB client driver
• What is new about USB samples in Windows7
•  What are the common issues involved in programming Isochronous Devices
• Information on Selective Suspend in the USB Stac
• Insight into the workings of the HUB and Port driver
•  USBCCGP - What is this ? What does it do ? 
• Information on USB Logo tests
• Information on  USB INF files, Information on USB User interface.
• Summary of various USB QFEs we have released for the various OSes.

We look forward to your feedback on our posts and any suggestions on what you might want to see from us in future.

Windows USB Core Team

 Disclaimer : This blog does not replace official MSDN documentation from Microsoft regarding USB support in windows. Please continue to read and provide feedback on the official Microsoft resources  for Windows USB driver developers

.