• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Memtest86+ Guide/How To's

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

RedDragonXXX

Senior RAM Pornographer
Joined
Mar 3, 2005
Location
Jacksonville, FL
short-media and memtest sites used as reference

What's Memtest :shrug:

For you new people and rest of you guys that wonder what memtest is, well its a RAM reliability tester. It evaluates the ability of your computers memory to store and retrieve data. A correctly functioning computer should be able to do both these tasks with 100% accuracy day in and day out. A computer that fails these tests, perhaps because of old hardware, damaged hardware, or poorly configured hardware, will be less stable and crash more often. By running MemTest, you can ensure that your computers RAM is correctly functioning. Unlike other memory checking software, MemTest is designed to find all types of memory errors including intermittent problems. Therefore, it needs to be run for several hours to truly evaluate your RAM. MemTest works with any type of memory.

The original program, Memtest 86, was written by Chris Brady and the "+" version is its legacy by other members of the x86-secret team. Memtest86 (the original) worked great but wasn't updated very often to reflect changes in chipsets or processors. Memtest86+ is updated quite often (sometimes monthly) and generally supports the latest hardware.


Some other things that you should keep on your mind!

Memory can break. Faulty memory can sometimes cause only certain programs to crash. Sometimes faulty memory can prevent the computer from booting. Memory errors, not prevalent during default settings, can sometimes inhibit overclocking ability.

Memory can be brand new and be faulty. It also can function normally for a period of time then, unpredictably, fail or exhibit errors.


First things first

Memtest86+ does not run in Windows. It uses a tiny version of Linux as its OS, just enough to run the program and generate a display a simple GUI. It is a small program and can easily extract to a floppy disk or can be run from a bootable USB key or CD.


How to create a bootable disk/floppy

Even though its possible to boot it off the USB its not recommended since it's way more complicated. Generally most people have either CD or Floppy drive which is much easier to use.

First thing you should get is the Boot Disk Maker
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You'll see the latest version of the boot disk maker at the top of the list. At the memtest page you will see few choices and they can look confusing. The ones that you will need are following:

To create a bootable CD then choose the Pre-Compiled Bootable ISO (.zip)!

To create a bootable floppy then choose the Pre-Compiled package for Floppy (DOS - Win)!


Making the floppy

Unzip the file and run the "runme.bat" file. It will run a batch program that prompts for a blank disk. Insert a blank disk and it will make a bootable floppy with Memtest on it. All you need to do is boot off of that floppy and memtest will start to run. :thup:


Making the CD

There's an ISO file inside of the downloaded zip file. You can use many popular CD burning packages such as Nero or Roxio to burn the ISO to a blank CD-R. Remember that you need to burn this iso file as a disk image. DON'T write the ISO file onto a blank CD as that will do nothing. You need to consult your particular CD burning program's documentation to learn how to burn a CD image on to a disk. Basically, the ISO is a "package" of what the CD looks like compressed into a file for easy transport. It contains the boot sector and the directory tree of the disk, so you can understand why it needs to be "extracted" and written to the disk.

In NERO an image file can be burnt by choosing BURN IMAGE in the RECORDER menu.





Once the floppy is created or the ISO image burned then the computer can boot off the CD or floppy and memtest will automatically start to run.


When the memtest starts basically let it run and your main goal is to get pass (usually around 10 but more is better for ultimate stability).



By request: It is recommended that you run all of the tests in the sequence since they each do/test different things:

Test 0 [Address test, walking ones, no cache]

Tests all address bits in all memory banks by using a walking ones address pattern.

Test 1 [Address test, own address]

Each address is written with its own address and then is checked for consistency. In theory previous tests should have caught any memory addressing problems. This test should catch any addressing errors that somehow were not previously detected.

Test 2 [Moving inversions, ones&zeros]

This test uses the moving inversions algorithm with patterns of all ones and zeros. Cache is enabled even though it interferes to some degree with the test algorithm. With cache enabled this test does not take long and should quickly find all "hard" errors and some more subtle errors. This test is only a quick check.

Test 3 [Moving inversions, 8 bit pat]

This is the same as test one but uses a 8 bit wide pattern of "walking" ones and zeros. This test will better detect subtle errors in "wide" memory chips. A total of 20 data patterns are used.

