Can random reboots (no BSOD) be caused by bad RAM?

[absurddreams]

Hi everyone. That's not my first build and not my first hardware-related problem, so usually I know what I'm doing. Yet this time, it really drives me nuts.
So, about a month ago I started experiencing random reboots. No BSOD (so no memory dumps whatsoever), just kernel power error 41 logged on boot with no useful information. There seems to be no correlation with what I'm doing, e.g. CPU load. The temps are fine, not more than 60C on full load, below 40C 95% of the time. There's also no steady frequency of crashes, but subjectively it went from ~1/day to 2/day in a couple of weeks.
Steps I've taken:
1) Installed the powerful UPS - no effect.
2) Changed the PSU (redoing all connections in process) - no effect.
3) Reinstalled Windows - no effect.
4) Moved both of the RAM sticks to different slots - seemingly, this reduced the frequency of crashes somewhat.
5) Disabled XMP profile (so RAM runs at 2133MHz now) - it seems to have further reduced the amount of crashes, yet they still happen.
So it really looks like bad RAM at the moment, but to my knowledge, bad RAM almost always manifests itself with BSODs. Does anyone have experience which is similar to mine - RAM so bad that it just forces PC to reboot? And I would be eternally grateful for any idea for further troubleshooting.

I can just replace the RAM of course, but I would prefer to be sure that it will solve the problem. My fear is that it can be CPU memory controller, which would be much worse.

Relevant specs: X99P-SLI Gigabyte motherboard, i7-6800K, 2x16Gb GeiL DDR4-2400 sticks.

 

[erpguy53]

If you suspect the RAM chips are the problem, try running Memtest86 on your computer first to see if there are problems.

 

[Kursah]

Sounds like the next step from suspecting the RAM is to diagnose it. I have seen this issue, the worst was on my first Core2 system with some shitty Buffalo FireStix DDR2-800...supposedly known for OC-ing, I went through 3 bad sets and refunded (also RMA'd 2 Asus P5B Deluxe boards during the process, but the RAM always failed).

What's the XMP timing specs for the GeiL RAM? Might as well go to your UserCP and fill out your system specs, it's a handy feature here at TPU well all look forward to folks using.

To add onto using Memtest 86+, I would also recommend you try a couple of different things.

• Test with each stick independently in Memtest and standard usage.
• Try a small increase in voltage (+.05-.1) in Memtest and standard usage.
• Try loosening timings (add 1-2 to each timing section...research this a little before trying. So going from 9-9-9-24 CL1 to 10-10-10-32 CL2 would be an example.
• Try different RAM if you have some to ensure its not your board or IMC. A spare stick for diag is fairly cheap and a good thing to have around.

You mentioned that load doesn't matter...but have you been able to notice if it happens at idle more than load or vice versa? In my experience, if crashing more at idle and low loads it's likely a RAM issue. If happening with more frequency during system loads, then I'd wager to think it was the IMC. Having a test stick of RAM would be a good help to confirm either suspicion though, doesn't need to be the same specs or size, just something that will work for testing and get you by in the event of a memory failure and awaiting RMA or delivery.

Welcome to TPU and I hope we can help you get your issue sorted!

 

[damric]

It can be a bad hdd or ssd. They can cause weird crashes when they start going downhill.

Edit: also bad mobo southbridge or even bad sata connector causes same symptom.

 

[Black.Raven]

My X58 has ram slots that are only secured on one side. So when I put them in and applied force on one side and then the other side, memtest read
de ram sticks as faulty. When I reseated the ram pushing on both sides everything was fine. I found this when testing the ram sticks one by one.

If you want to test the ram:

Get memtest or a boot disk.

Test one by one (pushing on both sides when installing the ram), so you can identify which stick is bad.
When you have identified the stick(s) put in the remaining stick and run the memtest longer.

I see this is already explained above

Mostly faulty memory is detected on the first pass, But it can be detected later. (Experience) That is why
you first test them fast separately and later test the rest to make sure it is safe.

Hope this helps. ATB

 

[absurddreams]

Sorry for not following up - it seems that crashes are gone (at least almost). The most likely cause was probably bad connection between MB and RAM. The fact that RAM sticks are indeed secured on one side was also likely contributing to the issue.

Thanks for the input!

 

[Jetster]

Check the event log

 

[natr0n]

could be ssd