How to Test Your RAM Properly

Almost every stop code on this site eventually says test your memory. Done badly, that means running the built-in Windows tool, getting a pass, and crossing RAM off the list incorrectly. Done properly it is one of the few conclusive tests available at home - but only if you understand that there are two different questions here and they need different tools.

Updated 2026-07-28

The two questions people conflate

This is the thing most guides skip, and it causes more wasted evenings than any other misunderstanding in this area.

Question one: is a module defective? Are there physically bad cells that fail regardless of how the memory is configured? This is a hardware fault, it does not go away, and the module needs replacing. MemTest86, run at stock settings, answers this.

Question two: are my settings stable? The modules may be perfectly healthy while the speed and timings you have asked for exceed what your particular CPU's memory controller and motherboard can sustain. Nothing is broken; the configuration is over-ambitious. Stability testers running inside Windows answer this, and MemTest86 is comparatively poor at it.

Why it matters

People buy replacement RAM because MemTest86 found errors with XMP enabled, when the modules were fine and the profile was not. Others declare memory healthy after a stability test passes, when a defective cell sits in a region the test never touched. Ask which question you are answering before you pick a tool.

Why Windows Memory Diagnostic is not enough

Windows includes mdsched.exe, and several Microsoft troubleshooting pages recommend it. It runs a limited set of test patterns for a short time and then reports a result to the event log.

The problem is sensitivity. It routinely passes modules that a thorough tester finds errors on within the first hour. A failure from it is meaningful - that is a definite fault. A pass from it is close to no information at all.

If you have already run it and it passed, that is not a reason to skip what follows. If you want to see the result it recorded:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-MemoryDiagnostics-Results'} |
  Select-Object TimeCreated, Message |
  Format-List

Running MemTest86 correctly

MemTest86 boots from USB and runs outside Windows, which is what allows it to test memory that an operating system would otherwise be occupying. The free version is sufficient.

Preparation matters more than people expect:

Disable XMP or EXPO in UEFI first. You are testing the modules, not the profile. Testing with a profile enabled conflates the two questions above and is the single most common mistake here.
Download MemTest86 and write it to a USB stick using the imaging tool it ships with.
Boot from the stick - usually F12, F9 or Escape at power on for a boot menu.
Let it run. It starts automatically after a few seconds.

How long: a minimum of four complete passes. Overnight is better. A single pass is not enough - some patterns only run on certain passes, and intermittent faults need time to surface. Expect several hours for a typical amount of memory.

Reading the result: the error count is at the bottom of the screen. Any error at all is conclusive - there is no threshold below which errors are acceptable. Note the failing address range if it reports one.

Isolating which module and which slot

If errors appear with everything installed, you know a fault exists but not where. Narrowing it takes patience and a specific method.

Power down fully and unplug at the wall.
Remove all modules except one, and put that one in the same slot every time - typically the second slot from the CPU, but check the board manual for the single-module position.
Run at least four passes.
Repeat with each module in that same slot.

Testing each module in the same slot is what separates a faulty module from a faulty slot. If you move both the module and the position at once, a failure tells you nothing about which changed.

If every module passes alone but the full set fails together, the modules are probably fine. Suspect the slot, the board, or the memory controller - and check whether you are running four modules on a board and CPU combination that struggles with four, which is common and often solved by slightly loosening timings rather than by replacing anything.

Testing whether your settings are stable

Once the modules are proven clean at stock, re-enable your profile and ask the second question. These tools run inside Windows and are far better at catching marginal instability than MemTest86 is:

Tool	Notes
TestMem5 (TM5)	Free. Used with community configuration files that adjust which patterns run. Widely regarded as the most sensitive for catching marginal memory settings, and fast at it.
Karhu RAM Test	Paid, small one-off cost. Reports coverage as a percentage, which makes it easy to judge when you have tested enough. Very sensitive.
HCI MemTest	Free version available. Older, slower, still effective. Run multiple instances to cover more memory.
OCCT	Free tier. Includes a memory test alongside CPU and power tests, convenient if you are checking several things.

Run one of these for a few hours after enabling your profile. An error here means the settings are not stable - the fix is to loosen the primary timings a step, raise the memory controller voltage slightly, or accept a lower speed. It does not mean the modules are defective.

What a pass actually means

Be careful with the conclusion you draw.

Errors are conclusive. There is no ambiguity and no acceptable error rate. Act on them.

A pass is suggestive, not proof. Intermittent faults can hide from any test - some only appear at particular temperatures, after hours of operation, or under access patterns the test does not generate. Four clean passes substantially reduce the probability that memory is your problem; they do not eliminate it.

So if every other avenue is exhausted and the evidence still points at memory - several unrelated stop codes, corruption-flavoured bugchecks, crashes surviving a clean Windows install - do not treat a clean MemTest run as closing the case. Swapping in known-good modules for a week is a more conclusive test than any software can offer.

What to do when it fails

Claim the warranty. Memory usually carries a long warranty, often a lifetime one, and manufacturers generally honour it on a MemTest86 error report. Photograph the error screen.

Claim the whole kit, not one module. Memory is sold in matched kits that are tested together. Replacing a single stick from a kit frequently reintroduces instability even when both are individually fine, because they were never validated as a pair.

Check it is not the slot first. Before returning anything, confirm the fault follows the module rather than staying with the position. A returned module that was never faulty comes back as no fault found and costs you weeks.

Consider the cause. Memory that fails after running at an aggressive profile for a long time may have been degraded by sustained high voltage. That does not usually affect a warranty claim, but it is worth being more conservative with the replacement.

Frequently asked

How many passes of MemTest86 is enough?

Four complete passes as a minimum, and overnight if you can. Different test patterns run on different passes, so a single pass exercises only part of the suite. If you are chasing something intermittent that only crashes weekly, consider a longer run - eight passes or more. The trade-off is only your time, since the machine is unusable during the test either way.

Should I test with XMP on or off?

Off, first. That tells you whether the modules themselves are sound. Once they pass at stock, re-enable the profile and use a Windows-based stability tester to check whether the settings hold. Testing only with XMP enabled leaves you unable to distinguish a defective module from an over-ambitious profile - and those have completely different fixes, one of which costs money unnecessarily.

MemTest86 passed but I still think it is the RAM. What now?

A pass is not proof, particularly for faults that depend on temperature or long uptime. Two things worth trying: run a Windows-based stability tester at your actual settings for several hours, since those catch marginal instability MemTest86 misses; and if you can borrow known-good modules, run on those for a week. Substitution is the most conclusive test available and no software equals it.

Can bad RAM damage anything permanently?

Not the hardware. It can corrupt data, though - anything the machine wrote to disk while memory was misbehaving may be silently wrong, including files that appear to save normally. That is why it is worth being careful about trusting documents and archives created around the time of the crashes, and why backing up before a long diagnostic process is sensible. The corruption risk is to your files, not to your components.

Is ECC memory worth it to avoid all this?

It corrects single-bit errors transparently and reports them, which turns a mystery crash into a logged event. That is genuinely valuable for diagnosis. The catch is that it requires CPU and motherboard support, which most consumer desktop platforms do not offer, and the modules cost more. For a workstation handling data you cannot afford to have silently corrupted it is worth the platform choice; for a gaming machine it is usually not, and the newer DDR5 on-die error correction is not the same thing despite sounding similar.