Test 4 [Moving inversions, random pattern]

Test 4 uses the same algorithm as test 1 but the data pattern is a random number and it's complement. This test is particularly effective in finding difficult to detect data sensitive errors. A total of 60 patterns are used. The random number sequence is different with each pass so multiple passes increase effectiveness.

Test 5 [Block move, 64 moves]

This test stresses memory by using block move (movsl) instructions and is based on Robert Redelmeier's burnBX test. Memory is initialized with shifting patterns that are inverted every 8 bytes. Then 4mb blocks of memory are moved around using the movsl instruction. After the moves are completed the data patterns are checked. Because the data is checked only after the memory moves are completed it is not possible to know where the error occurred. The addresses reported are only for where the bad pattern was found. Since the moves are constrained to a 8mb segment of memory the failing address will always be less than 8mb away from the reported address. Errors from this test are not used to calculate BadRAM patterns.

Test 6 [Moving inversions, 32 bit pat]

This is a variation of the moving inversions algorithm that shifts the data pattern left one bit for each successive address. The starting bit position is shifted left for each pass. To use all possible data patterns 32 passes are required. This test is quite effective at detecting data sensitive errors but the execution time is long.

Test 7 [Random number sequence]

This test writes a series of random numbers into memory. By resetting the seed for the random number the same sequence of number can be created for a reference. The initial pattern is checked and then complemented and checked again on the next pass. However, unlike the moving inversions test writing and checking can only be done in the forward direction.

Test 8 [Modulo 20, ones&zeros]

Using the Modulo-X algorithm should uncover errors that are not detected by moving inversions due to cache and buffering interference with the the algorithm. As with test one only ones and zeros are used for data patterns.

Test 9 [Bit fade test, 90 min, 2 patterns]

The bit fade test initializes all of memory with a pattern and then sleeps for 90 minutes. Then memory is examined to see if any memory bits have changed. All ones and all zero patterns are used. This test takes 3 hours to complete. The Bit Fade test is not included in the normal test sequence and must be run manually via the runtime configuration menu.


Bellow I will give you the key sequence for selecting the test:

1. First press C

2. then 1

3. then 3

4. and finally select the test that you want to run

5. press Enter

6. and then 0 to get it running

g0dM@n said:
The newer versions are:
Push C + Push 1 + Push 3 + Push Test#

Older versions (which Eva showed shortcuts for) are:
Push C + Push 2 + Push 5 + Push Test#

1, 3, test# doesn't work on the older memtests. I noticed this when I got my DFI NF4 the first time. I tried C, 2, 5, 5 for test#5 and it wasn't working out until I noticed that it was set up differently.


What to do if Memtest 86+ says there are errors?

If you have errors then there are a couple of things to check first.

First, if you have multiple sticks of ram, test each one at a time by physically pulling all RAM except for the module you wish to check. Test each good ram module in every slot to confirm if you have a faulty module or a faulty DIMM slot. Yes...DIMM slots can fail too.

If the memory is under warranty then it can be RMA'd to the supplier or manufacturer. It's a good idea to note any of the Memtest results in the RMA form.

If you are overclocking then too high FSB settings can generate memory errors as can under-volting RAM. Try backing down your OC or bumping the voltage to your RAM to see if that clears up the error.

Another thing that could help is fine tunning the timings but that depends on the chips used on your RAM. The most usual suspects is the RAS to CAS and CAS Latency. Increasing these will give you better stability but it will degrade your performance so you need to keep that in mind. Increasing Vdimm helps also but this differentiates from chip to chip since some can take higher voltages then the others. In this case make sure that you have your RAM active cooled to prevent it from overheating which in most cases causes the errors in first place. Cooler the RAM better the stability and performance as well.

Please be aware that not all errors reported by Memtest86 are due to bad memory. The test implicitly tests the CPU, L1 and L2 caches as well as the motherboard. It is impossible for the test to determine what causes the failure to occur. However, most failures will be due to a problem with memory module. When it is not, the only option is to replace parts until the failure is corrected.

