DRIVER_POWER_STATE_FAILURE 0x0000009F on sleep, hibernate or shutdown

Fix it now

0x0000009F means a driver is in an inconsistent or invalid power state. The most common form has parameter 1 of 0x3 – a device object has been blocking an IRP for too long – and it hands you the physical device object and the blocked request, which makes this one of the more readable bug checks.

!analyze -v
powercfg /a
powercfg /energy
powercfg /devicequery wake_armed

1. Establish the pattern first: does it crash on sleep, on hibernate, on shutdown, or on resume? That distinction narrows the field more than anything else.
2. Read parameter 1 from the dump. 0x3 means a device object blocked an IRP for too long, with parameter 2 the physical device object and parameter 4 the blocked IRP.
3. Update the wireless and Ethernet drivers from the hardware vendor, then USB and chipset drivers from the same source.
4. Stop devices sleeping on their own as a test: in Device Manager, open each network adapter and USB Root Hub, go to Power Management, and untick ‘Allow the computer to turn off this device to save power’.
5. Turn off Fast Startup as a test. It is in Power Options, under the settings for what the power buttons do, and needs the ‘change settings that are currently unavailable’ link before the checkbox can be cleared.

Reintroduce the power management settings one at a time once the machine is stable. Leaving every device permanently awake fixes the crash by disabling the feature that exposed it, which is not the same as fixing the driver.

If the transition that used to crash now completes, stop here. The next section covers the other parameter 1 values, which point at different drivers entirely.

Why it happens

Power management in Windows is cooperative. When the system changes state, the power manager sends a power IRP to every device stack and waits for each to complete it. Every driver in that stack gets a turn: handle the request, or pass it down and complete it on the way back up. The system cannot proceed until all of them have answered.

A driver that blocks – waiting on hardware that is not responding, or deadlocking against its own worker thread – stops the whole transition. The watchdog exists because the alternative is a machine that hangs forever with a black screen and no diagnostic evidence at all. The crash therefore lands the moment you close the lid, press shutdown, or the machine idles into sleep.

Parameter 1 is what makes this bug check tractable, and different values point at genuinely different drivers. 0x3 is a device object blocking an IRP for too long, with the physical device object of the stack in parameter 2 and the blocked IRP in parameter 4. 0x2 and 0x500 both mean the device object completed the power IRP but did not call PoStartNextPowerIrp, which is a driver bug of a different shape. 0x4 is the power transition timing out waiting to synchronise with the PnP subsystem, and gives you the time-out value and the thread holding the PnP lock.

Two more matter on current hardware. 0x5 means the device failed to complete a directed power transition within the required time, and 0x6 means it did not complete its directed power transition callback successfully, with parameter 3 saying whether it was a power-down or a power-up. Machines using modern standby exercise those paths constantly, which is why laptops see this far more than desktops do.

Full reference

Parameter 1 for 0x0000009F

powercfg, and what each option is for

Check powercfg /a before running /sleepstudy. On a machine using S3 sleep rather than modern standby there is nothing for the sleep study to report, and an empty report is easily mistaken for a clean one.

The related power and unload bug checks

Isolating it by transition

1. Try each transition deliberately – sleep, hibernate, shutdown, restart – and note which ones fail. A fault on shutdown only is a different set of drivers from one on resume only.
2. Turn off Fast Startup for the test. It makes shutdown a partial hibernation, so a shutdown fault and a hibernate fault become the same fault with it enabled.
3. Disconnect all removable devices and retry the failing transition.
4. Reintroduce devices one at a time, using the machine for a few minutes between each.
5. Once the device is known, work on its driver and firmware rather than on Windows power settings.

When the dump is not conclusive

• Run powercfg /energy for a few minutes of idle and read the errors and warnings sections. It names devices and drivers that behave badly around power without needing a crash.
• Check for a system firmware update from the machine vendor. Power transitions run through firmware, and this is one of the bug checks where a BIOS or UEFI update genuinely helps.
• Test with the machine docked and undocked if it is a laptop. A docking station adds an entire device tree to every transition.
• Keep several dumps. A device object that appears in all of them is worth more than the module !analyze names in one.

Every code this article covers

Confirm the fix worked

1. The transition that used to crash – sleep, hibernate or shutdown – now completes, several times in a row.
2. Resume works as well as suspend. A machine that sleeps cleanly and crashes on wake has not been fixed.
3. powercfg /energy reports no errors against the device you were chasing.
4. The fix survives with Fast Startup and the device’s power management setting restored, not only with them disabled.

Questions people ask about this