BSOD caused by ntoskrnl.exe

Question

For the past week I've been getting this bluescreen, with the DRIVER_POWER_STATE_FAILURE. I've looked on multiple threads online of various people with the same problem and no one ever seemed to fix this problem. So now I am here to get help so that if possible this problem is fixed once and for all.

================================================================

Steps I've tried :
BIOS update
Safe boot error code was given and changed them to new.
Updated all drivers, including graphics, chipset, network, audio.

================================================================

SPECS:

CPU: Ryzen 5 7600X

RAM: 32HGB DDR5 6000Mhz
GPU: Radeon RX 6800
Storage: Kingston 1TB NVMe

Motherboard: Gigabyte B650 EAGLE AX

================================================================
**
Mini Dump File:**

Thank you, I hope that someone can help.

Answer 1

Please upload any minidump files you have, I will check those to see if they provide any insight into a potential cause of the system crashes.

Please do not upload a very large Memory.dmp file.

Open Windows File Explorer.

Navigate to C:\Windows\Minidump

Copy any minidump files onto your Desktop, then zip those up.

Upload the zip file to the Cloud (OneDrive... etc.), then choose to share those and get a share link.

Then post the link here to the zip file, so I can take a look for you.

Answer 2

The blue screen with bug check code 0x9F (DRIVER_POWER_STATE_FAILURE) indicates that a driver is not handling power-state transitions correctly. Although BlueScreenView shows ntoskrnl.exe, that is almost never the root cause; a third‑party driver is typically blocking or timing out during sleep/hibernate or shutdown.

Because Parameter 1 is 0x3 in the screenshot, this matches the documented case where a device object is blocking a power IRP during a power transition.

Follow these steps to isolate and mitigate the issue:

1. Check Device Manager for faulty devices
   • Open Device Manager.
   • Look for any device with a yellow exclamation mark.
   • For such devices, open Properties → Events and Driver tabs, and update or temporarily disable/uninstall the device.
     This aligns with the guidance to use Device Manager to find drivers that are faulting around the time of the blue screen.
2. Review Event Viewer around the crash time
   • Open Event Viewer → Windows Logs → System.
   • Filter for Critical and Error events around the timestamp of the BSOD.
   • Note any driver or device repeatedly logging power or timeout errors (for example, storage, network, or GPU). This can point to the specific driver that is mishandling power IRPs.
3. Temporarily change power settings
   • Go to Control Panel → Power Options.
   • Select the active plan → Change plan settings → Change advanced power settings.
   • Temporarily disable or relax sleep/hibernate for disks, PCI Express link state power management, and USB selective suspend.
   • Also test with hibernation and hybrid sleep disabled.
     If the BSODs stop when power‑saving features are disabled, that confirms a driver that fails during low‑power transitions.
4. Test without recently added or non‑essential hardware
   • Disconnect any non‑essential USB devices, external drives, docks, or peripherals.
   • If any internal hardware (for example, additional NVMe, PCIe card) was added recently, test with it removed if possible.
     This follows the recommendation to remove or replace recently added hardware when troubleshooting bug check 0x9F.
5. Update or roll back suspect drivers and firmware
   • For any device implicated by Device Manager or Event Viewer, install the latest stable driver from the hardware vendor (chipset, GPU, storage/NVMe, network, Wi‑Fi, Bluetooth).
   • If the issue started immediately after a specific driver update, test by rolling that driver back to the previous version.
   • Check the motherboard vendor for updated BIOS/firmware and ACPI/board drivers; firmware updates are explicitly recommended for power‑related bug checks.
6. If comfortable with debugging, analyze the minidump with WinDbg
   For a precise root cause, the minidump must be opened in a kernel debugger:
   • Install the Windows debugging tools and open the minidump in WinDbg.
   • Run !analyze -v to identify the driver stack involved in the 0x9F crash.
   • Because Parameter 1 is 0x3, use the documented workflow:
     • Use dx KiBugCheckDriver to see if a specific driver name is recorded.
     • Use dt nt!TRIAGE_9F_POWER <Arg3> to inspect the power triage structure and list outstanding power IRPs.
     • Use !irp <Arg4> to inspect the blocked IRP and see which driver in the stack is not completing it.
     • Use !devstack <Arg2> to inspect the device stack for the PDO and identify the exact driver object blocking the power transition.
       Once the offending driver is identified, update, roll back, or uninstall that driver, or contact the vendor for a fix.
7. If debugging tools are not an option, apply general blue‑screen troubleshooting
   • Boot into Safe Mode and see if the issue reproduces; if not, that further indicates a third‑party driver or service.
   • Ensure Windows is fully updated.
   • If the problem persists and started recently, consider using System Restore or other recovery options to revert to a state before the BSODs began.

These steps follow the documented guidance for DRIVER_POWER_STATE_FAILURE (0x9F) and general Windows blue‑screen troubleshooting, focusing on identifying and correcting the misbehaving driver or hardware involved in power‑state transitions.

---

References:

• Bug Check 0x9F: DRIVER_POWER_STATE_FAILURE
• Troubleshooting Windows unexpected restarts and stop code errors