Once a memory error has been detected, determining the failing SIMM/DIMM module is not a clear cut procedure. With the large number of motherboard vendors and possible combinations of memory slots it would be difficult if not impossible to assemble complete information about how a particular error would map to a failing memory module. However, there are steps that may be taken to determine the failing module. Here are four techniques that you may wish to use:

1) Removing modules
This is simplest method for isolating a failing modules, but may only be employed when one or more modules can be removed from the system. By selectively removing modules from the system and then running the test you will be able to find the bad modules. Be sure to note exactly which modules are in the system when the test passes and when the test fails.

2) Rotating modules
When none of the modules can be removed then you may wish to rotate modules to find the failing one. This technique can only be used if there are three or more modules in the system. Change the location of two modules at a time. For example put the module from slot 1 into slot 2 and put the module from slot 2 in slot 1. Run the test and if either the failing bit or address changes then you know that the failing module is one of the ones just moved. By using several combinations of module movement you should be able to determine which module is failing.

3) Replacing modules
If you are unable to use either of the previous techniques then you are left to selective replacement of modules to find the failure.

4) Avoiding allocation
The printing mode for BadRAM patterns is intended to construct boot time parameters for a Linux kernel that is compiled with BadRAM support. This work-around makes it possible for Linux to reliably run with defective RAM. For more information on BadRAM support for Linux, sail to http://home.zonnet.nl/vanrein/badram

Sometimes memory errors show up due to component incompatibility. A memory module may work fine in one system and not in another. This is not uncommon and is a source of confusion. In these situations the components are not necessarily bad but have marginal conditions that when combined with other components will cause errors.

There have been numerous reports of errors with only tests 5 and 8 on Athlon systems. Often the memory works in a different system or the vendor insists that it is good. In these cases the memory is not necessarily bad but is not able to operate reliably at Athlon speeds. Sometimes more conservative memory timings on the motherboard will correct these errors. In other cases the only option is to replace the memory with better quality, higher speed memory. Don't buy cheap memory and expect it to work with an Athlon! On occasion test 5/8 errors will occur even with name brand memory and a quality motherboard. These errors are legitimate and should be corrected.

In the vast majority of cases errors reported by the test are valid. There are some systems that cause Memtest86 to be confused about the size of memory and it will try to test non-existent memory. This will cause a large number of consecutive addresses to be reported as bad and generally there will be many bits in error. If you have a relatively small number of failing addresses and only one or two bits in error you can be certain that the errors are valid. Also intermittent errors are without exception valid. Frequently memory vendors question if Memtest86 supports their particular memory type or a chipset. Memtest86 is designed to work with all memory types and all chipsets. Only support for ECC requires knowledge of the chipset.

All valid memory errors should be corrected. It is possible that a particular error will never show up in normal operation. However, operating with marginal memory is risky and can result in data loss and even disk corruption. Even if there is no overt indication of problems you cannot assume that your system is unaffected. Sometimes intermittent errors can cause problems that do not show up for a long time. You can be sure that Murphy will get you if you know about a memory error and ignore it.

Memtest86 can not diagnose many types of PC failures. For example a faulty CPU that causes Windows to crash will most likely just cause Memtest86 to crash in the same way.

eva2000 said:
memtest ain't 100% but you can use memtest to guage the max possible FSB/MEM which is the top limit of what you can expect... since i don't think i've ever experienced windows 100% stability and error free at a speed higher than the highest memtest passable speed

therefore

max FSB/MEM speed (100% windows error free/stability) <= max FSB/MEM speed (memtest error free)

test #1 - 4
are cpu fsb speed and or vcore related (meaning lowering fsb or increasing vcore saw errors in these tests disappear)

test #5
prior to 865/875 boards - memory speed, timings and vdimm related (meaning altering mem speed, timings and/or vdimm saw errors in this test disappear)

test#6
with 865/875 boards bigtoe has said related to cycle time (tras) in cpuz which i sort of confirmed with my current testing

note: prior to 865/875 boards, i've never had memory errors in test #6 only since these new boards have i experienced test #6 errors

test #7
not sure very rarely have i experienced errors

extended test
test #8 is a more intensive version of test #5

most memory related errors pop up at test #5 hence i like looping test #5 for memory testing for 12-24hrs after 1-4hr general standard loop of test #1-7

