MemTest86 is the standard tool for testing RAM because it runs outside Windows from a bootable USB drive, giving it direct, uncontested access to memory that a background operating system would otherwise interfere with. A clean run with zero errors after a full pass, or ideally several hours, is a strong sign your memory is stable; even one error usually means something needs attention, whether that’s reseating a stick, dialing back an XMP profile, or replacing hardware.

Two desktop memory modules over a circuit board with timing waveforms
Conceptual illustration of RAM modules and memory timing signals.

Quick answer

Download MemTest86 from its official site, write it to a USB drive with the included imaging tool, boot from that USB, and let it run. Zero errors after one full pass is a good sign; zero errors after 4+ hours or multiple passes is a strong sign. Any errors mean stop, note which test number and address they occurred at, and start narrowing down the cause rather than assuming the RAM itself is defective.

As an Amazon Associate we earn from qualifying purchases at no extra cost to you. Product prices and availability are accurate as of the date shown and are subject to change.

Scenario What to do Typical cause
Errors at XMP/EXPO speed only Retest at default JEDEC speed Overly aggressive memory profile
Errors on one stick, clean on another Test each stick individually Defective module
Errors change between test runs Reseat and retest Poor slot contact
Errors even at default speed, single stick Consider RMA Genuine hardware fault

Why RAM testing catches problems other tools miss

Unstable memory produces some of the most misleading symptoms in PC troubleshooting because the errors it causes look identical to software bugs, driver issues, or corrupted game files. A single flipped bit during a memory write can crash a game to desktop, corrupt a save file, or cause a blue screen with a generic error code that points nowhere near the actual cause. This is why memory testing is usually one of the first steps recommended for random, hard-to-reproduce crashes rather than something reserved for obviously broken hardware.

Temperature monitoring tools and drive health checkers, covered in our guide to PC temperature monitoring software, cannot catch memory instability because RAM errors are not thermal in most cases; they’re about signal integrity, timing, and voltage. A stick can run at a perfectly reasonable temperature while still producing errors under XMP timings the specific chips cannot sustain.

New builds benefit from a RAM test before anything else gets installed, since catching a defective stick in the first hour of ownership is far easier than debugging a game crashing three months later after dozens of other changes have happened to the system. Many experienced builders treat a MemTest86 pass as a standard step alongside the initial PC build process, right after confirming the system posts.

Testing also matters after any memory-adjacent change: adding a second kit, updating BIOS, or applying a new XMP or EXPO profile. Each of those changes the electrical conditions memory operates under, and what was stable before is not guaranteed to remain stable after.

Getting MemTest86 onto a bootable USB

MemTest86 (distinguished from the open-source Memtest86+ fork, which is also a valid option) is downloaded as an image file from its official site, then written to a USB drive using the imaging tool included in the download package for Windows, or a tool like Rufus if you are working from another OS. The USB drive needs to be at least 512MB, and everything on it will be erased in the process, so back up anything important on that drive first.

Once the image is written, restart the PC with the USB drive plugged in and enter the boot menu, usually by pressing a key like F11, F12, Esc, or Delete during startup depending on the motherboard brand; the exact key is normally shown briefly on the boot screen itself. From the boot menu, select the USB drive rather than the normal Windows boot drive.

MemTest86 will load its own minimal environment and present a menu to start testing. On systems with UEFI-based motherboards (essentially all built in the last decade), booting the UEFI version of the USB drive rather than the legacy BIOS version ensures it can see the system’s full memory capacity, particularly important on systems with 32GB or more installed.

Reading test results correctly

MemTest86 runs through a series of numbered test algorithms, each checking memory in a different pattern designed to catch different failure modes, from simple stuck bits to more subtle address-line or timing-related errors. A completed pass means all test algorithms finished; the pass counter increases each time the full sequence repeats.

Any error found is logged with the specific test number, the memory address where it occurred, and details about the expected versus actual value read back. You do not need to interpret the technical details of the error itself, but noting the test number is useful context if you later contact a manufacturer for warranty support, since it demonstrates the failure was reproduced with a recognized diagnostic tool.

