0x0000009F DRIVER_POWER_STATE_FAILURE
This bugcheck has a property that makes it far easier to diagnose than most: it happens at a specific moment. Not during use, but when the machine is going to sleep, waking up, hibernating or shutting down. Some driver was asked to change power state, and it did not answer within the time allowed - usually around ten minutes, which is a very long time for a driver to be silent.
What you are looking at
Your PC ran into a problem and needs to restart.
Stop code: DRIVER_POWER_STATE_FAILURE
What failed: ndis.sys
In Event Viewer the matching entries look like this:
Log Name: System
Source: BugCheck
Event ID: 1001
Level: Error
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000009f (0x0000000000000003, 0xffffa50c1b2e4060, 0xfffff8036c1d43d8, 0xffffa50c1d61bd0).What the error actually means
Sleeping a computer is a negotiation. Windows sends every device a power request - an I/O request packet asking it to move to a lower power state - and waits for each one to acknowledge. Only when the whole stack has answered can the machine actually sleep.
A driver that never answers stalls the entire transition. Windows cannot proceed, cannot safely give up, and cannot leave the machine half asleep. After a timeout it stops with this bugcheck and, where it can, names the driver responsible on the screen itself.
That last detail is worth appreciating. Most stop codes make you dig through a dump for a name; this one frequently prints it. Combined with the fact that the failure is tied to a specific event, it is one of the more tractable codes on this site.
Reading the parameters
Parameter 1 is the violation type, and the other three change meaning depending on it. Value 3 is the one you will almost certainly have.
| Parameter | What it holds |
|---|---|
| 1 = 0x3 | A device object has been blocking an IRP for too long - by far the most common. Parameter 2 is the physical device object of the stack, parameter 3 is a pointer to the nt!_TRIAGE_9F_POWER structure, and parameter 4 is the blocked IRP itself, which is what you feed to the debugger to find the culprit. |
| 1 = 0x1 | A device object that is being freed still has an outstanding power request it never completed. Parameter 2 is the device object. |
| 1 = 0x2 | The device object completed the power request but failed to call PoStartNextPowerIrp, so the chain stalled. Parameter 2 is the target device's device object, parameter 3 the device object, parameter 4 the driver object. |
| 1 = 0x4 | The power transition timed out waiting to synchronise with the Plug-and-Play subsystem. Parameter 2 is the timeout in seconds, parameter 3 is the thread holding the PnP lock, parameter 4 points at nt!_TRIAGE_9F_PNP. |
| 1 = 0x5 | The device failed to complete a directed power transition in the required time. Parameter 2 is the physical device object, parameter 3 the POP_FX_DEVICE object. |
| 1 = 0x6 | The device did not complete its directed power transition callback successfully. Parameter 2 is the POP_FX_DEVICE object; parameter 3 indicates whether this was a power down (1) or power up (0). |
What actually triggers it
Almost everything here is a driver that handles power transitions badly. The device categories are consistent enough to be worth memorising.
| Cause | How often | Detail |
|---|---|---|
| Network adapter drivers | Common | The most frequent single category, and Wi-Fi adapters more than wired. Network drivers implement wake-on-LAN and selective suspend, both of which involve exactly the transitions that fail here. Vendor-supplied drivers on laptops are often customised variants that lag the generic release. |
| USB devices and their drivers | Common | Microsoft's own documentation example shows a USB HID device stalling the transition. Docking stations, hubs, external drives, game controllers and capture devices are all recurring offenders - and a single misbehaving peripheral is enough. |
| Storage controllers | Occasional | A drive that stalls while flushing on the way into sleep blocks the request. Overlaps with the causes behind DPC_WATCHDOG_VIOLATION. |
| Graphics drivers | Occasional | Particularly on hybrid laptops where the discrete GPU powers down independently, and on multi-monitor setups where displays negotiate separately. |
| Vendor power-management utilities | Occasional | Laptop makers ship their own power and thermal management software that inserts itself into these transitions. When it is out of step with the Windows build, this is the result. |
| Firmware and ACPI bugs | Occasional | Microsoft's guidance explicitly suggests checking for an updated system BIOS or ACPI firmware. Sleep behaviour is defined partly in firmware, and vendors do fix it there. |
| Failing hardware | Rare | A device that has genuinely failed may never respond. Rare compared with a driver that simply handles the transition badly. |
Narrowing it down
Start with the timing, because it narrows things faster than anything else.
Establish exactly when it happens
Going to sleep, waking from sleep, hibernating, resuming, or shutting down? Does it happen every time or occasionally? Does it happen with the lid closed but not with it open, or only when a dock is attached?
Crashes only on wake point at devices that reinitialise on resume - network and USB in particular. Crashes only on the way into sleep point at something failing to flush or release. A crash that happens only when docked identifies the dock without further work.
Read the driver name off the screen
Where Windows can identify the responsible driver it prints the name on the blue screen under What failed. It also stores it in memory, so in a debugger you can retrieve it with:
dx KiBugCheckDriverA third-party .sys name is your answer directly. If it shows ndis.sys or usbhub.sys, those are Microsoft's framework components - the actual offender is a driver sitting on top of them, which the next step identifies.
Find the blocked request in the dump
When parameter 1 is 3, the dump contains everything needed. Run !analyze -v, then use the addresses from the arguments:
!irp <address from Arg4>
!devstack <address from Arg2>The first shows the blocked I/O request and which driver owns it; the second shows the device stack and names the driver and device instance.
This produces an exact device - in Microsoft's own worked example, a USB HID device under \Driver\usbhub. That is specific enough to act on immediately.
Disconnect everything and retest
Unplug all USB peripherals except keyboard and mouse - especially docks, hubs and external drives - and test sleep and wake several times.
If it becomes stable, reconnect one device at a time. This finds a faulty peripheral in an afternoon and requires no debugging at all.
Fixes, cheapest first
Ordered by likelihood of success on the common cases.
Update the network adapter driver
Given how often networking is responsible, do this first even without a name from the dump.
- Identify the adapter in Device Manager under Network adapters.
- Get the current driver from the adapter vendor - Intel, Realtek, Qualcomm, MediaTek - or from the laptop vendor if it is a laptop.
- Uninstall the existing one, ticking Delete the driver software for this device, then reboot and install.
- In the adapter's Properties, under Power Management, clear Allow the computer to turn off this device to save power.
Watch outThat last checkbox alone resolves a meaningful share of cases. It costs a small amount of idle power and nothing else.
Disconnect or replace USB peripherals
Run with only keyboard and mouse for a couple of days, testing sleep repeatedly. Then reintroduce devices one at a time.
Pay particular attention to unpowered hubs, docking stations and anything that draws significant current. A dock that worked for a year can start doing this after a firmware or Windows update.
Turn off selective suspend and device power saving
Microsoft's guidance suggests temporarily disabling power saving to isolate the cause. Do it in two places.
- Power Options, change plan settings, advanced settings, USB settings, USB selective suspend setting - set to Disabled.
- In Device Manager, for each USB Root Hub and for the network adapter, open Properties, Power Management, and clear Allow the computer to turn off this device to save power.
- Test sleep and wake several times.
Watch outTreat this as a diagnostic first. If it fixes things, you have identified the subsystem - and you can then decide whether to leave it disabled or pursue a proper driver update.
Disable Fast Startup
Fast Startup hibernates the kernel rather than shutting down fully, which means drivers resume from a saved state instead of initialising cleanly. It interacts badly with drivers that handle power transitions poorly.
- Control Panel, Power Options, Choose what the power buttons do.
- Click Change settings that are currently unavailable.
- Clear Turn on fast startup and save.
Watch outCold boots take a few seconds longer. In exchange, shutdown becomes a real shutdown, which also makes other troubleshooting more reliable.
Update chipset drivers and system firmware
Install the chipset package from your board or system vendor rather than relying on Windows Update. Then check for a BIOS or UEFI update - sleep and ACPI behaviour is defined partly in firmware and vendors ship fixes for exactly this.
Watch outIf the drive is protected by BitLocker or Device Encryption, a firmware update can change TPM measurements and trigger a recovery-key prompt on the next boot. Check with
manage-bde -statusand save your key from account.microsoft.com/devices/recoverykey first - Windows 11 enables Device Encryption by default on much consumer hardware.Run the update on mains power and do not interrupt it.
Remove vendor power management utilities
On laptops especially, uninstall the manufacturer's power, thermal or battery management software and test with Windows handling power alone. These utilities are a common source of transition failures after a Windows feature update, and most of what they do is available natively.
When it is the hardware, not Windows
Usually a driver problem, so hardware signals need to be clear before changing direction:
- The same device fails on a different machine.
- A specific USB device or dock reproduces it reliably and no driver update helps.
- The machine also fails to wake with no crash at all - a black screen requiring a hard power cycle.
- Other stop codes appear alongside this one.
WHEA-Loggerentries appear around the same timestamps.- It persists after a clean Windows install with only vendor drivers.
The most common genuine hardware case here is an external peripheral rather than anything inside the machine - a failing dock, a hub with a dying controller, an external drive whose bridge chip stops responding. Those are cheap to replace and easy to prove by substitution, which makes this one of the less expensive stop codes to resolve.
Frequently asked
It only crashes when I close the laptop lid. What does that tell me?
That the fault is in the sleep transition rather than in normal operation, which is useful. Closing the lid triggers the same power request as any other sleep, so the device stalling is the same one - you have simply found a reliable way to reproduce it. Test by sleeping from the Start menu instead: if that also crashes, the lid is incidental. If only the lid does it, look at whatever changes state on lid close, typically the display and any connected dock.
The screen names ndis.sys. Is that the faulty driver?
No - ndis.sys is Microsoft's network driver framework, and it appears because it was coordinating the transition on behalf of your actual network driver. The real culprit is the adapter's own driver sitting on top of it. Use !irp and !devstack on the dump arguments to get the specific device, or simply start by updating the network adapter driver since that is where this points.
Why does it take ten minutes to crash?
Because Windows is genuinely patient with power transitions. Legitimate operations can be slow - a drive flushing large caches, a device completing an in-flight operation - so the timeout is generous by design. If a driver has not answered in that time it is not being slow, it is not answering at all. The long timeout is also why you sometimes see the machine sit with a black screen for a while before the blue screen appears.
Should I just disable sleep entirely?
It stops the crashes, and it is a reasonable stopgap on a desktop while you diagnose. It is a poor permanent answer on a laptop, where sleep is most of the value of the machine, and it leaves the underlying driver problem in place - the same driver may misbehave at shutdown too. Use it to buy time, not as the fix.
Related errors
- 0x00000133DPC_WATCHDOG_VIOLATIONA driver hogged the CPU past a hard deadline. Storage firmware and SATA drivers cause most of them.
- 0x0000000AIRQL_NOT_LESS_OR_EQUALA driver accessed memory at an interrupt level too high to survive the fault. Nearly always a driver.
- GuideHow to Read a Windows Crash Dump File with WinDbgInstall WinDbg, open the dump, run one command. Fifteen minutes, and it usually names the driver.