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!

:partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay::partay:

I think I can finally lay this one to rest. Thanks again for all your help! I really really appreciate it all!
Code:
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 24, {1904fb, fffff880025f4338, fffff880025f3b90, fffff880012e0d4f}

Probably caused by : Ntfs.sys ( Ntfs!TxfAccessCheck+9f )

Followup: MachineOwner
Hi Fil,
even though it's NTFS related the reason it crashed is because data held in the RAM couldn't be read:
Code:
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
You really need to test the RAM for longer as we discussed above. We've tested everything else more or less and it's all come up clean. Try running Memtest86 for at least 12hrs, longer if possible.
 


Just finished testing the RAM (both in the same slot):

Module 1 - Slot 1 (22hrs): Link Removed
Module 2 - Slot 1 (13hrs): Link Removed

So it doesn't seem that was the problem. I have disconnected one of my internal HDDs to see if that affects anything. I will post the results after my computer goes to sleep for the night and wakes up in the morning.
 


Ok Fil, thanks for posting the update. We'll track this down eventually I'm sure..

As an after thought try running this command in an admin command prompt:

Similar to the System File Checker is the DISM Tool. This will, if possible, download files to repair missing or corrupt data. Opn the admin command prompt and type:
DISM /Online /Cleanup-Image /RestoreHealth
Press enter and await results.
 


So I've rebooted from sleep yesterday, without my F:/ drive plugged in, and I haven't gotten a BSOD yet. I let it run for a good 15 mins before coming back to it and trying to use it. Still no BSODs =]

I tried to use the DISM command you posted, but I got an error: Link Removed

I will head to work in a bit and remote into my computer to see if it got a BSOD or not. I can then fix whatever I was doing wrong with the DISM command.
 


Nice job on finding the possible culprit. Now we have to determine what it is that's causing the bsod. The drive itself or something else perhaps. It could be that when the machine is returning from sleep the external drive isn't waking or powering up but that's just a guess. Try changing USB ports as not all ports are the same and if they are in a USB3 port try changing to a USB2 or lower.
 


This drive is actually an internal drive. I can try switching Sata ports. One thing to note, is my drives were from a previous build that accidentally had water spilled on it =[ So it may be the hardware itself.

I'm planning on moving formatting then adding the files back to my non-OS drives, to see if something left over from my previous build is causing the BSOD, like a bad format or something.
 


Cool, thanks for those links. I'm reformatting the drive now. One thing to note, my drive type was Dynamic as opposed to Basic. I don't remember why I changed it to a dynamic drive, but I couldn't get it to change back.

Once my drive is done formatting, I will run chkdsk and SeaTools on it. I will post any results here.
 


Thanks kemical!

I scanned my newly formatted drive with chkdsk and with SeaTools (Short Generic, Short Drive Self Check, and SMART check) and all passed with no errors. I've just woke my computer and I am using it with (what appears to be) no issues so far. It looks like it might've been the data on the disk or possibly the dynamic type? I'm not sure, but I think it's fixed =]

Now what I want to do (after making sure that the computer won't BSOD on me with the new reformatted drive) is re-adding XMP, so I can get the appropriate RAM speeds. Hopefully, that doesn't cause a BSOD itself.

Once again, I'll keep this thread posted.
 


Wow... I talked way too soon. Just as I was re-downloading WhoCrashed (ironically enough) my comp went into a fit of BSODs: Link Removed

I'm going to remove that drive (that I just formatted) again and see if this happens again.
 


Code:
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {fffff6fb7a6003b0, 2, 0, fffff80002e272fc}

Probably caused by : memory_corruption

Followup: memory_corruption
Hey Fil,
the other dump file pointed to invalid system memory being referenced and I wonder if you have a RAM slot that's faulty? I would still continue with your idea however as it brought results last time. (removing the drive).
If you still get a bsod after removing the F drive then it may be worth testing the slots. All you can do in this regard is test a stick in each slot. We know from previous testing that your RAM is probably good so any faults found would have to be the slot itself.
 


Another BSOD. This one came with my newly formatted drive removed from the computer: Link Removed

Next, I'll switch the slots that the RAM is in. Let me know what you think about the dump.
 


Code:
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 24, {1904fb, fffff8800334d578, fffff8800334cdd0, fffff80002ea696a}

Probably caused by : ntkrnlmp.exe ( nt!DeleteNodeFromTree+fa )

Followup: MachineOwner
Hi fil,
Bugcheck 24 is NTFS related but I also saw this:
Code:
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
I'm also going to ask a friend to look over this thread and see what, if anything, he thinks. Try running the Seatools on your C drive too.
 


Just got a fresh one: Link Removed

I had woken my computer from sleep about 20 minutes before the BSOD. I was just about to open SeaTools to run it against my C: drive. This was after I swapped my RAM from slots 1 and 2 to slots 3 and 4. A small diagram of what I mean by the slot #s (just making sure I get it right): [CPU] 4 2 3 1
 


Code:
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 3B, {c0000005, fffff8000314c657, fffff8800a780dd0, 0}

Probably caused by : ntkrnlmp.exe ( nt!CmNotifyRunDown+1bb )

Followup: MachineOwner
Hey Fil,
Bugcheck 3B can be caused by old or incorrect drivers, hardware faults (usually RAM) and/or corrupt data. After you've tested the slots if they pass ok then we'll run the driver verifier to just make sure this isn't a driver.
 


So with my last test, I got a BSOD as well. My RAM was in slots 3 and 4 instead of the 1 and 2 setup. So does this mean my slots are okay since they both get the same behavior?

Eventually, I still want to try:
  1. Reformatting my other internal drive ( M: ) and test for BSOD
  2. Unplugging M: all together and test for BSOD
  3. Using only one RAM module in slots 1 or 3 (maybe dual channel is doing something?)
We can run driver verifier too. Just let me know. I don't have a set test that I'm doing right now, but I am running SeaTools on both C: and M: drives. Let me know and I can remote into my computer (I'm at work now) and turn on driver verifier to test when I wake my computer when I get home from work.
 


Last edited:
Using only one RAM module in slots 1 or 3
You guys have done some serious work in this thread and I almost hate to butt in, but.....
I really like that idea.
Since you gave both sticks a pretty good ride with memtest in slot one with no errors, why not try running your machine for a while with a single stick in slot one and see if you can make it Blue Screen.
Again, my apologies for jumping in so late in the game, your idea just hit me as a good practical diagnostic step.
 


So with my last test, I got a BSOD as well. My RAM was in slots 3 and 4 instead of the 1 and 2 setup. So does this mean my slots are okay since they both get the same behavior?
Personally I'd test one stick in slot 1 then slot 2 and so on.(although as you tested both sticks in slot one the slot itself is probably fine) I wouldn't worry so much about it being in dual channel as we are really just testing slots.
I once had a user with a slot which although didn't have a stick inserted was tested and found faulty. Ultimately that was the cause of the issue. Now I'm not saying for a moment that's what is wrong with yours but we have to go through the motions if only to eliminate likely suspects.
Try something else for me too. As your getting NTFS errors along with RAM errors I wonder if this has something to do with a corrupt pagefile? Open your advanced system settings and remove the pagefile. You'll need to reboot after making the changes but once you've booted back up turn the pagefile back on setting it to automatic. See how you go.
 


Back
Top