BSOD出现，驱动程序电源状态失败 ntoskrnl.exe
BSOD出现，驱动程序电源状态失败 ntoskrnl.exe
Hello everyone. Could you assist me in identifying the bsod problem in the new build?
CPU: 7800x3d
GPU: Gigabyte 4090 Gaming OC
PSU: NZXT 1200 Gold
Mobo: Asrock b650e Taichi
RAM: G.Skill Trident Z5
Usually bsod occurs after I stream with OBS (not during the stream but shortly afterward).
OBS 29, all drivers are up to date. For encoding I use NVENC.
Temperatures are normal and everything I did for OC was adjusting SoC voltage (as x3d chips are sensitive) and a minor RAM tuning from buildzoid.
Here are my 3 minidumps in .dmp format
minidumps.zip
drive.google.com
Currently I have no clear solutions.
The DRIVER_POWER_STATE_FAILURE issue arises when a driver keeps holding onto an IRP packet excessively. The root cause could stem from issues within the driver itself or problems with the device it manages. Two out of three dumps provided match exactly, indicating consistency in the situation.
I would begin by adjusting your RAM to its default setting and observe the results.
The DRIVER_POWER_STATE_FAILURE bugcheck happens when a driver holds on to (blocks) an IRP (Interrupt Request Packet) for too long. The cause is either a problem with the driver or a problem with the device it controls. Two of the three dumps you uploaded are DRIVER_POWER_STATE_FAILURE and they are identical.
The dump triage gives us pointers to useful data areas...
Code:
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: ffff800bb7f8e050, Physical Device Object of the stack
Arg3: fffff8003dfd4198, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffff800bbc1759c0, The blocked IRP
Argument 4 is the address of the blocked (held) IRP, displaying that gives...
Code:
0: kd> !irp ffff800bbc1759c0
Irp is active with 8 stacks 4 is current (= 0xffff800bbc175b68)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffff800bb7f8e050 00000000 00000000-00000000 pending
\Driver\storahci
Args: 00000000 00000001 00000001 00000000
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffff800bbc04ada0 00000000 fffff80044f68510-ffff800bbc155730 Success Error Cancel pending
\Driver\EhStorClass CLASSPNP!ClasspPowerUpCompletion
Args: 00000000 00000001 00000001 00000000
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffff800bbc1551f0 00000000 fffff80043e3ec60-00000000 Success Error Cancel pending
\Driver\disk partmgr!PmPowerCompletion
Args: 00000000 00000001 00000001 00000000
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffff800bbbf888d0 00000000 fffff8003f7a6b30-ffff800bbc175228 Success Error Cancel pending
\Driver\partmgr nt!PopRequestCompletion
Args: 00000000 00000001 00000001 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-ffff800bbc175228
Args: 00000000 00000000 00000000 00000000
The driver blocking (holding) the IRP is the bottom one; partmgr.sys. This is the Windows partition manager driver and because it's a Windows driver it's not at fault. This does however indicate that the problem was storage driver related and that because of some problem with a storage drive the partmgr.sys driver couldn't complete.
But which drive? Argument 2 is the clue here, it cotains the address of the device object for the storage device having a problem. Displaying this device object gives...
Code:
0: kd> !devobj ffff800bb7f8e050
Device object (ffff800bb7f8e050) is for:
Cannot read info offset from nt!ObpInfoMaskToOffset
\Driver\storahci DriverObject ffff800bb7e7ad40
Current Irp 00000000 RefCount 0 Type 00000007 Flags 00001050
SecurityDescriptor ffffc8877f75c5e0 DevExt ffff800bb7f8e1a0 DevObjExt ffff800bb7f8f3a0 DevNode ffff800bb7fa9c20
ExtensionFlags (0000000000)
Characteristics (0x00000180) FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffff800bbc04ada0 \Driver\EhStorClass
Device queue is not busy
Notice that the output here contains the address of the device node, that's the actual device at fault. Displaying that device node gives...
Code:
0: kd> !devnode ffff800bb7fa9c20
DevNode 0xffff800bb7fa9c20 for PDO 0xffff800bb7f8e050
Parent 0xffff800bb7f35a60 Sibling 0000000000 Child 0xffff800bbbff68a0
InstancePath is "SCSI\Disk&Ven_&Prod_CT500MX500SSD1\7&2a9b7bbb&0&010000"
ServiceName is "disk"
State = DeviceNodeStarted (0x30a)
Previous State = DeviceNodeEnumerateCompletion (0x30f)
StateHistory[15] = DeviceNodeEnumerateCompletion (0x30f)
StateHistory[14] = DeviceNodeEnumeratePending (0x30e)
StateHistory[13] = DeviceNodeStarted (0x30a)
StateHistory[12] = DeviceNodeEnumerateCompletion (0x30f)
StateHistory[11] = DeviceNodeEnumeratePending (0x30e)
StateHistory[10] = DeviceNodeStarted (0x30a)
StateHistory[09] = DeviceNodeEnumerateCompletion (0x30f)
StateHistory[08] = DeviceNodeEnumeratePending (0x30e)
StateHistory[07] = DeviceNodeStarted (0x30a)
StateHistory[06] = DeviceNodeStartPostWork (0x309)
StateHistory[05] = DeviceNodeStartCompletion (0x308)
StateHistory[04] = DeviceNodeStartPending (0x307)
StateHistory[03] = DeviceNodeResourcesAssigned (0x306)
StateHistory[02] = DeviceNodeDriversAdded (0x305)
StateHistory[01] = DeviceNodeInitialized (0x304)
StateHistory[00] = DeviceNodeUninitialized (0x301)
StateHistory[19] = Unknown State (0x0)
StateHistory[18] = Unknown State (0x0)
StateHistory[17] = Unknown State (0x0)
StateHistory[16] = Unknown State (0x0)
Flags (0x24000130) DNF_ENUMERATED, DNF_IDS_QUERIED,
DNF_NO_RESOURCE_REQUIRED, DNF_NO_LOWER_DEVICE_FILTERS,
DNF_NO_UPPER_DEVICE_FILTERS
CapabilityFlags (0x00002180) SilentInstall, RawDeviceOK,
WakeFromD3
The SCSI\Disk&Ven_&Prod_CT500MX500SSD1\7&2a9b7bbb&0&010000 identifies the device, its a Crucial MX500 500GB 2.5" SATA SSD (from the product code CT500MX500SSD1).
It would appear that there may be a problem with this device, so I would backup all data on it as soon as possible (when SSDs fail the data is gone forever). I would download and run the
Crucial Storage Executive software
from here, and run the drive self test from there. Also see whether there are firmware or other updates for the drive.
If it were mine I would replace the drive, once an SSD becomes untrusted it's time to replace it.
Oh! You're a magician! How do you earn so many likes for that detailed review? I have no clue how you manage to access that deep dump file—maybe you can show me the way? But I spent hours searching everywhere without success. Thank you very much. It seems like this old SSD might be beyond repair. I plan to follow your advice and just back up the data before exchanging it (just to see what happens). UPD. It looks like the firmware isn't readable and can't be updated through their tool either, with a firmware error reported and no fix available. It's time to let it go. No critical data here (pun intended, but nice XD).
This thread provided a great solution. I've faced a similar problem for a long time that was hard to figure out. I gained a lot of knowledge from this. The issue I'm addressing is the same one you mentioned, and I'm looking at the dump file in the same way. @ubuysa's report showed the error comes from my CRUCIAL MX500 2TB 2.5" SATA SSD. It's a small world! Have you ever had this resolved? Could you return it under warranty? My drive is only six months old, and I'm using the newest firmware. I'm wondering if swapping in a new drive would help or if these Crucial drives are really not worth it.