Zero errors after a single pass is a reasonable baseline, but memory errors are sometimes intermittent and only surface after extended time at operating temperature, or after enough address combinations have been cycled through. An overnight run covering several passes gives meaningfully more confidence than a 20-minute single pass, especially for a system you plan to keep running unattended, like one used for game servers or long recording sessions.

If the test appears to hang rather than complete or show errors, let it run longer before assuming it has frozen; some test algorithms take much longer than others on large memory capacities, and a 64GB kit can take considerably longer per pass than a 16GB kit.

Isolating which stick is causing errors

When MemTest86 reports errors on a multi-stick system, the next step is narrowing down which specific stick is responsible rather than assuming the whole kit is bad. Power down, remove all sticks except one, and run the test again; repeat with each stick individually installed in the same slot to rule out a slot-specific issue rather than a stick-specific one.

If a single stick tested alone in a known-good slot still produces errors, that stick is very likely the actual problem and a candidate for warranty replacement. If every stick tests clean individually but errors reappear once multiple sticks are installed together, the issue is more likely to be a compatibility, timing, or slot-population problem rather than a specific defective module.

Testing in a different slot with the same stick is worth doing before concluding a stick is defective, since a bent pin in a DIMM slot or a poor contact can produce errors that look identical to a memory defect. If a stick tests clean in slot 2 but errors in slot 1, the slot itself, or dust and debris in it, deserves attention before you write off the stick.

Keep notes as you go through this process; it is easy to lose track of which combination has already been tested, especially on boards with four DIMM slots and a two-stick kit, where there are more slot combinations than most people expect.

A large share of “defective RAM” reports are actually cases where an XMP or EXPO profile is pushing frequency, timings, or voltage beyond what a specific motherboard and CPU memory controller combination can reliably sustain, even though the memory chips themselves are fine. This is common enough that testing at default JEDEC speed (XMP or EXPO disabled) is a standard troubleshooting step before assuming hardware failure.

If a kit errors at its rated XMP/EXPO speed but runs clean at default speed, the practical options are running at a slightly reduced frequency than the kit’s rating, loosening the timings a notch, or in some cases increasing the memory controller or SoC voltage slightly if your motherboard’s BIOS exposes that option; each of these trades a bit of theoretical performance for stability, more detail on the tradeoffs is in our RAM speed and timings guide.

Some CPUs, particularly certain generations, are known to have memory controllers that struggle with four DIMM slots fully populated at rated XMP speed even when running two sticks at that same speed works fine; this is a documented limitation rather than a defect in any specific component, and the fix is usually a modest frequency reduction rather than a return.

Motherboard BIOS updates occasionally improve memory compatibility for specific kits through better default training parameters, so if a kit is listed as compatible with your board on the manufacturer’s memory support list but is still erroring, checking for a BIOS update is worth trying before assuming the kit itself is defective.

Physical reseating and slot cleaning

Before assuming any test result points to defective hardware, physically reseating memory sticks resolves a surprising number of intermittent errors, since a stick that was not fully clicked into place during the original build can appear to work while still having marginal contact under load. Power off, unplug the system, press the retention clips open, remove the stick, and reinsert it firmly until the clips snap closed on their own.

Static discharge is a real risk when handling memory directly; touching an unpainted metal part of the case, or ideally wearing an anti-static wrist strap, before handling sticks reduces the (small but nonzero) chance of damaging sensitive components during reseating, something covered more in our anti-static wrist strap guide.

Visually inspecting the gold contacts on the bottom edge of each stick for dust, discoloration, or debris is worth doing while it’s out of the slot; a can of compressed air on the slot itself, with the system powered off, can clear out dust that has settled over time, particularly relevant in systems that have been open or in dusty environments.

Testing memory in a new versus existing build

A brand new build benefits from a clean overnight MemTest86 run before anything else gets installed, since this establishes a stable baseline before games, drivers, and background software introduce other variables that could later be mistaken for a memory issue. Treat this pass as part of the same initial verification stage as confirming XMP or EXPO applied correctly, since both checks are quick, one-time steps that save considerable troubleshooting time months down the line.

