Skip to content
PCDecoder
0x0000009FDRIVER_POWER_STATE_FAILUREStop codeWidely reported

DRIVER_POWER_STATE_FAILURE (0x9F): what it means and how to fix it

Updated Oct 4, 2026 · Checked against Microsoft documentation · How this page is made

Quick answer

This blue screen crash occurs when a hardware driver enters an invalid power state or fails to change power levels in time. The most frequent cause is a device driver hanging during power transitions such as sleeping, waking, or shutting down. Checking Device Manager for troubled hardware and removing or updating recently installed drivers is the best starting point.

What it means

What happened to your system

Windows expects every piece of hardware and software driver to switch power modes predictably. Devices shift between active usage and low-power states whenever your computer sleeps, hibernates, wakes up, or shuts down. During these transitions, the Windows kernel sends power input/output request packets (IRPs) to the driver stack.

The 0x0000009F bug check indicates that a driver failed to handle one of these power requests properly. Instead of confirming that it powered down or resumed, the driver stayed in an inconsistent state or blocked the request until a system timer expired.

Why the crash occurs

When Windows tells a device to change power states, it waits for confirmation from the driver stack. If a driver stops responding or takes too long to finish the power transition callback, Windows triggers a crash to protect system integrity and data.

Specific internal triggers defined by the operating system include:

  • A device object being freed while it still has an active, uncompleted power request.
  • A device object completing an I/O request packet for a system power state request without calling PoStartNextPowerIrp.
  • A driver or device object blocking an IRP for too long.
  • A power state transition timing out while waiting to synchronize with the Plug-and-Play (PnP) subsystem.
  • A device failing to complete a directed power transition or callback within the allocated time window.

If Windows identifies the specific driver responsible at crash time, its file name is displayed directly on the blue screen and saved in memory. When it cannot isolate the exact file, the crash points to the general power management subsystem.

Common causes

  • A hardware driver blocked a power I/O request packet for too long during a sleep, wake, or shutdown event.
  • A recently installed driver or system service failed to complete a required power state transition.
  • A device object was freed while an uncompleted power request was still outstanding.
  • A driver completed a system power state request without calling PoStartNextPowerIrp.
  • A device timed out while attempting to synchronize with the Plug-and-Play subsystem.

How to fix it

Safest and most likely fixes first. Readers' answers to "Did this fix it?" reorder this list over time.

  1. Check Device Manager for failing hardware

    Use this first to spot hardware components that Windows has already flagged for driver or power issues.

    1. Right-click the Start button and select Device Manager.
    2. Scan the device tree for any category showing a yellow exclamation point icon.
    3. Right-click any flagged device and select Properties.
    4. Open the Events tab to review logged device installation and power errors.
    5. Open the Driver tab and select Update Driver to check for a corrected version.
    Did this fix it?

  2. Remove or roll back recently added drivers

    Use this if the 0x9F crash started immediately after installing a new device, driver update, or software service.

    1. Right-click the Start button and select Device Manager.
    2. Locate the device that received a recent update.
    3. Right-click the hardware entry and choose Properties.
    4. Select the Driver tab.
    5. Click Roll Back Driver if the option is available, or select Uninstall Device if the driver was newly added.
    6. Restart Windows to complete the removal.
    Did this fix it?

  3. Identify the failing driver using crash dump analysis

    Use this advanced step if the blue screen does not name the faulting file and Device Manager shows no obvious problems.

    1. Open a kernel debugging tool with administrative permissions.
    2. Load the memory dump file created during the 0x9F bug check.
    3. Run the command !analyze -v to generate a verbose breakdown of the crash.
    4. Inspect the KiBugCheckDriver value to see if Windows identified the exact file name.
    5. Run the !devstack or !irp command against the listed parameter addresses to inspect the blocked device driver.
    6. Locate the driver identified in the stack and update or remove the corresponding software.
    Did this fix it?

Is it just you?

25+ Microsoft Q&A threads discuss this. Most recent activity:

Checked Oct 2, 2026. Refreshed automatically every few days.

Sources

Frequently asked questions

What is the most common parameter for error 0x9F?

The most common condition occurs when Parameter 1 equals 0x3, which indicates that a device object blocked a power IRP for too long.

Does DRIVER_POWER_STATE_FAILURE mean my power supply is broken?

No. The name refers to software power management states between Windows and hardware drivers, not physical power supply hardware failures.

Can I see which driver caused 0x0000009F on the blue screen?

Windows will print the driver name directly on the screen if it can identify the culprit, which is stored in memory at KiBugCheckDriver.

More stop codes decoded