Memory Testing and What a Pass Covers

The tool that tests memory has to take the machine away from the operating system first. Memtest86+ is a stand-alone memory tester, free and open source under the GNU GPL v2.0, built for IA-32, x86-64 and LoongArch64 systems. Stand-alone is the word doing the work: on x86 hardware the program loads either directly from a PC BIOS, legacy or UEFI, or through an intermediate bootloader that supports the Linux boot protocol. No operating system is resident, so the tool decides what gets written where.

That is the same logic that makes a diagnosis run from a live system instead of the installed one: the instrument should not depend on the patient. What follows is about this particular instrument, and about what a clean run of it does and does not put in a bench record.

What does a clean pass actually cover?

A run that finishes with no reported error states exactly this: the patterns the tool ran, on the modules installed, in that machine, at the speed and temperature it happened to be at, produced nothing the tool was built to detect, for the duration of that run. Every clause is a boundary. The project describes its check as more thorough than the memory test a BIOS performs, and that is a claim about pattern coverage, not a certificate for the hardware. For how many passes make a run sufficient, the page publishes no figure; it directs questions the FAQ does not answer to the full README.

The FAQ's own shape says where the real difficulty sits. Its sections cover why to test RAM at all, installation on removable media, booting issues, troubleshooting RAM errors, and a catch-all for the rest. Three of those five headings are about getting the tester to run. In practice that is where most memory tests end, before any pattern reaches a module, and the page structure quietly agrees.

Which machines does it load on?

The stated hardware range is broad and precisely worded: any Pentium-class or later 32-bit x86 CPU, any 64-bit x86 CPU, and the supported Loongson LA64 systems. Broad is not the same as frictionless. The boot path is where machines differ from one another, and the changelog of the release current at this writing, v8.10, published on the Memtest86+ site, reads like an inventory of those differences: fixes for AMI BIOS boot issues, for GRUB boot issues and for the SecureBoot path through shim, support for x2APIC and for Intel Panther Lake, corrected timings on LPDDR5, better bandwidth measurement, and LA64-specific work.

Read that list as maintenance rather than novelty. A tester whose releases still fix how it starts on current firmware is a tester being kept usable on machines as they ship, which is the property a diagnostic tool needs more than any feature.

Why two programs share one name

Memtest86+ is not an edition of Memtest86. The program without the plus has, since 2013, been closed-source freemium software owned by PassMark Software Pty Ltd, while the one with it stayed GPL. The pair descend from the same ancestor, and a search for either still returns both, which is how results get attributed to the wrong tool.

The GPL side of that line, as the project records it:

The v6 row explains the present. Martin Whitaker wrote that code base under the PCMemTest name, on top of the v5 that Sam Demeulemeester had carried since 2004, and the two now maintain Memtest86+ together. A tool with two active maintainers and a 1994 ancestor is a maintained tool with a paper trail, not a leftover.

A nightly build is not a release

Nightly builds are generated automatically, every night, from the latest code, and the project labels them without ceremony: pre-release, beta, fully untested, possibly containing issues. The label deserves more weight here than it would on a text editor. A memory tester that is itself unverified produces a run whose value as evidence is reduced by exactly that fact, and the project says so before offering the download.

There is one workflow where untested code is the point. The project asks for bug reports on its GitHub page, with hardware details and reproduction steps, after checking the issue is not already filed. Running a nightly to confirm a fault against current code before reporting it is what that label was made for.

Where the pass sits in a bench record

A clean run is one entry in a file, not the file. A module set that passes in a cold machine can still fault once the same machine is warm or loaded; the run covered the state the machine was in, and only that state. This is why a bench that records what a stress test proves, and that reads the sensors while the load runs, treats the memory pass as one instrument among several rather than as the verdict.

The note matters as much as the result. "Memory fine" is worth nothing a year later. A line recording which build ran, on which modules, for how many passes, in a machine in what state, can be set beside the next failure and compared.

The next machine that crashes twice in a week and then boots clean is the one to practice on. Put the current release on removable media, confirming the target device first because the write erases everything on it, note the conditions before it reboots, let the run finish, and file the result beside the load tests and the sensor logs rather than in place of them. The pass earns its place by being narrow, dated and comparable, not by being final.