i like to loop test #3 and/or #4 for cpu related issues

I follow it up with at least goldmem 5.07:

2 quick test loops
+
2-4 full standard loops <-- can take forever trying doing it with 4 x 512mb xms3200c2

to loop a particular test

n memtest hit keyboard key

C -> 2 -> 5 and then select a test number to loop

spacebar = locks screen so it shows the very first error so where ram first errors out

enter key = unlocks screen

this is done, before i even load windows... if theres errors in above stage memtest or goldmem stages, i don't even bother loading windows or benching

i realise not everyone has time to do this but i like to know exactly what i get (ram) and how it performs

some people just load windows and see if it crashes or is stable... but you can't see why it crashes or isn't stable - is it the memory or cpu related etc

it makes it easier to test when you have more than 1 pc and a kvm switch to control 2-4 pcs from the same console


Memtest CHANGE LOG

Enhancements in v3.2 (11/Nov/2004)

* Added two new, highly effective tests that use random number patterns (tests 4 and 6)
* Reworked the online commands:
o Changed wording for better clarity
o Dropped Cache Mode menu
* Updated CPU detection for newer AMD, Intel and Cyrix CPUs
* Reworked test sequence:
o Dropped ineffective non cached tests (Numbers 7-11)
o Changed cache mode to "cached" for test 2
o Fixed a bug that did not allow some tests to be skipped
o Added bailout for Bit fade test
* Error reports are highlighted in red to provide a more vivid error indication
* Added support for a large number of additional chipsets (from Memtest86+ v1.30)
* Added an advanced setup feature that with new chiset allows memory timings to be altered from inside Memtest86. (from Memtest86+ v1.30)
* Misc bugfixes and code cleanup.

Enhancements in v3.1a (11/Mar/2004)

* Added processor detection for newer AMD processors
* Added new "Bit Fade" extended test
* Fixed a compile time bug with gcc version 3.x.
* E7500 memory controller ECC support
* Added support for 16bit ECC syndromes
* Option to keep the serial port baud rate of the boot loader

Enhancements in v3.0 (22/May/2002) - Provided by Eric Biederman

* Testing of more than 2gb of memory is at last fixed (tested with 6Gb)
* The infrastructure is to poll ecc error reporting chipset regisets, and the support has been done for some chipsets.
* Uses dynamic relocation information records to make itself PIC instead of requiring 2 copies of memtest86 in the binary.
* The serial console code does not do redundant writes to the serial port. Very little slow down at 9600 baud.
* You can press ^l or just l to get a screen refresh, when you are connecting and unconnecting a serial cable.
* Netbooting is working again
* LinuxBIOS support (To get the memory size)
* Many bugfixes and code cleanup

Enhancements in v2.9 (29/Feb/2002)

* The memory sizing code has been completely rewritten. By default Memtest86 gets a memory map from the BIOS that is now used to find available memory. A new online configuration option provides three choices for how memory will be sized, including the old "probe" method. The default mode generally will not test all of memory, but should be more stable. See the Memory Sizing section for details.
* Testing of more than 2gb of memory should now work. A number of bugs were found and corrected that prevented testing above 2gb. Testing with more than 2gb has been limited and there could be problems with a full 4gb of memory.
* Memory is divided into segments for testing. This allow for frequent progress updates and responsiveness to interactive commands. The memory segment size has been increased from 8 to 32mb. This should improve testing effectivness but progress reports will be less frequent.
* Minor bug fixes

Enhancements in v2.8 (18/Oct/2001)

* Eric Biederman reworked the build process making it far simpler and also to produce a network bootable ELF image.
* Re-wrote the memory and cache speed detection code. Previously the reported numbers were inaccurate for intel CPU's and completely wrong for the Athlon and Duron.
* Disabled the serial console by default since it was slowing down testing.
* Added CPU detection for Pentium 4
* Minor bug fixes

Enhancements in v2.7 (12/Jul/2001)

