Errors in RAM -Error Verifying Data in RAM

[gbu]

Ive been having lagging problems with my PC so was advised to use Burnintest to see if i could test the RAM

I have 2x 2GB Corsair ram in dual configuration.

When i run the test i get Errors namely Error Verifying Data in RAM

The thing is i then run each stick individually and no errors where found.

I ran them in both DIMM A1 and then B1 to test all slots and each stick and there was no errors but the minute i put them both in the errors appear, any ideas as to what it could be please

running Windows 7 64Bit

[David (PassMark)]

If you get the error Error Verifying Data in RAM, then the RAM is almost surely bad. (there is a small chance it might be the MB or CPU however).

When testing 1 stick at a time the error might be hidden. The test can't test RAM that is in use by the operating system. And when testing with a single stick a much higher percentage of the RAM will be in use by the O/S.

Given at least one of the sticks is probably bad I would by a new stick then retest, or return them for replacement. You might also want to have a look at memtest86, as this tool doesn't use Windows the amount of RAM hidden by the O/S is less.

In general bad RAM will cause a application or system crash. It would be strange for bad RAM to manifest itself as "lagging problems".

[gbu]

Thankyou for your reply, i have since tested with memtest but that passed and i had no errors, i then just did a new test with burnintest and the error Error Verifying Data in RAM appeared again?

When i referred to the 'lagging problems'i hope i can explain, the problem is that if say for example MS is installing an update or i am installing a program i cant seem to run or access another program for a few seconds(sometimes 10secs) when i cleck on anything i get the blue circle on the cursor appear and i have to wait (which i call lagging problems) is this normal?

[David (PassMark)]

Yes, if your computer is installing an update, or you are installing a new package, then the computer will slow down while this takes place. This is more or less normal, especially if you have a slow hard drive and older CPU.

[gbu]

My pc is only 6 months old though with a quad core 2.6 cpu and asus pql/epu motherboard, would it really be that slow during updates?

Also why would burnintest give errors but memtest doesnt is one more efficient then the other?

[David (PassMark)]

Hard to judge without seeing the PC. But I think pauses of a few second while installing software are nothing to be concerned about.

BurnInTest might be detecting RAM faults that memtest isn't if the error is caused for example by some external factor, or the access pattern.

When using BurnInTest in Windows more components in your system will have some activity on them. e.g. the video card, network card, etc.. will be in use. With memtest86 really only the RAM and CPU get any use.

The extra activity and being booted in Windows could cause,
- additional heat in the system
- additional EMI in the box
- more load and more variation on the load, on the PSU.
- different RAM access patterns & CPU cache usage.

Any of these items might provoke a fault in RAM if the RAM was marginal. But as mentioned above there is a small chance it might be the MB or CPU however.

[DaveC]

I decided not to start a new string, but reply to this instead.
My system and OS are different, running a dual processor Westmere on 64 bit RHEL 5.5.
The system has 128GB of memory in 32x4GB DIMMs.
The problem I have is that during a 16 hour run of burnintest last night, the RAM test reported 6 "error verifying data" errors. Nowhere in the reports does the CPU that detected the error, a location of the error and the "good" and "bad" data. Basically the report was void of any useful information in triaging failure.
Is there a way to tun on more verbose logging or otherwise triaging the nature of these errors?

Test report appended below
LOG NOTE: 2010-11-22 16:10:43, Status, Starting test run

LOG NOTE: 2010-11-22 16:10:47, Status, Completed started test run

SERIOUS: 2010-11-22 19:17:33, RAM, Error verifying data in RAM

SERIOUS: 2010-11-22 19:17:44, RAM, Error verifying data in RAM

SERIOUS: 2010-11-23 00:24:29, RAM, Error verifying data in RAM

SERIOUS: 2010-11-23 00:26:48, RAM, Error verifying data in RAM

SERIOUS: 2010-11-23 05:30:34, RAM, Error verifying data in RAM

SERIOUS: 2010-11-23 05:35:52, RAM, Error verifying data in RAM

LOG NOTE: 2010-11-23 08:50:29, Status, Test run stopped

(null)
(null)

**************
RESULT SUMMARY
**************
Test Start time: Mon Nov 22 16:10:43 2010
Test Stop time: Tue Nov 23 08:50:25 2010
Test Duration: 016h 39m 42s

Test Name Cycles Operations Result Errors Last Error
CPU - Maths 79597 71.895 Trillion PASS 0 No errors
Memory (RAM) 57 777 Billion FAIL 6 Error verifying data in RAM
2D Graphics 19647 1.643 Billion PASS 0 No errors
Disk: Startup Disk [/dev/sda1] 930 823 Billion PASS 0 No errors
Network: eth0 (127.0.0.1) 38284117 336 Billion PASS 0 No errors
TEST RUN FAILED
[root@ban21uut058 ~]#

[Ian (PassMark)]

Additional logging is available by selecting:
1) Preferences->RAM, Log memory allocation
2) Preferences->Logging, Trace File detail level = Activity trace 2.

It won't however tell you which particular RAM module is faulty.