Share via

Understanding USB Sleep State Issues in Windows Vista

  • Article

This article briefly outlines how sleep state works for two different classes of USB devices in a Windows operation system, describes some the unique issues that result from those behaviors in a Windows Vista system, and provides a workaround for those issues.

Windows Power States

The Windows operating system supports six system power states, from S0 through S1, S2, S3, S4, and S5 (power off). State S0 is the working state, where the system is fully on and operational, while states S1, S2, S3, and S4 are sleeping states, in which the computer appears off because of reduced power consumption but retains enough context to return to the working state without restarting the operating system and state S5 is the shutdown or off state. A system is waking when it is in transition from the shutdown state (S5) or any sleeping state (S1-S4) to the working state (S0), and it is going to sleep when it is in transition from the working state to any sleep state or the shutdown state. For a more detailed description of the power states in Windows see System Power States.

In versions of Windows earlier than Windows Vista, a PC with any type of connected USB device was, by default, prohibited from entering the S3 sleep state; it was instead limited to the S1 (suspend) state. This was done to accommodate for a significant percentage of machines with non-compliant BIOS behavior, e.g., failure to resume from S3 sleep, and loss of power on USB controllers and/or devices during sleep.

Note

It is, however, possible to enable S3 sleep on a case-by-case basis for earlier systems of Windows by use of the USBBIOSx registry key. For more information, see KB article 841858

USB Devices and Windows Vista

For Windows Vista, the prohibition against entering S3 sleep while USB devices are connected was removed. BIOSes are now almost universally capable of handling USB power and wake requirements while in S3 sleep correctly. Enabling S3 sleep on PCs with USB devices (the majority of new systems) allows customers to realize the full power-saving benefit of S3 sleep over S1 suspend and is a recommended best practice. During the development of Windows Vista, a number of USB devices were found that did not resume correctly when the system woke from S3 sleep. These devices tend to fall into two classes; low-cost devices with non-compliant USB implementations, and USB devices embedded on laptop motherboards for which the BIOS incorrectly removes power during S3 sleep. To address these devices, Microsoft modified the behavior of the USB driver stack; upon resume from S3 sleep, the driver would reset all USB host controllers connected to the system.

After Windows Vista was released, a second group of devices with problems arose. Some USB devices were taking a long time to respond, or even failing to respond altogether, on resume from S3 sleep. Microsoft investigated, and found the root cause to be the reset of the USB host controllers on resume from S3 sleep.

Herein lies the root of the problem: one class of devices requires a host controller reset to function properly after resume from S3 sleep, and another class of devices requires that the host controller not be reset after resume from S3 sleep. Therefore for one class of USB devices, there is no issue when the system resumes on from a sleep state; the system responds as normal. However, for another class of USB devices, resuming from the sleep state may result in the failure of the Windows Vista system to respond. These devices require that the host controller for the device be reset on resume from S3 sleep.

The default behavior of Windows Vista, as specified by the USB2.0 specification, is not to reset the host controller on resume. (For more information, see sections 7.1.7.6 and 7.1.7.7 of the USB 2.0 specification). While Microsoft is making a best-effort attempt to provide a fix for this problem for Windows Vista, the problem is fundamentally one of non-spec-compliant USB 2.0 devices, which require that the USB host controller be reset on resume from S3 sleep. There are only limited options available to mitigate this issue.

There is, however, a way to modify the reset behavior of a controller in order to resolve this issue for those non-spec-compliant devices: changing the ForceHCResetOnResume registry key for each controller in the system as described in KB article 928631

Important

For the ForceHCResetOnResume registry key workaround, note that:

  • Making the registry change for a controller will affect all USB devices connected to that host controller, not just the behavior of the non-spec-compliant device. For maximum compatibility, this registry key should only be set where required. The majority of USB devices are spec-compliant with respect to their behavior when the system resumes from S3 sleep. The ForceHCResetOnResume registry key should be set only for devices which fail to respond when the system resumes from S3 sleep.
  • Since this registry key is applied on a per-host controller basis, it is possible (albeit unlikely) that one host controller will have devices attached which require incompatible resume behavior (i.e. one device requires the ForceHCResetOnResume registry key solution to function properly, and another requires that this registry key not be set). This problem is intractable, and outside of Microsoft’s ability to accommodate. If two USB devices, one non-spec-compliant and the other spec-compliant are used, the two devices must be connected to different USB host controllers, with different settings for the ForceHCResetOnResume registry key.