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.

Is it possible to remove a device from this ‘reset list’? After upgrading to w7 some of my USB devices software does not work after returning from hibernation without a restart(never had this problem in XP). And oddly enough this only happens when returning from hibernation and not standby. I know they are getting reset because you can hear the windows sound when a usb device is unplugged and plugged back in. help! I do not want to go back to xp, but I am almost out of options. Thanks.

I am developing an application that validates UFD devices (similar to USBCV from usb.org).In this application we develop exhaustive test cases for each USB device states (default, address & config). I am using WinUSB driver for achieving this.

After a lot of struggle I have managed to reset the device from the user space with IOCTL_USBUSER_REQUEST with USBUSER_SET_ROOTPORT_FEATURE. I have confirmed this with a lecry protocol analyzer. The problem is when I issue a GET_DESCRIPTOR (DEVICE) request after resetting the port. This command fails despite having received valid handles for host controller, roothub and device.

I am clueless on what I have done incorrect and your advise woudl be appreciated

I’m finding the windows7/usb ports problem is absurd. When can windows7 users expect to be able to use a flash drive like a normal person? Should we just never allow the computer to sleep? Will that do it? Should we go back to XP while we still can?

We are facing a similar problem in my USB driver on Windows 7. Once system goes to hibernate, my USB driver reloaded again, means USB got re-enumerated again. This happens sometimes, once in every five times. Could please give some light on this.

the USB Troubleshooter cannot add my device to the reset list and there is also no way to reset it trough the device manager (I run a windows 7 x64 system), the only way to make it work is to unplug/plug the usb cable.

is there a way to manually add a device to the reset list or to manually reset it?