* Expanded workaround for errors caused by BIOS USB keyboard support to include test #5.
* Re-worked L1 / L2 cache detection code to provide clearer reporting.
* Fixed an obvious bug in the computation of cache and memory speeds.
* Added a menu option to disable the serial console.
* Changed on-line menu to stay in the menu between option selections.
* Fixed bugs in the test restart and redraw code.
* Adjusted code size to fix compilation problems with RedHat 7.1.
* Misc updates to the documentation.

Enhancements in v2.6 (25/May/2001)

* Added workaround for errors caused by BIOS USB keyboard support.
* Fixed problems with reporting of 1 GHZ + processor speeds.
* Fixed Duron cache detection.
* Added screen buffer so that menus will work correctly from a serial console.
* The Memtest86 image is now built in ELF format.

Enhancements in v2.5 (13/Dec/00)

* Enhanced CPU and cache detection to correctly identify Duron CPU and K6-III 1mb cache.
* Added code to report cache-able memory size.
* Added limited support for parity memory.
* Support was added to allow use of on-line commands from a serial port.
* Dropped option for changing refresh rates. This was not useful and did not work on newer motherboards.
* Improved fatal exception reporting to include a register and stack dump.
* The pass number is now displayed in the error report.
* Fixed a bug that crashed the test when selecting one of the extended tests.

Enhancements in v2.4

