BurnIn Test v9.2(1002) - Memory (RAM) test failure

[Andy_Chen]

Hi support team,

We got Memory (RAM) test failure during BurnIn test on laptop which have discrete GPU.
This failure only occurred on 4GB RAM. But It's cannot be reproduce if system RAM greater than 4GB or UMA system.
I found there are similar issue reported from another topics and it seems the available RAM is not enough under high load situation after checked the level 2 trace log.
Please refer our log file in the attachment (It need to be unzip by 7z)

May I know is there any suggestion to execute BurnIn test on the system with low or no free RAM available?


Here is detail information:
OS: Windows 10 19042.928
BurnIn test version: v9.2 (1002)
CPU: Tiger Lake-H
Discrete GPU: NVIDIA MX450
RAM: DDR4 4GB x1

BurnIn Test configuration:
CPU: 40%
2D Graphics: 40%
3D Graphics: 50%
Disk: 100%
Memory (RAM): 50%

Figure-1 The snapshot of result:

[David (PassMark)]

You are a few patch releases behind. So you should update BurnIntest. See,
https://www.passmark.com/products/bu...st/history.php

4GB isn't enough RAM to run Windows anymore, unless you only do a few Emails and open one or two browser tabs. So it will be a a pretty useless machine and shouldn't really be sold anymore.

This is especially the case if you are using integrated graphics, (integrated + discrete in this case). So you only have 3.7GB before you even boot Windows. Then the video card uses another 1GB for video RAM.

So you can see in the log lines like this,
Memory (RAM), System Memory Total: 3822MB, Test RAM allocated 4MB

So there is only 4MB (from 4GB installed) that is being tested, as all the other memory is in use by Windows, the disk cache, background processes, etc... Some RAM needs to be left free for Windows to use, otherwise the O/S will crash. It is kind of pointless to run a RAM test when there is no available to test (0.1% of the total in this case).

This doesn't fully explain the crash in the memory test that resulted in the "Memory Test Failure" message you saw. Can you re-run the tests with 8GB? Can you run the RAM test by itself with 4GB?

[Andy_Chen]

Hi David,

Sure, I will try the latest Burnintest to test.

When the test running, Task Manager report the available RAM around 300~400MB
May I know why the test RAM only be allocated 4MB?

In addition, 8GB RAM cannot reproduce this error and 4GB discrete have fail rate. Let me share the detail test record:
1. 4GB + Discrete GPU -> Fail, F/R:2/5@2nd,4th
2. 8GB + Discrete GPU -> Pass. F/R: 0/3
Each test duration = 15 minutes. If get PASS result then reboot the system and re-run again.

By the way, the error will disappear If modify RAM test mode from Standard to Multi-process Torture Test (Number of process=10 / % of RAM per process=1)
Is it a good way to test if system into a low RAM available state?

[David (PassMark)]

Task Manager report the available RAM around 300~400MB
May I know why the test RAM only be allocated 4MB?

1) It isn't safe to run Windows with so little free RAM
2) We don't want to force Windows into swapping to disk, as this also causes a world of pain (massive performance loss, freezes, timeouts, and eventual crashes).

Note that the amount of RAM being tested varied as memory use from other tasks varied and memory pages were swapped to disk. At some points 200MB was being tested. So it wasn't only testing 4MB all the time.

We'll setup a test system next week with ~3GB of RAM and what errors we get. We don't expect it be able to test the RAM, as there will be no free RAM, but it should be more graceful in it's failure.

Is it a good way to test if system into a low RAM available state?

Do two test runs in series.
1st run: Run all tests you need except the RAM test.
2nd run: Run just the RAM test.

Or don't boot Windows at all and use Memtest86 for RAM testing. Without Windows and other test and background processes there should be at 3GB+ RAM available for testing.

[Andy_Chen]

Hi David,

Update my test result:

>> 1st run: Run all tests you need except the RAM test.
>> 2nd run: Run just the RAM test.
Both tests are got pass results(F/R: 0/5, run 15 minutes in each iteration)
Memtest86 also got positive result with pre-boot environment.
BurnIn 9.2 v1005 under testing, will update the result later

As you mentioned, your suggestion is to use greater than 4GB RAM to perform BurnIn test with multiple items?

[David (PassMark)]

your suggestion is to use greater than 4GB RAM to perform BurnIn test with multiple items?

It is your hardware, so you get to make the choice of what hardware to include with your systems.
But you need to be aware that with 4GB of installed RAM, there isn't much point running a RAM test in Windows, as 4GB is barely enough for Windows anymore, and there won't be much free RAM to test, especially with all other tests running at the same time. Shared video memory can make it much much worse as well.

But as mentioned we are doing some testing here this week to try and make the handling of the low RAM situation more graceful in BurnInTest. It shouldn't be crashing, but it isn't clear that this point if that is a problem with BurnInTest itself or some other bug in 3rd party software (during a low RAM situation) causing a failure.

[Andy_Chen]

Got it, thank you for your prompt reply.

[David (PassMark)]

There is a new release of BurnInTest for Windows out today. V9.2 build 1006.
https://www.passmark.com/products/bu...st/history.php

Relevant changes are,

1. RAM Test: Made some changes to avoid a verification error being logged when the system was low on memory, in some cases a write phase was aborted due to the low memory but the verification phase would continue instead of being skipped which would lead to a verification error for some patterns. This would only occur on systems that had nearly no free RAM before the start of the RAM test . So typically only on systems with <4GB of RAM installed and only when background tasks, other than the RAM test, were already using a lot of the available RAM.
2. RAM Test: Made some changes when allocating/deallocating memory for the test in low memory situations, fixing a potential bug that could cause verification errors when small amounts of RAM (<100 MB) were being allocated/deallocated rapidly by the test when the system was low on memory. There isn't much point running the RAM test when you only have less than 100MB of free RAM, but if you do the error case is now handled better.
3. RAM Test: made some changes so multiple copies of BurnInTest running the RAM test will have separate shared memory blocks, still not recommended to run multiple copies of BurnInTest at the same time however.