STOP 0x0000009F — DRIVER_POWER_STATE_FAILURE
A driver did not complete a power transition in time, so the power manager gave up and bugchecked.
What you see
Bluescreens on sleep, hibernate, resume or shutdown — rarely while the machine is being used. Laptops closing the lid, or a machine that will not wake.
What is actually wrong
Network adapters (particularly Wi-Fi and Killer/Intel), USB controllers, and storage drivers are the usual suspects. Fast Startup makes it appear on shutdown as well as sleep.
Codes and articles
Fixes (3)
Stop the devices most likely to be at fault from being powered down
Sleep or resume. This narrows it quickly without needing a debugger.
List every device Windows is allowed to switch off.
Get-CimInstance -ClassName MSPower_DeviceEnable -Namespace root\wmi | Where-Object Enable -eq $true | Select-Object -First 20 InstanceNameTurn off power management on the network adapters first — they cause most of these.
Get-NetAdapter | Get-NetAdapterPowerManagement | Format-Table Name, AllowComputerToTurnOffDevice -AutoSizeGet-NetAdapter | ForEach-Object { Set-NetAdapterPowerManagement -Name $_.Name -AllowComputerToTurnOffDevice Disabled -ErrorAction SilentlyContinue }
Disable USB selective suspend in the active power plan.
powercfg /setacvalueindex SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3 48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0powercfg /setactive SCHEME_CURRENT
Update the chipset, network and storage drivers from the machine vendor rather than Windows Update.
Test sleep and resume several times.
powercfg /sleepstudy /output C:\temp\sleepstudy.htmlTurn off Fast Startup
It happens on shutdown. Fast Startup makes shutdown a hibernate, so a driver that cannot hibernate bugchecks on what looks like a normal shutdown.
Disable hiberboot, which is what Fast Startup actually is.
powercfg /hibernate offThis also frees a hiberfil.sys the size of your RAM. If you want hibernate kept, disable only Fast Startup in Control Panel → Power Options → Choose what the power buttons do.
Confirm it is off.
powercfg /aShut down and start up several times to test.
Name the driver from the dump
No pattern, or the quick fixes did not help. For 0x9F the dump identifies the device stack precisely.
Open C:\Windows\MEMORY.DMP in WinDbg.
Run the automatic analysis.
!analyze -vParameter 3 of this bugcheck is the device object that stalled. Inspect it.
!devstack <address-from-parameter-3>This prints the whole driver stack for that device, which names the third-party filter driver holding up the transition — the thing !analyze often attributes to ntoskrnl.
Update or remove the driver it names.
Reference
Related faults
Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.