MemTest86 Technical Information

What's New in Version 5?

MemTest86 supports booting from both the newer UEFI platform and the traditional BIOS. When booting from UEFI, MemTest86 has access to additional services not available in BIOS including:

  • Native 64-bit support
  • No longer requires the use of the PAE workaround to access more than 4GB of memory. (PAE = Physical Address Extension)
  • Mouse support, where supported by the underlying UEFI system. On older systems a keyboard is still required.
  • Improved USB keyboard support. The keyboard now works on systems that fail to emulate IO Port 64/60 correctly. So Mac USB keyboards are now supported.
  • Improved multi-threading support, where supported by the underlying UEFI system.
  • Reporting of detailed RAM SPD information. Timings, clock speeds, vendor names and much more.
  • Support to writing to the USB drive that MemTest86 is running from for logging and report generation. In all prior MemTest86 releases, there was no disk support.
  • Use of GPT. (GUID Partition Table)
  • ECC RAM support (limited hardware support, ongoing development)
    • Detection of ECC support in both the RAM and memory controller
    • Polling for ECC errors
    • Injection of ECC errors for test purposes. (limited hardware only)
  • Attempted preliminary DDR4 support. But as of Dec 2013 we are having problems sourcing DDR4 RAM to test with, so it probalby won't work. We'll be revisting this in V6.
  • Option to disable CPU caching for all tests
  • Having a configuration file to allow settings to be pre-defined without the need for keyboard input. This can help with automation.
  • Support for Secure Boot.
  • Speed improvements of between 10% and 30%+. Especially for tests, #5, #8 & #9. This is the result more moving to native 64bit code, removing the PAE paging hack, switching compilers and using faster random number generation algorithms.
  • Addition of 2 new memory tests to take advantage of 64bit data and SIMD instructions.
  • See the What's New page for a complete list of changes.

See the feature comparison page for a summary of the differences between the various editions of MemTest86.

If UEFI is not supported on the system, the older v4 BIOS version is booted. MemTest86 can boot from a CD, USB flash drive or, with Linux systems, by the boot loader (for example, LILO or Grub). Any Windows, Linux or Mac system may be used to create the CD or USB flash drive. Once a MemTest86 boot disk has been created, it may be used on any x86 (PC/Mac) computer.

Back to top

Creating a MemTest86 boot disk in Windows

To create a MemTest86 bootable USB, CD or floppy in Windows, it is recommended that you download one of the Windows MemTest86 images.

Note: There is no difference in the resulting MemTest86 boot disk created using either the Windows or Linux/Mac images; the difference is merely that the images are packaged in a way that it is more suited for the respective operating system (eg. zip vs tarball).

Create a bootable CD-ROM:

  1. Download the Windows MemTest86 ISO image.
  2. Right click on the downloaded file and select the "Extract to Here” option. This places the CD-ROM ISO image into the current folder.
  3. Use the CD burning software available on your system to create a CD-ROM using the extracted ISO image. Be sure that you create a CD image from the ISO file rather than placing a copy of the ISO file onto a data CD. Look for “Burn Image from File” or similar option under the File menu of your CD burning software.

Create a bootable USB Flash drive:

  1. Download the Windows MemTest86 USB image.
  2. Right click on the downloaded file and select the "Extract to Here” option. This places the USB image and imaging tool into the current folder.
  3. Run the included imageUSB tool, it should already have the image file selected and you just need to choose which connected USB drive to turn into a bootable drive. Note that this will erase all data on the drive.

Create a bootable floppy (v4 only):

  1. Download the Windows MemTest86 floppy disk image.
  2. Right click on the downloaded file and select the "Extract to Here” option. This places the floppy disk image into the current folder.
  3. Creating a bootable floppy disk requires use of a third party program to write the floppy disk image to a disk. A number of programs are available to write the disk image. Rawwrite is a recommended free program available at: A more robust solution is WinImage, available at
Back to top

Creating a MemTest86 boot disk in Linux/Mac

To create a MemTest86 bootable USB, CD or floppy in Linux/Mac, it is recommended that you download one of the Linux/Mac pre-compiled MemTest86 images. Advanced users may wish to build from source and optionally make source code changes.

Note: There is no difference in the resulting MemTest86 boot disk created using either the Windows or Linux/Mac images; the difference is merely that the images are packaged in a way that it is more suited for the respective operating system (eg. zip vs tarball).

Create a bootable CD-ROM:

  1. Download the Linux/Mac MemTest86 ISO image.
  2. UN-tar the package (tar xvzf MemTest86-*-iso.tar.gz). An ISO image file and a README file will be created in the current directory.
  3. Use the CD burning software available on your system to create a CD-ROM using the uncompressed ISO image. Be sure that you create a CD image from the ISO file rather than placing a copy of the ISO file onto a data CD. Look for “Burn Image from File” or similar option under the File menu of your CD burning software. On a Mac, you can use 'Disk Utility'. See this forum post for details.

