Need Help Diagnosing BSOD


Recommended Posts

Ever since I built my Ryzen rig, there has been something causing it to blue screen, and it's a problem that has persisted several driver updates, it only happens when I use hybrid boot (the issue seems to be that whatever driver is responsible freaks out when it's running from a hibernated state). My finger of suspicion is the Intel WiFi, I've seen a few people with Ryzen builds saying that Intel WiFi blue screens their rigs. I know my CPU, GPU, RAM, and Board are in working order, I've extensively stress tested them. I'm no good at diagnosing BSOD reports, so I'd appreciate any help people can offer in tracking down the culprit.

The actual bugcheck is 0x0000009F (DRIVER_POWER_STATE_FAILURE), I can't track down the fault because the process actually triggering the bugcheck is ntoskrnl. I've uploaded the minidump, if anyone can help me hunt this down I'd appreciate it. The problem doesn't happen if I disable fast boot by turning hibernation off, but I don't want to disable useful functionality unless I really need to.

Link to comment
Share on other sites

install (wifi, motherboard chipset, gpu) driver direct from manufacturer and do not let windows OS download/install the drivers for you.

Link to comment
Share on other sites

DaRT says

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: ffff850ca8da5060, Physical Device Object of the stack
Arg3: ffff8308022378f0, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffff850ca82b2640, The blocked IRP
 

but you are on the insider preview so debugging wont be easy you might want to revert to the creators update.

https://pastebin.com/aTCTkHLk

Edited by TPreston
Link to comment
Share on other sites

6 minutes ago, TPreston said:

DaRT says

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: ffff850ca8da5060, Physical Device Object of the stack
Arg3: ffff8308022378f0, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffff850ca82b2640, The blocked IRP
 

but you are on the insider preview so debugging wont be easy you might want to revert to the creators update.

https://pastebin.com/aTCTkHLk

I don't think this has anything to do with the insider channel, I had the same issues with the Creator's update before I switched myself onto the insider program. Whatever this is, it's persisted across a lot of build and driver changes.

I've had a look at your debugging trace, but unless I'm reading it wrong, it's still not telling me what driver is actually causing the IRP stall.

Link to comment
Share on other sites

Just now, Javik said:

I don't think this has anything to do with the insider channel, I had the same issues with the Creator's update before I switched myself onto the insider program. Whatever this is, it's persisted across a lot of build and driver changes.

I've had a look at your debugging trace, but unless I'm reading it wrong, it's still not telling me what driver is actually causing the IRP stall.

It would make it easier to diagnose because there are symbols available, But you are right this is not looking like simple driver related crash otherwise it would pinpoint the driver at fault. 

 

Can you load in safe mode and try to cause the crash there (to further rule out the chance that a driver is at fault) 

Link to comment
Share on other sites

2 minutes ago, TPreston said:

It would make it easier to diagnose because there are symbols available, But you are right this is not looking like simple driver related crash otherwise it would pinpoint the driver at fault. 

 

Can you load in safe mode and try to cause the crash there (to further rule out the chance that a driver is at fault) 

Might be tricky, as the problem *only* seems to occur when I boot the computer up in hybrid boot mode (hibernated kernel and driver data), and I understand that booting in safe mode will trigger a full boot even if you shut the computer down first. I'll try it and see if I can trigger the problem in safe mode, but I don't expect i'll be able to.

Link to comment
Share on other sites

1 hour ago, TPreston said:

It would make it easier to diagnose because there are symbols available, But you are right this is not looking like simple driver related crash otherwise it would pinpoint the driver at fault. 

 

Can you load in safe mode and try to cause the crash there (to further rule out the chance that a driver is at fault) 

Ok, so I tried to get the issue to replicate in safe mode and as I predicted it didn't do it in safe mode, however after installing the latest build (which re-enabled hybrid boot) the bugcheck reappeared, and I also saw a second bugcheck 0x000000EF (CRITICAL_PROCESS_DIED). Triggered again by ntoskrnl, and seemingly no more helpful than the previous crash. I've upped the minidump for this crash in case it's of any use.

 

Seems like both bugchecks are related to the same memory address (1637D0), so I expect they're related.

Link to comment
Share on other sites

image.thumb.png.d5ad3c1ca80d21e04dfa9aefa69f2b20.png

 

I think this means it's something in the PCI Express root complex, but I'm not that good at reading memory addresses?

Link to comment
Share on other sites

Is XMP enable?

 

If so, try disabling it.

 

_____________________________________________________

 

Damn, you have the AsRock X370 Taichi?

 

That was the motherboard I wanted, but it was OOS.

Link to comment
Share on other sites

Wouldnt be surprised if Kaspersky is causing it. Could be the version of Win10 you're using as well 16294

 

Possible this file is causing it vmbkmclr.sys. I think it belongs to Hyper-V

 

 

 

 

Link to comment
Share on other sites

14 hours ago, TPreston said:

It would make it easier to diagnose because there are symbols available, But you are right this is not looking like simple driver related crash otherwise it would pinpoint the driver at fault. 

 

Can you load in safe mode and try to cause the crash there (to further rule out the chance that a driver is at fault) 

Yea ... this.  Hard to diagnose something when symbols aren't available.  The last build with local symbols was 16278 (afaik) ... tried the msdl but no-go with that.  I couldn't find anything for 16294 ... so yea ... unless I'm missing something (never tried WinDbg on Insider Previews).  Makes the minidump's kinda pointless.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.