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.