Create a bootable USB Flash drive:

  1. Download the Linux/Mac MemTest86 USB image.
  2. UN-tar the package (tar xvzf MemTest86-*-usb.tar.gz). An image file and a README file will be created in the current directory.
  3. Follow instructions in the README to write the USB flash disk.

Create a bootable floppy (v4 only):

  1. Download the Linux floppy disk image.
  2. UN-tar the package (tar xvzf MemTest86-*-floppy.tar.gz). An image file and a README file will be created in the current directory.
  3. Follow instructions in the README to write the floppy disk.
Back to top


Booting MemTest86

MemTest86 supports booting from both UEFI and BIOS systems. Most newer systems are able to run the UEFI version of MemTest86, but all systems should be able to boot the traditional BIOS version.

To start MemTest86 insert the CD-ROM or USB flash drive into the appropriate drive and restart your computer. Note: If running on a UEFI system, the UEFI BIOS must be configured to boot from the device that MemTest86 is installed on. Most systems have an optional boot menu that is enabled be pressing a key at startup (often ESC, F9, F11 or F12) similar to the following:


If available use the boot menu to select the correct drive. You may see both the UEFI and BIOS as separate options. Please consult your motherboard documentation for details.

On a Mac, you need to hold down the 'c' key while the computer is booting to boot from CD. To boot from USB, you need to hold down the ALT / Option key on the Mac keyboard while powering on the machine.

Using a Serial Console

For systems without video support, MemTest86 can run in serial console mode from both UEFI and BIOS systems. For MemTest86 v4, select option 5 from the menu to enable output to serial console. You will not need to do anything for MemTest86 v5 or later as it will automatically use the serial console, provided that the UEFI BIOS has been configured to redirect the console to the serial port. No GUI support is available when using the serial console so all test configurations must be done using the configuration file.

Back to top

Configuring MemTest86

When MemTest86 boots, a splashscreen is displayed with a 10 second countdown timer which when expires, automatically starts the memory tests with default settings. Pressing a key or moving the mouse shall stop the timer. To configure the memory tests, select 'Config' and the main menu is displayed. The main menu allows the user to customize the memory test settings such as the specific tests to execute, address range to test and which CPU(s) are used in testing.

MemTest86 Main Menu

The Main Menu is structured as follows:

  • System Info - displays the hardware details of the system
  • Test Selection - specifies which tests to enable, and how many passes to run
  • Address Range - specifies the lower and upper address memory limits to test
  • CPU Selection - select between Single, Parallel, Round Robin and Sequential modes
  • Start - start executing the memory tests
  • Exit - exits MemTest86 and reboots the system

(Pro version only) Memory test parameters can also be set via a configuration file (mt86.cfg) that is loaded on startup, without the need to manually configure the memory tests every time MemTest86 is run. This is useful especially in testing environments where memory tests need to be executed in an automated fashion without user intervention. The mt86.cfg config file need to be placed into the EFI\BOOT folder on the USB drive. The following is an example of a MemTest86 configuration file:


See this forum post for additional details about MemTest86 configuration files.

Back to top

Test Results

At the end of the test, a summary of the test results is displayed, as shown in the following screenshot:

MemTest86 Test Summary

  Error Confidence Value:
     A value that indicates the validity of the errors being reported with
     larger values indicating greater validity. There is a high probability
     that all errors reported are valid regardless of this value.  However,
     when this value exceeds 100 it is nearly impossible that the reported
     errors will be invalid.

  Lowest Error Address:
     The lowest address that where an error has been reported.

  Highest Error Address:
     The highest address that where an error has been reported.

  Bits in Error Mask:
     A mask of all bits that have been in error (hexadecimal).

  Bits in Error:
     Total bit in error for all error instances and the min, max and average
     bit in error of each individual occurrence.

  Max Contiguous Errors:
     The maximum of contiguous addresses with errors.

  ECC Correctable Errors:
     The number of errors that have been corrected by ECC hardware.

  Test  Errors:
     On the right hand side of the screen the number of errors for each test
     are displayed.

The user may also save the results as an HTML test report to a file. The test report appearance is fully customizable in the pro version. Here is an example of an HTML test report

Back to top

Troubleshooting Memory Errors

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

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.

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 full speed. 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 reliably. On occasion "block move" test errors will occur even with name brand memory and a quality motherboard. These errors are legitimate and should be corrected.

We are often asked about the reliability of errors reported by Mestest86. 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.

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 cannot 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.

Back to top

Execution Time

The time required for a complete pass of MemTest86 will vary greatly depending on CPU speed, memory speed and memory size. The pass counter increments after all of the selected tests have been run. Generally a single pass is sufficient to catch all but the most obscure errors. However, for complete confidence when intermittent errors are suspected testing for a longer period is advised.

