BurnInTest and Memtest86 not agreeing?

[Not One Of Us]

So I've been experiencing problems across two different installs on the same computer (one was a five-year running Win7 64-bit install on an HDD, the other (current) is a new install of the same OS on an SSD). The issues have only been happening in the past week, but I'll get more into that if need be. For now, my question:

While trying to diagnose my problems, I performed a memtest (latest version). Two and a half passes, all good. Figured, not the memory, then. After another day of trying to fix this machine, I tried out BurnInTest - originally just for stress testing other things, but also decided to give the RAM ago. I soon started getting errors for the RAM in BurnInTest. I ran the test again, full throttle, only on the RAM. 30% into second Cycle 0 Testing and the errors came in like mad.

This perplexes me, as Memtest86 saw no problems in over an hour of running, yet BurnInTest got a bunch within five minutes.

Any ideas? Fully up to going into the details of the problems I've been having, as until I can get this resolved my computer won't be very productive (holding out hope my browser doesn't crash while typing this.)

[David (PassMark)]

Which version of MemTest86 were you running? There is a V7 beta release which should be more effective than earlier versions.
http://www.passmark.com/forum/showth...86-v7-0-Beta-1

What were the exact errors from the BurnInTest log?

It could well be that the RAM is bad. But there are other possibilities as well. For example it might be temperature related, or it might be a bad buggy device driver overwriting RAM it shouldn't be writing to causing corruption.

What are the system specs. The RAM specs in particular.

[Not One Of Us]

Memtest 6.3.0. I'll give V7 beta test shortly.

Basic computer information:

CPU: i5-2500k
GPU: GTX 970
Motherboard: Gigabyte Z68X-UD4-B3
RAM: Corsair DDR3 (4GB x4) - model: CML16GX3M4AS1600C9 (rated 1600, clocked at 1333)

Here's my latest BurnInTest RAM test log: http://pastebin.com/W5Fv2qdW

Other notes: while my suspicions have come down to Drivers, RAM, or Video card (and/or its VRAM), I think the latter is ruled out (at least I want it to be). RAM *would* be my immediate assumption, but the differences in Memtest and the RAM test in BurnInTest have me perplexed at the moment. Drivers are second in mind, and the one I've mainly been working on, but that could be so many things. Still working on that.

Additional info: CPU is overclocked to 3.6 (from 3.3). Temperatures have been acceptable, with the highest being 69C under torture tests in Prime95 (and 61C maxed in BurnInTest's own CPU stress test, which, strangely, doesn't max the TDP like Prime95 does). The CPU had been at 4GHz since last November, and I only just yesterday toned it down to 3.6 - not that there was any temp issues, just did it in case. But heat in all monitored zones (CPU, GPU, system) are all normal.

GPU drivers in that log should list an older Nvidia driver from early March this year. I did this during my driver tests, as I had been using an even older version when the problems started appearing earlier this week. I then switched to the latest (early May) a day ago, but that resulted in no change. Thus went back to what's regarded as most recent, stable release (early March drivers). Still no difference.

[Not One Of Us]

Update on my situation:

Based on more research and testing, I decided to just get new RAM to rule this out and (hopefully) resolve this issue. After installing the RAM and doing the BurnInTest for the RAM at full throttle, it came up with no errors in fifteen minutes, when before it would get a flood of errors with in three minutes every time.

Current conclusion is that the problem has been resolved: it was the RAM all along. Why Memtest didn't pick this up still puzzles me, but there was something I should've done but didn't want to deal with (computer, while in a spot well ventilated, is not easy to get to) - do a stick-at-a-time run on Memtest. So yeah, laziness.

Here's some details that may be of interest to Passmark: In my research, I learned that some have had a similar issue with Memtest not detecting errors it usually would. In my experience of Memtest (since the late 90s? Can't recall, been so long), if the RAM is bad, you'll almost always see errors quickly on the first pass. Even with that, it was still generally suggested to let it run for at least a few passes (the more the merrier). With my latest Memtest run, it had done four full passes with no errors. This indicated to me that all was well with the hardware. However, as I read around, some have had Memtest do nine or more passes with no problems, but once they started doing it stick-by-stick, the errors came quickly for specific sticks.

Obviously, I should've done what is common knowledge in this area, but didn't because lazy.

Anyways, while I was planning to do this, I got my new RAM sticks in and just thought, screw it, put the new ones in, do the BurnInTest, uh, test, and, oh hey, all good.

So the plan now is just to overload my system as much as I can to see if it's stable. If you don't hear back from me in a week, consider this resolved.

Of additional note, I still remain curious why a desktop software (BurnInTest) was able to detect the errors so quickly, while Memtest seemed unable to. I would've thought the long-reliable test software at boot would be more, well, reliable than one ran from the OS.

[David (PassMark)]

Not really sure about the difference, but our suspicious is as follows.

The old version of MemTest86, V4, ran on BIOS. It was able to multi-thread, by directly doing it at a very low level if the CPU supported it.

MemTest86 V5,6 & 7 all run in UEFI. Which is like a tiny operating system, hard coded into the firmware of all new PCs. UEFI supports threading via function calls (not direct low level threading anymore). But UEFI is still kind of new and a bit buggy as it doesn't get tested very well by the vendors. Old UEFI doesn't support threading at all and some new UEFI versions have multi-threading bugs. This stopped MemTest86 using multi-threading by default. You could still try and turn it on from the settings page however.

With V7 of MemTest86 we are hoping to switch on threading by default (when supported by the hardware). Our hope is that this will place more load on the system, generate more heat and provoke more RAM failure.