Your machine reboots in the middle of a match. Or it hands you a memory management stop code every few days, or it falls apart the moment you switch on XMP in the firmware. Windows logs nothing you can use, and every troubleshooting thread ends with the same advice: test the RAM.
Testing RAM from inside the desktop is awkward. The operating system owns memory, moves it, caches it, and hands it out to drivers, so a utility running under Windows or Linux measures an address space the kernel keeps rearranging. That's the entire reason MemTest86 exists: it boots ahead of the operating system from a USB stick and writes patterns straight into physical memory, with no kernel in the middle. Most guides answer how to run MemTest86 and then stop at the boot screen.
The hard part isn't starting it. It's knowing when the run in front of you is finished, and what each outcome commits you to.
What Pass Fail and Incomplete Actually Mean
Before you download anything, learn the scoreboard. MemTest86 reports three labels, and two of them get misread constantly. The official result definitions are deliberately narrow: PASS requires every configured test to finish with zero detected errors. FAIL means at least one error was detected, or the run crossed the configured MAXERRCOUNT threshold at any point. INCOMPLETE PASS means at least one configured test never finished, even though no errors appeared in the portion that did run.
That third label catches people. You walk away, come back to a screen showing an error count of zero, and declare the RAM good. But the program never completed the sequence it was asked to run, so it can't vouch for the addresses the later tests would have covered. The documentation says it plainly: an incomplete pass doesn't carry the same meaning as a completed clean pass.
| Label | Official meaning | What to do with it |
| PASS | Every configured test finished with zero errors | Accept this hardware setup and duration as clean |
| FAIL | At least one error, or MAXERRCOUNT exceeded | Treat it as a stability failure and isolate hardware |
| INCOMPLETE PASS | At least one test didn't finish, and no errors were seen | Don't call it a pass; let the sequence complete |
| One pass | About 15 minutes in the 2026 execution-time examples | Short smoke check only |
| Four passes | About 120 minutes in the 2026 execution-time examples | Practical baseline before blaming software |
The clock decides whether a label means anything
The execution-time reference gives about 15 minutes for one pass and about 120 minutes for four passes. Larger kits, tighter timings, and the slower algorithms stretch that, so a four-DIMM 64 GB build is an evening, not a coffee break.
Reporting rule: if you stopped the run early, you don't have a pass. You have an unfinished test and a green screen for the rows that happened to complete.
Treat the machine as occupied while it runs. Mains power, not a laptop on battery, a cool room, and no gaming in another window or firmware flashing alongside it. Interrupting a run to check something throws away the time you'd already spent.
Cost isn't the reason people skip passes. The Free Edition of MemTest86 costs nothing to download and carries no usage restrictions, so a full run consumes only time and a wall socket. Budget four passes, write down how many you selected, and then build the USB.
How to Build the USB and Start the Test
MemTest86 runs before the operating system, so the USB stick must be bootable. The MemTest86 project page documents the six steps below.
- Download and extract the USB image package. It contains the bootable image and the writing utility. Extract the ZIP to your computer, not to the stick you plan to erase.
- Copy anything you want to keep off the flash drive. Writing the image wipes the drive, so treat this step like clearing a workbench before laying out new parts.
- Use a drive larger than 1 GB. That is the capacity requirement listed on the MemTest86 download page. A spare 8 GB stick is comfortably large enough.
- Write the image with ImageUSB. On Windows, open the bundled imageUSB.exe, select the target drive, leave the supplied MemTest86 image selected, then click Write. Linux and macOS can also prepare the image, but the bundled Windows writer is the documented default.
- Restart with the stick inserted and open the one-time boot menu. Common firmware keys include Esc, F9, F11, and F12, according to the MemTest86 booting guide. Choose the entry that starts with UEFI: and names the USB drive.
- On a Mac, hold Option or Alt while powering on. Select the USB drive in the startup manager.
The same six steps appear in the image:
Two choices often explain why the test does not start. Changing boot order inside the operating system cannot help: firmware chooses the boot device before the OS loader runs. Use the one-time boot menu to select the stick directly.
Choose the UEFI entry on a modern board. The current image expects UEFI; a BIOS-only machine needs the older legacy build. Selecting a legacy or CSM entry on a modern board can leave you at a black screen, even when the USB was written correctly.
MemTest86 began with Chris Brady and later split into a separate project, MemTest86+. They have separate downloads, so use the guide that matches the image you wrote.
After the test environment loads, MemTest86 starts testing automatically. It works through numbered sections that combine algorithms, data patterns, and cache settings. A zero-error display is only reassuring if the run has finished; if you stop it early, the result is incomplete.
Test Options Worth Changing Before You Walk Away
The first run has one job: to be comparable with the second run. Defaults suit most of the menu, but a handful of choices decide whether tonight's result still means something next week. The MemTest86 UEFI user guide treats these as prerequisites for a reproducible run.
Record the layout before you change it
Open the case or check the firmware screen and note which slots hold which modules: capacity, slot order, and anything printed on the label. Photograph it. When a failure narrows to one module later, that photo is the difference between a five-minute answer and an hour of guessing.
Turn the profile off for the first run
Disable XMP or EXPO and let the kit run at default JEDEC speed and timings. A machine that fails at JEDEC has a hardware problem. A machine that fails only with the profile enabled has a settings problem, and those two outcomes lead to completely different repairs. Blending them on the first run wastes the run.
Choose four passes and mean it
Four passes is the sensible desktop baseline, and a big kit turns that into an overnight session. Rare crashes justify going longer with a second session. What you shouldn't do is stop at the first zero and call it done, because interrupting a clean run leaves you holding an unfinished test, not a result.
Know what the numbered tests are hunting
Each numbered section applies a different strategy, because faults don't all look alike. Moving inversions is the clearest example: the program fills memory with a pattern, verifies those contents while writing the complementary pattern, then repeats the walk in both ascending and descending address order. That catches cells that read back correctly until a neighbor changes. Other sections vary offsets, patterns, cache behavior, and access direction for the same reason, and MemTest86's explanation of its test algorithms notes that different fault types surface only under particular data or addressing conditions.
The current build supports 14 RAM-testing algorithms, including row hammer detection, which is why a modern run covers ground that a decade-old tutorial never mentions.
Write down the pass count you actually selected. When the log gets read later, the plan and the report have to match.
Skip the rest of the menu on the first run. More knobs mean more difference between tonight's result and next week's.
How to Read a Fail and Isolate the Stick
A red screen during a memory test gives you a starting point, not a verdict on which part to replace. Record the error details, then change one thing at a time so you can tell whether the fault follows a module, a slot, or a memory setting. Even errors on name-brand memory in a quality motherboard count as real failures that should be corrected, according to the MemTest86 general information documentation.
Read the fields, not the color
The failing screen records the address, test pattern, CPU or core, and running error count. Copy those details before restarting. A completed run can save a log to the USB drive at EFI/BOOT/MemTest86.log and can produce an HTML report or optional JSON report, as described in the MemTest86 how-to. A photo of a scrolling screen may miss the test number or address.
Repeated errors at the same address suggest a consistent fault at that location. Scattered errors, or errors that appear only after the system has warmed up, can point to a broader issue such as cooling, power delivery, or tight memory timings. Use the pattern to guide the next check, not to identify a failed part on its own.
Run the isolation in a fixed order
Change one thing at a time. Otherwise, you cannot tell which change affected the result.
| Check | What you change | If the failure changes |
| JEDEC baseline | Disable XMP or EXPO and use default timings | The profile, voltage, timings, training, or memory controller may be involved |
| Single DIMM | Install one module at a time and retest each stick | If the error follows a module, that stick is suspect |
| Slot swap | Move the same DIMM to another slot | If the error follows the slot, check the slot or its contact |
| Firmware retest | Update to a stable BIOS or UEFI and repeat | Memory training or controller behavior may be involved |
Label each module with tape or a paint pen before removing it, then record the results in a table. Without labels, identical sticks are easy to mix up between tests.
Why the row hammer test exists
DRAM stores data in rows, and repeated access to nearby rows can disturb stored bits before the next refresh. MemTest86's second pass applies a repeated row-access pattern designed to stress cells that row hammer can disturb. This test looks for a specific kind of memory instability, rather than writing and checking random patterns.
Accept what a clean run does and doesn't prove
A finished, error-free run means no errors appeared with that configuration during that run. It does not rule out every CPU, motherboard, or platform fault, and a component problem can stop the diagnostic before it produces a report. A zero-error screen that you interrupt is still an incomplete test, not a clean result.
Fixes When MemTest86 Never Appears
You select the USB drive in the boot menu, but the computer starts Windows instead. MemTest86 has not tested the memory yet. A missing boot entry points to the USB media or firmware setup, not to a pass or a fail.
Work through the MemTest86 troubleshooting guidance from the simplest fix to the more disruptive ones:
- Recreate the USB drive with the official imaging utility. A drive written with a generic ISO tool may not boot on your firmware.
- Plug it into a rear motherboard USB port, preferably USB 2.0, rather than a front-panel hub or extension cable.
- Disable Fast Boot temporarily. Some firmware skips USB initialization when this option is enabled.
- Choose UEFI mode and the UEFI-named USB entry. If the computer has a legacy BIOS instead, use the legacy build.
- Change Secure Boot only if the earlier steps fail. Firmware may hide the USB entry when Secure Boot is enabled. Restore the setting after the test if you changed it.
A missing entry is a boot-path problem. A red screen after MemTest86 starts is a test result, so follow the fail-isolation steps rather than changing USB settings.
If the test starts but you have no saved report, retrieve the log and HTML report from the USB drive before reformatting it. A photo can help record what appeared on screen, but it cannot replace a saved report.
For a visual walkthrough of the boot process, this video shows the USB setup from start to finish.
If the USB entry remains missing, check the firmware's boot mode and Secure Boot settings before blaming the memory. Once MemTest86 opens, the boot problem is resolved; use the test result to decide what to investigate next.
Decide the Next Repair After the Run
Results turn into repairs. Each label has one useful next action.
- Completed PASS at JEDEC across four passes: clears the memory layout for that configuration and duration. If you need the XMP or EXPO profile, put it back and run one full pass again before calling it stable, because the JEDEC result doesn't transfer to a faster profile.
- INCOMPLETE PASS: a scheduling problem, not a parts order. Finish the configured passes before you buy anything.
- FAIL that follows one module across two slots: that module is the suspect. Start the warranty claim and note the serial number.
- FAIL that clears at JEDEC and returns with the profile: speed, voltage, timings, or firmware training. Drop the speed a step, relax the primary timings, or leave the profile off.
- FAIL that stays with one slot no matter which stick sits in it: reseat the module, try another slot, and suspect the board if the pattern holds.
The test that crashes instead of reporting is its own case. At that point the CPU, the power supply, and the motherboard are all candidates, and no single stick deserves the blame.
Keep the log next to your build notes, alongside the photo of the layout. When a crash returns in six months, that file answers the first question in the thread. Readers who want the same treatment applied to a small-form-factor machine, including what a 6400 MT/s memory configuration delivers, can follow NeoTeo's breakdown of the Minisforum T5 Max and its memory spec.
The action is the same for everyone: boot the stick, finish the planned passes, save the log from the USB drive, and let the isolation result pick the repair.
NeoTeo covers the hardware side of this work beyond a single diagnostic, from memory kits and mini PCs to the build guides that put them together. If you want more step-by-step troubleshooting and hardware analysis in that same practical voice, browse the tutorials and hardware sections at NeoTeo and find the guide for the machine on your bench.