Back to top

Detailed Descriptions

Memory Testing Philosophy

There are many good approaches for testing memory. However, many tests simply throw some patterns at memory without much thought or knowledge of memory architecture or how errors can best be detected. This works fine for hard memory failures but does little to find intermittent errors. BIOS based memory tests are useless for finding intermittent memory errors.

Memory chips consist of a large array of tightly packed memory cells, one for each bit of data. The vast majority of the intermittent failures are a result of interaction between these memory cells. Often writing a memory cell can cause one of the adjacent cells to be written with the same data. An effective memory test attempts to test for this condition. Therefore, an ideal strategy for testing memory would be the following:

  1. write a cell with a zero
  2. write all of the adjacent cells with a one, one or more times
  3. check that the first cell still has a zero

It should be obvious that this strategy requires an exact knowledge of how the memory cells are laid out on the chip. In addition there is a never ending number of possible chip layouts for different chip types and manufacturers making this strategy impractical. However, there are testing algorithms that can approximate this ideal.

Back to top

MemTest86 Test Algorithms

MemTest86 uses two algorithms that provide a reasonable approximation of the ideal test strategy above. The first of these strategies is called moving inversions. The moving inversion test works as follows:

  1. Fill memory with a pattern
  2. Starting at the lowest address
    • check that the pattern has not changed
    • write the patterns complement
    • increment the address
    • repeat
  3. Starting at the highest address
    • check that the pattern has not changed
    • write the patterns complement
    • decrement the address
    • repeat

This algorithm is a good approximation of an ideal memory test but there are some limitations. Most high density chips today store data 4 to 16 bits wide. With chips that are more than one bit wide it is impossible to selectively read or write just one bit. This means that we cannot guarantee that all adjacent cells have been tested for interaction. In this case the best we can do is to use some patterns to insure that all adjacent cells have at least been written with all possible one and zero combinations.

It can also be seen that caching, buffering and out of order execution will interfere with the moving inversions algorithm and make less effective. It is possible to turn off cache but the memory buffering in new high performance chips can not be disabled. To address this limitation a new algorithm I call Modulo-X was created. This algorithm is not affected by cache or buffering. The algorithm works as follows:

  1. For starting offsets of 0 - 20 do
    • write every 20th location with a pattern
    • write all other locations with the patterns complement
    • repeat above one or more times
    • check every 20th location for the pattern

This algorithm accomplishes nearly the same level of adjacency testing as moving inversions but is not affected by caching or buffering. Since separate write passes (1a, 1b) and the read pass (1c) are done for all of memory we can be assured that all of the buffers and cache have been flushed between passes. The selection of 20 as the stride size was somewhat arbitrary. Larger strides may be more effective but would take longer to execute. The choice of 20 seemed to be a reasonable compromise between speed and thoroughness.

Back to top

Individual Test Descriptions

MemTest86 executes a series of numbered test sections to check for errors. These test sections consist of a combination of test algorithm, data pattern and cache setting. The execution order for these tests were arranged so that errors will be detected as rapidly as possible. A description of each of the test sections follows:

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, Sequential]

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. This test is done sequentially with each available CPU.

Test 2 [Address test, own address, Parallel]

Same as test 1 but the testing is done in parallel using all CPUs and using overlapping addresses.

Test 3 [Moving inversions, ones&zeros, Parallel]

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 is done in parallel using all CPUs.

Test 4 [Moving inversions, 8 bit pattern]

This is the same as test 3 but uses a 8 bit wide pattern of "walking" ones and zeros. This test will better detect subtle errors in "wide" memory chips.

Test 5 [Moving inversions, random pattern]

Test 5 uses the same algorithm as test 4 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. The random number sequence is different with each pass so multiple passes increase effectiveness.

Test 6 [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 7 [Moving inversions, 32 bit pattern]

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 8 [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 9 [Modulo 20, Random pattern]

Using the Modulo-X algorithm should uncover errors that are not detected by moving inversions due to cache and buffering interference with the algorithm.

Test 10 [Bit fade test, 2 patterns]

The bit fade test initializes all of memory with a pattern and then sleeps for a few minutes. Then memory is examined to see if any memory bits have changed. All ones and all zero patterns are used.

Test 11 [Random number sequence, 64-bit]

This test is the same as Test 8, but native 64-bit instructions are used.

Test 12 [Random number sequence, 128-bit]

This test is the same as Test 8, but native SIMD (128-bit) instructions are used.
Back to top

Recover disk space on a flash drive

We have had a few users wondering how to get back the space on a USB drive once they have finished using MemTest86. The problem stems from the fact that the Windows Disk Management function doesn't allow for wiping or re-partitioning of USB flash drives. You can find the steps needed to reformat a USB flash drive to full capacity here.

Back to top