An existing system that has run stably for a long time and only recently started showing crashes is a different diagnostic situation; here, testing is less about catching a factory defect and more about ruling memory in or out as the cause of a new symptom, alongside other recently changed variables like a driver update, a new game, or a hardware addition. Working backward through what changed right before symptoms started is often more productive than testing memory in isolation without that context.

Used or second-hand memory kits, whether bought individually or as part of a used prebuilt system, are worth testing before trusting them in any important system, since their prior operating history and handling are unknown; a full overnight MemTest86 pass here serves the same verification purpose it does for a new kit straight from the manufacturer.

When testing does not give a clear answer

Not every unstable system produces clean, repeatable MemTest86 errors, even when memory genuinely is the cause. Marginal instability tied to temperature can pass a test run in a cool room and fail hours into a hot afternoon; if crashes correlate with ambient temperature or how long the system has been running, consider testing again after the system has been under load for a while rather than immediately after boot.

Power delivery issues can mimic memory errors closely enough to confuse the picture, since an unstable or aging power supply can cause voltage fluctuations that memory is sensitive to. If MemTest86 comes back completely clean but crashes continue, checking the power supply, covered in diagnosing a failing power supply, is a reasonable next step rather than continuing to suspect memory.

Some crashes attributed to memory are actually caused by an unstable CPU overclock or an aggressive undervolt, since both change the electrical margins the whole system operates within, not just the CPU. If you have made CPU-side changes recently, reverting those to stock before retesting memory helps isolate which component is actually at fault.

Troubleshooting common testing problems

If the USB drive does not appear in the boot menu at all, the most common cause is the boot mode mismatch between how the drive was written (UEFI vs. legacy) and how the motherboard is configured; try both boot modes if your BIOS boot menu lists the drive twice, once under each mode, or check that Secure Boot is not blocking the unsigned bootloader (some boards need Secure Boot disabled specifically for MemTest86 to boot).

A system that reboots on its own partway through a test, rather than showing an error and continuing, often points to something more serious than a simple bit error, such as overheating or a power delivery problem severe enough to trigger a hard reset; check temperature monitoring during a shorter test run to rule that out first.

If results are inconsistent between runs, with errors appearing in one run and a completely clean pass in the next under otherwise identical conditions, this pattern itself is diagnostic: it points toward marginal stability (an XMP profile right at the edge of what the system supports, or a slot with intermittent contact) rather than an obviously defective stick, which would typically fail more consistently.

Test runs that seem to complete unusually fast compared to the expected duration for your memory capacity may indicate MemTest86 only detected and is testing a fraction of installed memory; this usually traces back to booting the legacy BIOS mode USB image instead of UEFI mode on a system with more than 4GB per test region, so confirm you booted the correct mode.

Frequently asked questions

How long should I run MemTest86?

One full pass (all test algorithms) is a reasonable first check, but many errors only appear after 4-8 hours or multiple passes, so an overnight run is the more reliable way to confirm a stick is truly clean.

Does MemTest86 need Windows installed?

No, it runs from a bootable USB drive completely outside of Windows, which is actually the point, since it needs to control memory directly without an operating system using part of it at the same time.

Is one error enough to call a stick bad?

A single error can be a fluke from an aggressive XMP or EXPO profile rather than defective hardware, so first retest at default JEDEC speeds before concluding the stick itself has failed.

Can I test RAM without removing it from the motherboard?

Yes, MemTest86 tests memory in place; you only need to physically remove and reseat sticks if you are trying to isolate which specific stick or slot is causing errors.

Is Windows Memory Diagnostic as good as MemTest86?

It is a reasonable built-in fallback with fewer test algorithms and shorter default run time, useful for a quick sanity check, but MemTest86 is more thorough for genuinely diagnosing an intermittent crash.

Daniel Kovac, Components Editor, runs new memory kits through an overnight MemTest86 pass on the PSU load tester bench before any kit goes into a recommendation, precisely because the intermittent errors that only show up after hours of runtime are the ones most likely to cause real-world crashes. If your kit does turn out unstable at rated speed, our best RAM for gaming and best DDR5 RAM guides cover kits with a track record of running clean at their advertised specs.

Related guides

Browse all Cases & Cooling guides →