DRIVER_POWER_STATE_FAILURE Blue Screen 0x9F: Seven Parameter 1 Values Explained

DRIVER_POWER_STATE_FAILURE is Windows stop code 0x0000009F (0x9F). Microsoft's reference says it indicates "that the driver is in an inconsistent or invalid power state." It is the stop code most connected to sleep, hibernation and devices that do not wake properly, and Microsoft's own Remarks section says as much.

The first parameter selects which of seven situations applies. Several of them are about a request or a transition that did not finish in time.

This page is built from the Microsoft Learn article "Bug Check 0x9F: DRIVER_POWER_STATE_FAILURE" and, where noted, Microsoft's general page on analysing blue screen data, both read on 13 October 2026 and checked against the Microsoft Docs source files. Microsoft marks the 0x9F page as written for programmers and directs customers to https://www.windows.com/stopcode. Anything taken from the general page rather than the 0x9F page is labelled as such.

What does parameter 1 tell you?

Parameter 1 indicates the type of violation. As printed in Microsoft's table:

Parameter 1	Cause, as Microsoft words it
0x1	The device object that is being freed still has an outstanding power request that it has not completed
0x2	The device object completed the I/O request packet (IRP) for the system power state request, but it did not call PoStartNextPowerIrp
0x3	A device object has been blocking an IRP for too long a time
0x4	The power state transition timed out waiting to synchronize with the Plug-and-Play (PnP) subsystem
0x5	The device failed to complete a directed power transition within the required amount of time
0x6	The device did not complete its Directed Power Transition callback successfully
0x500	The device object completed the IRP for the system power state request, but it did not call PoStartNextPowerIrp

Values 0x2 and 0x500 describe the same failure in Microsoft's table, with different parameter layouts. Parameter 1 equal to 0x3 is the case Microsoft documents in most detail: for it, parameter 2 is the physical device object of the stack, parameter 3 points to a power-triage structure, and parameter 4 is the blocked IRP.

What are the common causes?

The Cause section sends readers to the table above and lists four common causes, which are the same four situations in shorter form:

• Device object freed with an outstanding uncompleted power request
• Power state transition timed out
• Device object blocking an IRP
• Completed IRP but did not call PoStartNextPowerIrp

Microsoft states that finding the specific cause and creating a code fix requires programming experience and access to the source code of the faulting module.

What does the debugging section focus on?

Microsoft's detailed debugging steps are for parameter 1 equal to 0x3, and a similar set for 0x4. For 0x3 it names the !analyze -v command, which shows the nt!TRIAGE_9F_POWER structure's address in Arg3, then the dt, !irp, !devstack and !poaction commands, plus the !stacks extension to find a thread holding up the power transition. For Kernel-Mode Driver Framework (KMDF) drivers it adds !wdfkd.wdflogdump and !wdfkd.wdfdevicequeues.

The page lists questions to ask during that debugging: what the characteristics of the physical device object driver are, whether the blocked thread can be found, whether there is I/O associated with it, and what the PnP minor function code of the power IRP is. These are for developers. The takeaway for everyone else is that a 0x9F usually means something was waiting on a device that never answered.

What does the Remarks section say to try?

The Remarks section is the customer-side list, and it is more specific than most:

Check	What Microsoft says
Recent changes	If new device drivers or system services were added recently, try removing or updating them, and try to determine what changed
Device Manager	Look for devices marked with an exclamation point, review the event log in the driver properties, and update the related driver
System Log	Look for critical errors in the same time window as the blue screen
Power saving	Temporarily disable power save in Control Panel, Power Options, because some driver issues are related to hibernation and suspend and resume
Hardware	If you recently added hardware, try removing or replacing it, or check with the manufacturer for patches
Diagnostics	Try the hardware diagnostics supplied by the system manufacturer
Firmware	Check whether an updated system ACPI/BIOS or other firmware is available

The power-save step is the one that stands out. Microsoft says to disable it temporarily to isolate the cause; it does not say to leave it off.

What Microsoft tells non-programmers to do

For people who cannot debug, the Remarks section lists seven basic techniques. In Microsoft's order:

• Remove or update recently added drivers or system services, and work out what changed.
• In Device Manager, look for devices marked with an exclamation point and update the related driver.
• Check the System Log for critical errors in the same time window as the blue screen.
• Temporarily disable power save in Power Options to isolate the cause.
• Remove or replace recently added hardware, or ask the manufacturer for patches.
• Run the hardware diagnostics supplied by the system manufacturer.
• Check for an updated ACPI/BIOS or other firmware.

Because the stop code is about power transitions, Microsoft's advice mentions hibernation and suspend and resume specifically. It does not mention memory tests or disk checks for this code, and this page does not add them.

Checklist before changing anything

• Parameter 1 from the System Log
• Whether the crash happens on sleep, hibernate or resume
• Devices marked with an exclamation point in Device Manager
• Hardware or drivers added recently
• Whether an ACPI/BIOS or firmware update exists

How to work through a 0x9F blue screen

• Note parameter 1 and when the crash happens (sleep, resume or other)
• Update or remove recently added drivers and hardware
• Temporarily disable power saving to isolate the cause
• Run the manufacturer's diagnostics and look for firmware updates

Registry edits and paid tools. Microsoft's page does not mention them, so neither does this one.

How does the page say the driver gets named?

Microsoft adds a step that does not depend on reading the parameter table. If a driver responsible for the error can be identified, its name is printed on the blue screen and also stored in memory at the location KiBugCheckDriver, a PUNICODE_STRING. In a kernel debugger the dx command displays it: dx KiBugCheckDriver. That gives the same name the screen showed, from the dump, which matters when the screen was photographed badly or not at all. The parameter table also names one object this page returns to repeatedly, the POP_FX_DEVICE object, which appears as parameter 2 or 3 in the two directed-power rows (parameter 1 of 0x5 and 0x6).

Every stop code covered here is listed in our Windows blue screen stop code index.

Sources and how to check

• Microsoft Learn, "Bug Check 0x9F: DRIVER_POWER_STATE_FAILURE" — https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x9f--driver-power-state-failure. Source file in the MicrosoftDocs/windows-driver-docs repository.
• Microsoft Learn, "Analyze bug check (stop code error) data" — https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/blue-screen-data (general guide).
• Bug check code reference, Microsoft Learn: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-code-reference2
• Troubleshoot blue screen errors (for regular users): https://www.windows.com/stopcode
• Licence and credit: Microsoft Learn documentation is published under CC BY 4.0. This page selects, rewords and reorders it, adds a plain-language reading, and is not endorsed by Microsoft. The original is linked above.
• Checked as of 13 October 2026.