Windows 10: Different Bug Check codes in ntoskrnl.exe only after wakeup from sleep

Disclaimer: I'm starting this crosspost to the microsoft forums since there where only 16 views in 5 days and only one reply and I've come to some conclusion. I'm curios if thats reasonably and maybe here is someone around with more Windows debugging experience than me who can pin point it some more.

____________________________________________________________________________________________________ __________
Post:


The system is a new build (2 weeks) for gaming mostly and i commonly run into a system that won't wake up after putting it into the sleep mode. It's not always the case, but maybe 1 out of 3 times, it won't wake up properly. After trying it to wake up per keyboard/mouse, the power LEDs lid up for maybe 1-2 secs and then the system shuts down. When i press a random key on the keyboard, the num lock LED still turns on.

Besides the mini dumps, i also get "Event 41 - Kernel Power" entries in the system log. Bug Check Codes: 0xd1, 0x1e, 0xef.

• The system is new, so maybe hardware related?
• The Stop Codes only happen after sleep during wake up so far.
• I am sure that i had the same problem with the one week i was running Windows 8.1 before i updated to Windows 10. So it's maybe not Windows 10 related.
• I did run a sfc /scannnow, it passed without errors.
• memtest86 run for 8h without any error.
• I already removed a gigabyte driver gdrv.sys, after I tired to solve the problem and thought it is driver related. I ran verifier.exe on non microsoft drivers turning on everything except Force IRQL Checking and Low Resource Simulation and in the one day i way running it, that driver caused some shutdowns.
• I already updated all drivers and the bios (F8)
• SMART long tests without errors
• chkdsk /F /R C: is also clean
• I almost uninstalled all software with drivers (.sys) except those for (well known) Hardware. Not that much was installed yet, but ..

So, my main question, can it even be a hardware problem, even though it happens only during wake up after a sleep, otherwise the system is just fine (run for 3 days without problems)?!

The mcupdate_GenuineIntel.dll in the stack trace makes me think it's either a Windows software fault (unlikely) or a hardware issue with my Gigabyte Mainboard and/or the Intel CPU. Is that reasonable, or any other thing i could test before RMA? Maybe run a linux and see if i can sleep/suspend there? But than i again, i'm not sure what that would prove at all..

Thanks in advance for any hints, Johannes.

:)

 

Different Bug Check codes in ntoskrnl.exe only after wake up from sleep.

I'm happy to announce that I found a solution to my sleep problems. After running a successfull test with the Intel Processor Diagnostic Tool and multiple perfect working sleep/wakeup cycles under linux, it must have been some Windows issue.

Thanks go over to the the HP Forum and this dude.

I never would have come up with that, since i didn't even know my consumer mainboard would have a Intel Managment Interface installed. So, an outdated driver causes the issue in my case. I'm sure i also didn't install any driver for that in the first place,
so maybe Microsoft could ship a newer version with some Windows 10 update or update their online search for a newer version.

Addendum: Two days ago I started a
crosspost with the tenforums in the hope to find a solution or at least some confirmation in my drawn conclusions..

 

Different Bug Check codes in ntoskrnl.exe only after wake up from sleep.

Just to let you know, I finally found a solution and it wasn't the IMEI driver at all. The system still ran into BSODs, I just wasn't running any high memory applications which masked the error..

After buying a 28€ GT210 von MSI and running into the same problems, I focused back on the mainboard / ram, since the board was the only thing I really didn't swapped out for testing. I figured out, that indeed not only the OS memory was screwed sometimes,
but also the applications memory, but mostly windows services crashed and immediately restarted and nothing I regularly see on the desktop and noticed. The wired thing though was, that running the system for, say, three days straight without entering the sleep
mode, everything was perfectly fine, no crashes, nothing in the Windows Event Viewer. But starting a high memory usage application like Battle Field 4 to fill the ram and entering suspend immediately corrupted the ram content.

So, I reloaded memtest86, this time for 6 passes and not a single error. I was really out of ideas and went back to searching the web to specially search for
crucial ballistix gigabyte sleep issues and found that many people with gigabyte boards run into sleep errors which mostly weren't resolved. But I found a single post were someone mentioned that raising the ram voltage solved his particular problem.
I thought I'd give it a try and tried the JEDEC instead of the XMP profile with no luck, but raising the ram voltage by one tick from 1.50V to 1.52V successfully brushed away all my stability problems! I can finally use this crappy machine! The exact ram DIMM
is even listed on their compatibility sheet.

tl;dr:

For everyone having sleep issues with application crashes, BSODs after entering sleep and having a totally fine system else, might give a try in raising the ram voltage a bit. It looks like the voltage drops below some specific threshold by entering
the S3 state which corrupts the DIMMs content. I cannot explain it otherwise.

 

I'm happy to announce that I found a solution to my sleep problems. After running a successfull test with the Intel Processor Diagnostic Tool and multiple perfect working sleep/wakeup cycles under linux, it must have been some Windows issue.

Thanks go over to the the HP Forum and this dude:
I never would have come up with that, since i didn't even know my consumer mainboard would have a Intel Managment Interface installed. So, an outdated driver caused the issue in my case. I'm sure i also didn't install any driver for that in the first place, so maybe Microsoft should ship a newer version with some Windows 10 update or update their online search for a newer version.

 

Just to let you know, I finally found a solution and it wasn't the IMEI driver at all. The system still ran into BSODs, I just wasn't running any high memory applications which masked the error..

After buying a 28 GT210 von MSI and running into the same problems, I focused back on the mainboard / ram, since the board was the only thing I really didn't swapped out for testing. I figured out, that indeed not only the OS memory was screwed sometimes, but also the applications memory, but mostly windows services crashed and immediately restarted and nothing I regularly see on the desktop and noticed. The wired thing though was, that running the system for, say, three days straight without entering the sleep mode, everything was perfectly fine, no crashes, nothing in the Windows Event Viewer. But starting a high memory usage application like Battle Field 4 to fill the ram and entering suspend immediately corrupted the ram content.

So, I reloaded memtest86, this time for 6 passes and not a single error. I was really out of ideas and went back to searching the web to specially search for crucial ballistix gigabyte sleep issues and found that many people with gigabyte boards run into sleep errors which mostly weren't resolved. But I found a single post were someone mentioned that raising the ram voltage solved his particular problem. I thought I'd give it a try and tried the JEDEC instead of the XMP profile with no luck, but raising the ram voltage by one tick from 1.50V to 1.52V successfully brushed away all my stability problems! I can finally use this crappy machine! The exact ram DIMM is even listed on their compatibility sheet.

tl;dr:

For everyone having sleep issues with application crashes, BSODs after entering sleep and having a totally fine system else, might give a try in raising the ram voltage a bit. It looks like the voltage drops below some specific threshold by entering the S3 state which corrupts the DIMMs content. I cannot explain it otherwise.