* The error report format was reworked for better clarity and now includes a decimal address in megabytes.
* A new memory move test was added (from Robert Redelmeier's CPU-Burn)
* The test sequence and iterations were modified.
* Fixed scrolling problems with the BadRAM patterns.
* Updated and improved CPU and cache detection.

Enhancements in v2.3

* Measurement and reporting of memory and cache performance was added.
* All of the test routines were rewritten in assembler to improve both error detection and speed.
* A progress meter was added to show pass and test completion.
* The screen layout was reworked to hopefully be more readable.
* Support for creating BadRAM patterns was added.
* An error summary option was added to the online commands.

Enhancements in v2.2

* Added two new address tests.
* Added an on-line command for setting test address range.
* Optimized test code for faster execution (-O3, -funroll-loops and -fomit-frame-pointer).
* Added and elapsed time counter.
* Adjusted menu options for better consistency.

Enhancements in v2.1

* Fixed a bug in the CPU detection that caused the test to hang or crash with some 486 and Cryrix CPU's
* Added CPU detection for Cyrix CPU's
* Extended and improved CPU detection for Intel and AMD CPU's
* Added a compile time option (BIOS_MEMSZ) for obtaining the last memory address from the BIOS. This should fix problems with memory sizing on certain motherboards. This option is not enabled by default. It may be enabled by default in a future release.

Enhancements in v2.0

* Added new Modulo-20 test algorithm.
* Added a 32 bit shifting pattern to the moving inversions algorithm.
* Created test sections to specify algorithm, pattern, cache and refresh rate.
* Improved test progress indicators.
* Created popup menus for configuration.
* Added menu for test selection.
* Added CPU and cache identification.
* Added a "bail out" feature to quit the current test when it does not fit the test selection parameters.
* Re-arranged the screen layout and colors.
* Created local include files for I/O and serial interface definitions rather than using the sometimes incompatible system include files.
* Broke up the "C" source code into four separate source modules.

Enhancements in v1.5

* Some additional changes were made to fix obscure memory sizing problems.
* The 4 bit wide data pattern was increased to 8 bits since 8 bit wide memory chips are becoming more common.
* A new test algorithm was added to improve detection of data pattern sensitive errors.

Enhancements in v1.4

* Changes to the memory sizing code to avoid problems with some motherboards where Memtest86 would find more memory than actually exists.
* Added support for a console serial port. (thanks to Doug Sisk)
* On-line commands are now available for configuring Memtest86 on the fly (see On-line Commands).

Enhancements in v1.3

* Scrolling of memory errors is now provided. Previously, only one screen of error information was displayed.
* Memtest86 can now be booted from any disk via lilo.
* Detection of up to 4gb of memory has been fixed is now enabled by default. This capability was clearly broken in v1.2a and should work correctly now but has not been fully tested (4gb PC's are a bit rare).
* The maximum memory size supported by the motherboard is now being calculated correctly. In previous versions there were cases where not all of memory would be tested and the maximum memory size supported was incorrect.
* For some types of failures the good and bad values were reported to be same with an Xor value of 0. This has been fixed by retaining the data read from memory and not re-reading the bad data in the error reporting routine.
* APM (advanced power management) is now disabled by Memtest86. This keeps the screen from blanking while the test is running.
* Problems with enabling & disabling cache on some motherboards have been corrected.



That's about it and feel free to add anything that I may have left out!
 
Last edited:
looks like you made this post sticky-ready, so I will go ahead and bump it for you to be made one. Although, as we have all discussed, being memtest stable doesn't mean that it will be in windows, but if you can't even get through memtest runs then you almost have no prayer in windows :D
 
Care to put in some more information about tests 5 and 6, and why they're "the most reliable"?

Also, maybe demonstrate the ability to change timings from within Memtest86+...

Most reliable test is the #5. Since by default memtest will run #2 you will need to set it to run #5 manually. Bellow I will give you the key sequence for selecting the test:
It should run 1-8 in a loop by default. Running the entire sequence of tests over and over is a good way to test for stability if you're going to be testing for a couple of hours.
 
johan851 said:
Care to put in some more information about tests 5 and 6, and why they're "the most reliable"?

Also, maybe demonstrate the ability to change timings from within Memtest86+...


It should run 1-8 in a loop by default. Running the entire sequence of tests over and over is a good way to test for stability if you're going to be testing for a couple of hours.

Well I just noticed over time that those are the ones that people use most of the time as for myself I do nothing but #5 when playing with timings. Over time I found that I can get 24hour pass on most of them but like Janus said its not Windows stable. For system stability I seek elsewhere like PI and Prime95, but memtest is a good indicator.

Also I'm still using older version of the memtest and by default it runs #2, but thanx for the correction.

Another thing that I want to point out (thanx to Son) is that DFI NF4 BIOS come equiped with memtest so you don't need to wory about backing it up. However not all BIOS contain it only the 3/10 and up.

P.S. I'll make sure to make the correction on that as it was requested by others, but thanks for pointing it out.
 
Mate,

I was looking for information on how one could interpret the errors with certainity, but I couldn't find anything specific. From my experience, setting incorrect drive strength and tREF timings throws up test 2 & 3 errors first. I remember reading about crap PSU's throwing up the same errors, but I have no way to test that hypothesis. Maybe you could use the following format to clear things up once and for all:

Test # :

Typical number of Errors :

Wall time of 30 min <quick test>
Overnight run < one complete thermal cycle>


Diagnosis:

You could ask people to run memtest to generate real-time data, instead of relying on second hand material.

Keep up the good work. I'm sure you will get more specific suggestions.

S-N
 
Super Nade said:
Mate,

I was looking for information on how one could interpret the errors with certainity, but I couldn't find anything specific. From my experience, setting incorrect drive strength and tREF timings throws up test 2 & 3 errors first. I remember reading about crap PSU's throwing up the same errors, but I have no way to test that hypothesis. Maybe you could use the following format to clear things up once and for all:

Test # :

Typical number of Errors :

Wall time of 30 min <quick test>
Overnight run < one complete thermal cycle>


Diagnosis:

You could ask people to run memtest to generate real-time data, instead of relying on second hand material.

Keep up the good work. I'm sure you will get more specific suggestions.

S-N

Test def added :thup:

And yes drive strenght especially makes big difference in the memtest, thanx for pointing it out. I tried that experiminet before with my TCC5's and setting it to anything bellow/above 7 will throw errors all over the place regardless of other timings.

Currently I'm using Mushkin 2GB kit with CE-6's and it wouldn't be much of a use if I was test it myself, but like you said I'm sure that someone else will clarify this soon enough.
 
Last edited:
VERY concise guide, RedDragon!

I've got it bookmarked for future reference for noobs!
 
Good Post RedDragon :thup:
I saw you hit on the bit about Chris Brady and the original memtest. You might want to add what the different types of memtest are, i.e. MemTest, Memtest86, Memtest86+, Memtest|OSX, and provide a link to the actual Memtest86+. The link you provide is called 'Boot Disk Maker' and that could be confusing. The only reason I say this is because if you google memtest you get many different versions from many different places and authors.
 
Back