Noir Angel Posted September 23, 2017 Share Posted September 23, 2017 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 More sharing options...
Mindovermaster Moderator Posted September 23, 2017 Moderator Share Posted September 23, 2017 Did you update your BIOS? I don't know how relavent this is, but: https://support.microsoft.com/en-us/help/977186/error-message-when-you-try-to-resume-a-windows-7-based-or-a-windows-se Link to comment Share on other sites More sharing options...
atcapistrano Posted September 23, 2017 Share Posted September 23, 2017 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 More sharing options...
TPreston Posted September 23, 2017 Share Posted September 23, 2017 (edited) 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 September 23, 2017 by TPreston Jim K 1 Share Link to comment Share on other sites More sharing options...
Noir Angel Posted September 23, 2017 Author Share Posted September 23, 2017 My BIOS is up to date, and I always update drivers when they become available. Link to comment Share on other sites More sharing options...
Noir Angel Posted September 23, 2017 Author Share Posted September 23, 2017 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 More sharing options...
TPreston Posted September 23, 2017 Share Posted September 23, 2017 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 More sharing options...
Noir Angel Posted September 23, 2017 Author Share Posted September 23, 2017 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. TPreston 1 Share Link to comment Share on other sites More sharing options...
Noir Angel Posted September 23, 2017 Author Share Posted September 23, 2017 (edited) 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 More sharing options...
xendrome Posted September 23, 2017 Share Posted September 23, 2017 Maybe get AIDA64 or something to see what device is operating in that memory address. Link to comment Share on other sites More sharing options...
Noir Angel Posted September 23, 2017 Author Share Posted September 23, 2017 (edited) 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 More sharing options...
Mockingbird Posted September 24, 2017 Share Posted September 24, 2017 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 More sharing options...
John.D Posted September 24, 2017 Share Posted September 24, 2017 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 More sharing options...
Jim K Global Moderator Posted September 24, 2017 Global Moderator Share Posted September 24, 2017 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 More sharing options...
Recommended Posts