fillswitch

Member
Joined
Sep 3, 2014
Messages
61
Hello!

I've been troubleshooting this issue for months now and it is really frustrating. My issue is every time my computer goes to sleep/is shut down, when I start it back up, the computer works normally for about 7-10mins or so, and then BSODs. Once I reboot from the BSOD, my computer runs just fine until the next sleep-bsod episode

I've done Memtest86+ on my RAM modules to see if they were the culprit.
Module 1: Link Removed
Module 2: Link Removed

I noticed something strange on these tests though. When I would test my memory on slots 1-2, Memtest86+ would read my memory's speeds/timings correctly: 1866 9-10-9-28. But when I tested the same modules in slots 3-4, I would get half of that: DDR3-784 4-5-5-15. I then checked if slots 3-4 read with the lower speeds/timings in CPU-Z, but they did not; they read with the normal 1866 9-10-9-28. I'm not sure if that's an indicator of a problem at all, but it seems unlikely.

Trusting my logic, I decided to see if having both modules in slots 1-2 would alleviate the issue. I put the computer to sleep overnight (usually the scenario that results in a BSOD) and upon waking from sleep, it seemed fine for about 10 minutes (just like before every other BSOD), then it crashed: Link Removed

Here's my build for reference: Link Removed

Any ideas why this is happening?
 
Last edited:
Solution
Hey guys!

Got my RAM yesterday and installed them. I turned on XMP and let them run. By now, I've been through 4 wake cycles and NO BSODs!



I think I can finally lay this one to rest. Thanks again for all your help! I really really appreciate it all!
Just have one stick in slot 1 now. Just woke up the machine. Will see if we BSOD anytime soon.

I will also remove the pagefile and report back.
 
Scratch that. Since I had to restart because of the pagefile, I'll check in the morning when I wake my computer. I don't my computer BSODs after restarting.
 
One thing I wanted to point out. I was working my way though reformatting my data (non-os) drives and I noticed that my M: drive is marked as a System drive, though my OS is on my C: drive. I will be reformatting both drives and reinstalling the OS (my third time doing this -_-). Sounded similar to this issue: Link Removed

I'll keep you all posted.
 
