[BSOD] DRIVER_POWER_STATE_FAILURE ntoskrnl.exe

AshySamurai

Distinguished
Oct 21, 2016
19
1
18,515
Hello everyone. Please help me to pinpoint bsod issue 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 happens after I stream with OBS (not during stream but a little bit AFTER i stop).
OBS 29, all drivers are up to date. For encoding I use NVENC.
Temps are quite fine + all I did for OC is limiting SoC voltage (since x3d chips are quite sensitive) and a little bit ram tuning from buildzoid.

Here are my 3 minidumps in .dmp format

As of now I'm really out of ideas.
 
Solution
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...
Hello everyone. Please help me to pinpoint bsod issue 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 happens after I stream with OBS (not during stream but a little bit AFTER i stop).
OBS 29, all drivers are up to date. For encoding I use NVENC.
Temps are quite fine + all I did for OC is limiting SoC voltage (since x3d chips are quite sensitive) and a little bit ram tuning from buildzoid.

Here are my 3 minidumps in .dmp format

As of now I'm really out of ideas.
I would start by setting your ram to default and see what happens from there
 
  • Like
Reactions: AshySamurai
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.
 
  • Like
Reactions: AshySamurai
Solution
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.

O!M!G! You are a magician! How to give you bazillion likes for that in-depth analysis?
I have no idea how you get that deep into dump file (maybe you can teach me how?) but I spent hours checking everywhere with no result.
Thank you VERY much. It an old ssd so prob it is time to get rid of it anyway. I will follow your advice and just backup the data and then exchange it (maybe check it just to see what happens).

UPD. I guess it is faulty since I can't even get firmware reading and can't update firmware via their tool. It also reports firmware error with no way to fix it. Guess it is time to put it to rest. Gladly there is no CRUCIAL data (pun is not intended but nice XD.
 
Last edited:
  • Like
Reactions: ubuysa
O!M!G! You are a magician! How to give you bazillion likes for that in-depth analysis?
I have no idea how you get that deep into dump file (maybe you can teach me how?) but I spent hours checking everywhere with no result.
Thank you VERY much. It an old ssd so prob it is time to get rid of it anyway. I will follow your advice and just backup the data and then exchange it (maybe check it just to see what happens).

UPD. I guess it is faulty since I can't even get firmware reading and can't update firmware via their tool. It also reports firmware error with no way to fix it. Guess it is time to put it to rest. Gladly there is no CRUCIAL data (pun is not intended but nice XD.
@AshySamurai ! This thread was a lifesaver. I've been having the same issue for a while that was impossible to diagnose. Learned so much from this.

The reason I'm replying is that I am having the same error and checking the dump file in the way @ubuysa did (using the WinDbg program) revealed that the error is coming from my CRUCIAL MX500 2TB 2.5" SATA ssd. Small world! Did you ever get this fixed? Were you able to return it under warranty? My drive is only 6 months old. I'm on the latest firmware, so I'm wondering if a replacement drive will help, or if the Crucial drives are simply hopeless.