Windows stop code · 0x0000009F

0x9F DRIVER_POWER_STATE_FAILURE

What stop code 0x9F DRIVER_POWER_STATE_FAILURE means, what each parameter tells you, and the WinDbg commands that find the driver holding the power IRP.

Published 2026-10-20 by PerformanceInsights.ai

Short answer: 0x9F means a driver left a power request (an IRP for sleep, resume or a device power change) unfinished for too long, or broke the power IRP rules. It usually shows up on sleep, hibernate, resume or shutdown. Parameter 1 tells you which case. For the common 0x3, Parameter 4 is the blocked IRP: !irp on it names the driver that is holding it.

Parameters

Parameter 1	Meaning	Parameters 2 / 3 / 4
`0x1`	A device object being freed still has an outstanding power request.	Device object / reserved / reserved
`0x2`	The device object completed the IRP for the system power state request but didn't call `PoStartNextPowerIrp`.	Target device object / device object / driver object
`0x3`	A device object has been blocking an IRP for too long. The most common one.	PDO of the stack / `nt!_TRIAGE_9F_POWER` / the blocked IRP
`0x4`	The power transition timed out waiting to synchronize with Plug and Play.	Timeout in seconds / thread holding the PnP lock / `nt!_TRIAGE_9F_PNP`
`0x5`	The device didn't finish a directed power transition in time.	PDO / `POP_FX_DEVICE` / reserved
`0x6`	The device's directed power transition callback failed.	`POP_FX_DEVICE` / 1 = power down, 0 = up / reserved
`0x500`	Same as `0x2`, with the parameters in different slots.	Reserved / target device object / device object

Source: Microsoft Learn, Bug Check 0x9F.

Reading the dump (Parameter 1 = 0x3)

A minidump often doesn't hold the IRP and the device stack. Use a kernel memory dump for this one if you can.

!analyze -v                 # Arg2 = PDO, Arg4 = the blocked IRP
!irp <Arg4>                 # the current stack location (">") names the driver, e.g. \Driver\HidUsb
!devstack <Arg2>            # every driver in that device's stack, and the device instance ID
!poaction                   # outstanding power IRPs and the threads handling them
dx KiBugCheckDriver         # the driver Windows named, if it named one
!stacks 2                   # look for a thread that's waiting while it holds the power transition up

The driver on the current IRP stack location is the one sitting on the request. That's often a filter driver (antivirus, VPN, USB or storage filters) rather than the device's own driver. Then lmvm <driver> shows its version and date.

For 0x4, Arg3 is the thread holding the PnP lock: !thread <Arg3> shows what it's waiting on.

Typical causes and fixes

An old or buggy driver for a USB, Wi-Fi, Bluetooth, graphics or storage device. Update it from the hardware vendor, not just Windows Update.
Filter drivers from security or VPN software that hold IRPs during sleep. Update the product, or test with it removed.
Firmware. BIOS/UEFI and chipset updates fix many sleep and resume hangs.
To confirm the trigger, turn off sleep, hibernate or fast startup for a while and see if the crash stops.

Rather not read the dump yourself?

Upload it to DumpTriage. It runs the debugger, reads the output and sends back the faulting module, the stack and a plain-language root cause. Cases the automated passes can't settle go to an engineer. Free during the pilot.

Create an account