I did see your PM, but I wanted to take care of this issue, because it seems like there was something fundamentally wrong with how I installed my OS. I was not using UEFI when installing my OS the first time. I have changed my BIOS settings to boot with only UEFI and have installed my new OS (without the other drives plugged in, so Windows doesn't install any system files on those drives). I'll be installing Windows Updates now with my fresh copy.

If I still BDOS, I will come back to the drive tests/stripdown/driver verifier. I wasn't trying to go against your advice, but it seemed like something definitely was wrong with how I originally installed my OS.
 
Sure no worries Fil I was just making sure you'd seen the information. I'll await your next post..
 
I'm back! Freshly reformatted all drives and new OS. Let's get back to work

Currently, I have one RAM module in slot #1 and both HDDs plugged in.

I've run SeaTools on all my drives (Long test): Link Removed
My M: drive got stuck somehow, so I'm re-running it. I didn't see any errors on it on the limited time (8hrs) it ran.

I did get one BSOD after waking: Link Removed
(Might not be worth looking at, since I'm not at a stable point to test yet. Still doing the M: long test.)

Once the test is done, I will let the comp fall asleep then wake it up and check for BSODs. After that test, I'll run with Driver Verifier.

Thanks for hanging in there with me!
Fil
 
Code:
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 50, {fffffa0003baa660, 0, fffff800035e2a7c, 7}


Could not read faulting driver name
Probably caused by : memory_corruption ( nt!MiEmptyPageAccessLog+dc )

Followup: MachineOwner
Hey Fil,
thought i'd have a look see at the dump file as you just never know. As you can see memory corruption was listed and I'll copy and paste the main causes listed for this Bugcheck:

You'll notice that the causes mentioned are those that you've been testing. The only tests we have to think of next is perhaps the L2 cache or VRAM. This link will give you an app to test the VRAM on your card:
Link Removed
 
Ran long test on M: and got a message saying "Test taking too long... feel free to close..." (or something like that): Link Removed

I'm going to put my 2nd RAM module back and run the VRAM test you provided. I'll come back with results. Then, I'll restart with Drive Verifier.
 
Code:
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 3B, {c0000005, fffff880060b211b, fffff88007dced00, 0}

Probably caused by : dxgkrnl.sys ( dxgkrnl!DoublyLinkedList<DMMVIDPNSOURCEMODE>::DoublyLinkedList<DMMVIDPNSOURCEMODE>+df )

Followup: MachineOwner
Hey Fil,
another Bugcheck 3B although this time the graphic subsystem is being blamed. I checked through the driver stack and found some possible culprits:

AODDriver2.sys Wed Nov 21 07:44:04 2012: AMD Overdrive; also in EasyTune6 for Gigabyte motherboard Known BSOD issues in Win7

amd_sata.sys Fri Jun 28 05:50:15 2013: AMD Chipset driver. Please update using the driver found on motherboard support page:
http://www.gigabyte.com/products/product-page.aspx?pid=4672#driver

mvs91xx.sys Tue Jul 30 07:52:22 2013: Marvel AHCI driver. 2014 version available on motherboard support page:
http://www.gigabyte.com/products/product-page.aspx?pid=4672#driver

Update the drivers below from the links given. The versions found on support page are older.

Rt64win7.sys Tue Sep 27 15:50:33 2011: Realtek RTL8168D/8111D Family PCI-E Gigabit Ethernet please update:
Link Removed

RTKVHD64.sys Tue Dec 03 12:26:10 2013: Realtek High Definition Audio Function Driver please update:
Link Removed

Is your SSD running the latest firmware?

Also what mode are you running in IDE or ACHI?

Also I noticed you called one of your drives 'M' (I know you've mentioned this previously but I can be slow on the uptake sometimes lol) . I guess the reason for this is because you've removed some drives but still you'd need a few drives installed to get to the letter M. If you go to computer management via admin tools, click Storage, Disk management and there you should be able to change the Drive letter to D.
As a last thought try checking your advanced power options too just in case anything looks out of place.
 
Last edited:
Just updated the drivers above and restarted my comp. The Marvel AHCI driver download didn't come with an install exe, so I wasn't sure how to install it. Maybe you can shed some light on that?: Link Removed

My SSD firmware is up to date: Link Removed

I believe my I'm in ACHI mode. I checked my BIOS and I have two options.
  • One for SATA slots 0-3: Link Removed
  • One for SATA slots 4 and 5: Link Removed
So I have slots 0-3 as ACHI, which contains my SSD and M: drive, but my Z: drive (previously F is on port 4 and is marked as IDE. Should I change ports 4-5 as " as SATA type" instead?
Just for reference, here's my SATA ports listed: Link Removed

My M: drive has that letter because I went into Disk Management and changed the letter to M (mainly because it holds my Media). So that was a deliberate choice on my part. (Same thing with Z

And here's my adv power settings: Link Removed
I've tried messing with these in the past, but no dice. If you have any suggestions on the settings, I'd be happy to try them.

Fil
 
So I have slots 0-3 as ACHI, which contains my SSD and M: drive, but my Z: drive (previously F is on port 4 and is marked as IDE. Should I change ports 4-5 as " as SATA type" instead?
Yes.. That's how i run my board with an SSD and SATA drives combined.

Advanced Power settings.
Try setting the 'Sleep after' to like 60 minutes or even 30 minutes. 180 minutes is three hours. Also check if your hard drives are set to be turned off after a certain period of time. If they are change the setting to never. (simply type never in the space).
 
Sounds good. When I get back home, I will change the setting from IDE to SATA.

For now, I changed my sleep setting to 60mins and and hard drive power off setting to never.
 
When I got home, I woke my comp from sleep. now 45 minutes later, no BSOD. I've programs that I've seen trigger the BSOD (after sleep), but the comp seems stable. I will restart now to change the SATA setting in the BIOS. After that, I'm thinking of turning XMP back on.

Fingers crossed that we solved this issue!
 
Went out for a few hours. Since my comp is set to sleep at 60 mins, it was asleep when I got home. I resumed Windows and now, 60 mins later, we're still running. Ran the previous usual suspects (programs like chrome and itunes) and no BSOD.

So it could have been one of a few things that fixed this:
  • Updating the following drivers:
    • AMD Chipset driver
    • Realtek High Definition Audio Function Driver
    • Realtek RTL8168D/8111D Family PCI-E Gigabit Ethernet
  • Updating sleep setting to 60 minutes instead of 180 minutes
  • Updating HDD settings to never turn off
Since I did all three before re-testing sleep, I'm not sure which one did it.

Edit: I've just opted for turning on XMP. Seems to be running fine. I'll report what happens when I wake it from sleep tomorrow morning.
 
Last edited: