Memory-related BSODs: how to check RAM and find unstable memory

The operating system keeps memory in carefully managed structures. Drivers and the kernel allocate and free memory through the memory manager, which keeps track of which pages are valid, where they live, and who owns them. When code touches a page that the bookkeeping says it shouldn't — a freed page, a kernel page from user mode, an address that isn't mapped at all — the manager raises a fault. If that fault happens somewhere Windows can't recover from, the result is a stop error, and several of the most common stop errors are named after the memory subsystem because that's where the inconsistency was caught.

That's why a code with "memory" in it is a memory-management fault code, not a "your RAM is dead" code. The physical modules can be perfectly healthy and still produce one, if a driver dereferences a stale pointer or a storage fault corrupts data that the manager later reads. Conversely, a genuinely failing DIMM can corrupt data quietly and surface its problem hours later, in a component that has nothing to do with memory. The code tells you where the inconsistency was detected; your job is to work backwards from there.

Three behaviors deserve special attention, because they're the classic signatures of memory instability in the broad sense (module, configuration, or platform): crashes with no pattern and no obvious trigger, crashes that only appear after the machine has been running for a while, and crashes that started around the same time as a memory speed or voltage change. A one-off crash with a clear trigger is less likely to be memory, but memory can't be ruled in or out without the testing below.

A handful of stop codes show up repeatedly in memory discussions. None of them is a verdict — each has several possible causes, and the table below is a starting map that says which candidates to test and which caveats to keep in mind. For what the codes mean in general, the blue screen of death guide covers the full reading process.

Notice the pattern in the "caveat" column: every one of these codes has a non-memory cause that is at least as common as a memory cause. That's the whole reason this guide exists — the testing sequence below is what converts "probably RAM" into an actual conclusion.

Before testing, it helps to know what you're testing for. When a system misbehaves in ways that look memory-related, the root cause is one of seven things. The isolation sequence in this guide is designed so the evidence points at one of them.

1. A defective DIMM. A module with failing cells. Its signature: errors that follow the module from slot to slot, while other modules in the same slots stay clean.
2. Memory configuration instability. The module is fine, but the profile it runs at (XMP/EXPO, manual timings, or an aggressive voltage) is beyond what this particular CPU and board can sustain. Its signature: stable at JEDEC defaults, crashes or test errors only with the profile enabled.
3. A motherboard or slot problem. A damaged slot, bent pin, cracked trace, or weak channel. Its signature: errors that follow the slot — a known-good module errors in A2 but is clean in B1.
4. The CPU's integrated memory controller. It can degrade with age, or simply lack headroom for a speed profile. Its signature: errors across every module in every slot, at defaults, with power delivery verified clean.
5. BIOS/UEFI behavior. Memory training bugs, bad timing defaults, or a firmware regression. Its signature: instability that appeared after a BIOS update — or disappears after one.
6. Driver or software mimicry. A driver corrupting kernel memory, or a storage fault, surfacing as a memory-named code. Its signature: memory tests pass cleanly, and the crashes correlate with software events (updates, new apps, specific workloads).
7. Other hardware instability. Power delivery (VRM, PSU) or thermal problems making the memory subsystem misbehave under load. Its signature: crashes that track load and temperature rather than test patterns.

Keep these seven in mind while you work. Every result you record below is evidence for or against one or more of them, and by the end of the matrix you should be able to name a shortlist — which is the point at which you stop testing and start acting.

Memory testing is only interpretable when the system is in a standard configuration. A result from a machine running an unstable profile, with a half-seated module and three USB devices attached, tells you almost nothing. Spend ten minutes making the baseline before the first test, and every later result becomes meaningful.

1. Back up anything important. You'll be rebooting into test environments repeatedly; some tests take hours. If the machine is already unstable, assume the instability could get worse during the process.
2. Write down the current configuration. How many DIMMs, their size and speed, which slots they occupy, whether XMP/EXPO is enabled, and the BIOS version. The diagnostic record template below has a place for all of it.
3. Disable XMP/EXPO and run at JEDEC defaults. This is the single most important preparation step. Menu names differ by vendor (XMP, EXPO, D.O.C.P., Memory Profile, A-XMP…), but the setting is the one that switches the kit from its advertised profile back to the base spec. If the machine is unstable at the profile but stable at defaults, that's your answer — and no amount of module swapping will change it.
4. Remove the non-essentials. Keep the GPU (you need the display), one storage drive, and the keyboard. Disconnect extra USB devices, secondary drives, and anything you don't need. You're looking for the smallest stable system, not your full build.
5. Don't update anything yet. No BIOS updates, no driver updates, no Windows Update. Record the state first; updates are a variable you'll introduce deliberately later, not one that sneaks in during the test.

There are three practical options, and they're not equal. The right choice depends on how much you need to trust the negative result: a quick screen, or the evidence base for an RMA or a hardware conclusion.

For a real diagnosis, MemTest86 is the workhorse: it runs outside the operating system (so nothing in Windows is masking or adding to the problem), it can run unattended for many passes, and it reports the test number and the failing address, which is exactly what you need to document a reproducible failure. Windows Memory Diagnostic is a reasonable first screen when you don't have USB media yet, but don't treat a clean WMD run as proof the memory is healthy — treat it as "no quick fault found, run the longer test."

If you want to start with the built-in tool now, this opens it:

With the system at defaults (section 04) and all modules in their normal slots, boot the tester and let it run. This first pass-through has a specific job: it tells you whether the problem is eager (shows up quickly, every run) or lazy (needs time, temperature, or repetition). That distinction decides how much patience the rest of the matrix needs.

1. Boot the tester. From the MemTest86 USB (or WMD after a reboot). If the machine has been crashing on boot, use the recovery environment's boot options — the crash-loop guide covers forcing that.
2. Let it run unattended. Leave defaults on the tester's screen; you don't need to change its options. It will cycle through test patterns and count passes.
3. Record the first error precisely. If an error appears, note the test number, the failing address, and what it read versus what it expected. The tester keeps running after errors — let it, because the pattern of errors (same address every time, or scattered) is diagnostic in itself.
4. Run to a defined stop. Four complete passes, or two to three hours, whichever comes first. Write down the date, duration, pass count, and result before you touch anything else.

One caution: a single early error is a lead, not a sentence. Marginal faults can produce one error in the first hour and then go quiet, and a one-off error from a flaky cable or a marginal boot is not the same as a reproducible pattern. The rule for the whole matrix is the same: record, compare, conclude — never act on one data point.

A "pass" in a memory tester is one traversal of the address space for a given test pattern, and a full run cycles through many patterns. A single complete run therefore touches each memory location a limited number of times, with a limited set of access patterns. That's fine for catching a dead cell. It is not fine for catching a marginal one — a cell or a channel that fails one access in ten thousand, or only above a certain temperature, or only when its bank is accessed in a particular order. Memory faults are probabilistic, which means the test has to run long enough that "probable" becomes "observed."

Time and repetition are the diagnostic instruments here. The longer the run and the more passes, the higher the chance of catching an intermittent fault — and the more meaningful a clean result becomes. This is also why "I ran it once and it passed" is the least useful sentence in RAM troubleshooting: it's a short, single-pattern sample of a probabilistic system.

Practical targets, scaled to how urgent and how intermittent the problem is:

One more scope note: a clean test at defaults says nothing about the machine at its advertised profile. If the PC runs XMP/EXPO in daily use, the profile gets its own test later (section 12). The two configurations are different systems, and each needs its own evidence.

If the first run was clean and the crashes continue, the correct next step is often the least exciting one available: run the same test again, for longer. Intermittent faults frequently need repetition to reveal themselves, and a large share of "mystery" memory cases resolves at this step — an overnight run that was clean in the first two hours produces its first error at hour six, and the diagnosis goes from impossible to straightforward.

Keep the configuration identical between repeats; that's what makes the results comparable. Small environmental variations are acceptable and occasionally useful — machine orientation changes airflow, a warm room changes thermal margin — but note them in your record rather than pretending they weren't there. What you must not vary is the thing under test: same modules, same slots, same profile.

If the first run produced errors, repeat before isolating too. Two error runs tell you whether the errors are reproducible (the strong case — same test, same or similar addresses, every boot) or sporadic. Reproducible errors are worth far more diagnostically than a scattered one, because they give you a stable target to chase through the module and slot matrix.

Module isolation is the heart of the diagnosis. With a single module installed, any error you see must involve that module, that slot, or the platform path they share — everything else is out of the equation. Test each module alone, in the same slot (the primary slot your manual recommends for a single DIMM — usually the second slot from the CPU, but check your manual, since it differs), for a comparable number of passes.

Record every combination in the matrix, and interpret the pattern rather than any single cell:

The trap to avoid: a module passing on its own does not prove the whole configuration is stable. Dual-channel interleaving, rank interactions, and profile timings only exist with multiple modules installed, so the full configuration always gets its own test at the end. "Each stick passes" is a necessary step, not a conclusion.

The checklist below is the full test matrix in order. It's saved in this browser, so you can work through it across several days — which is usually what this process actually takes.

Every motherboard has a slot-and-channel layout: two or more memory channels, each served by one or two physical slots, typically labeled A1/A2 and B1/B2 (the names and the recommended slots vary by board — your manual defines them). The slots are not equivalent: the manual's preferred slots give the memory controller the best electrical path, and any slot can individually be damaged — a bent pin, a cracked trace, a swollen capacitor nearby. If one slot is bad, every module in it will produce errors, no matter how healthy the stick is.

The slot test is the mirror of the module test: take a module — ideally one that produced errors, plus a known-good one — and move it slot by slot, with the same pass count each time. If the errors follow the module from slot to slot, the module is implicated. If the errors follow the slot — the known-good module errors in A2 but is clean in B1 — the slot, its channel, or the board's path is implicated, and the answer is a board-level one, not a new DIMM. Swapping modules between the two channels (A↔B) is a useful variant: if a failing pair follows the channel, that points at the channel's path or training rather than the individual modules.

Also check the physical layer before you go deeper: a partially seated module, dust in a slot, or a slightly bent pin can produce exactly the signature of intermittent memory errors. Reseating every module is a zero-cost test. Visually inspecting slots with the power off and capacitors discharged is reasonable — but that's roughly where "safe home maintenance" ends and "take it for service" begins.

Most kits are sold as matched pairs, and most systems run dual channel: the memory controller interleaves data across both channels for bandwidth. That interleaving — plus how ranks and densities interact between channels — means a configuration can be unstable even when every individual module is perfectly good. "Passes alone, fails together" is the classic signature of a configuration or platform problem, not a dead stick, and it's the reason the matrix always ends with the full build.

Reassemble in stages, still at defaults: each module alone (done), then the pair in the manual's recommended dual-channel slots, then the full configuration. If a pair fails, try it in the other channel pair (swap A↔B): if the failure follows the channel, the channel's path or training is implicated; if it follows the specific two modules, their interaction is. Each swap is one controlled experiment, and each result narrows the seven-cause shortlist from section 03.

Mixed kits deserve a word of their own. Mixing brands, speeds, densities, or rank counts in one system forces the whole set to run at the slowest common specification and defeats the validation the kits went through as a set. Instability from a mixed configuration is common, and it's a configuration problem first: try the modules in separate systems, or at defaults, before concluding any of them is defective. If your machine has mixed modules and started crashing after a recent swap, that event is the lead.

XMP (eXtreme Memory Profile) and EXPO (AMD's DDR5 equivalent) are speed profiles stored in the DIMM's SPD chip. Enabling one tells the motherboard to run the kit at its advertised frequency, timings, and voltage instead of the JEDEC base specification — DDR4-2133/2666 or DDR5-4800, depending on your generation. The profile is validated by the memory vendor on their test platforms, but "validated" does not mean "stable on every CPU and every motherboard." The memory controller in your specific CPU has its own headroom, and your board's traces and power delivery have their own limits. The kit, the CPU, and the board are three different companies' products meeting for the first time at the profile's edge.

That's why a perfectly functional kit can still crash at its advertised profile: the CPU's integrated memory controller can't quite sustain the speed, the timing margins are too thin for your board's particular traces, or the voltage sags under load. The classic result is a system that's rock-solid at JEDEC defaults and bluescreens — often with a memory-named code — the moment XMP or EXPO is switched on. Calling the profile "overclocking" is fair in one sense (it runs above the JEDEC base spec) and misleading in another: it's a specification the vendor ships, not a manual tweak — and it is the single most common cause of "new RAM, new crashes" reports.

The diagnostic move is a direct comparison, which is why the whole matrix runs at defaults first: establish the baseline, then enable the profile and retest. The four outcomes are different diagnoses:

When the profile is the culprit, the fixes are in a specific order: update the BIOS first (memory support and training improve with firmware, and this is often the whole fix), then step the profile speed down one notch, and only then consider a small voltage increase. DDR5 deserves an extra line: EXPO profiles, higher operating voltages, the power management on the module itself, and longer boot-time training make DDR5 systems more sensitive to marginal configurations than DDR4 was — a BIOS update is disproportionately effective there.

Some memory faults only appear after hours: the system warms up, thermal margins shrink, and a marginal cell finally fails. Others only appear under specific workloads — gaming is the classic example, because it drives the CPU, GPU, and memory simultaneously and keeps the whole system hot for long, unbroken stretches. A crash that happens "only in games" is most often blamed on the GPU, and the GPU is a good candidate — but memory and power are in the same differential, because the same conditions that stress a GPU also stress the memory path.

The test for workload cases is to combine two pieces of evidence: reproduce the workload under the same configuration and watch for the crash, while also running an extended memory test at that same profile. If the crash happens in the game and the memory test at the identical configuration produces errors, the correlation is strong and the direction is set. If the test stays clean, extend the duration, and then give the other causes on the seven-cause list their turn — "game crashes" have a long differential, and memory is one of its entries, not all of it.

This is where documentation stops being optional and becomes the deliverable. Whether you're filing an RMA, asking for help, or just keeping yourself honest across a week of testing, the record is what turns scattered observations into a pattern. Copy this template and fill one in per configuration:

RAM diagnostic record — DiagMyPCHub
Date / time:
Machine (CPU / motherboard / BIOS version):
Modules: make, size, speed, slots (e.g. 2x8GB DDR4-3200, A2+B2)
Profile: JEDEC default | XMP/EXPO (specify speed & voltage)
Tool: MemTest86 (version) | Windows Memory Diagnostic
Configuration tested: [module(s) + slot(s)]
Passes / duration:
Errors (test number, address, read/wrote):
Notes (temperature, workload, reboots):

After the matrix, the evidence usually points one of six ways. The table below is the synthesis — the place where recorded results become a direction. Read it as patterns, not rules: real machines produce ambiguous results, and the right move for an ambiguous result is one more controlled test, not a purchase.

The CPU memory controller deserves its own paragraph because it's the one people don't expect. It's integrated into the CPU and drives every channel, so its failure mode is distinctive: errors appear on every module in every slot, at defaults, with power delivery checked. A controller can also simply lack headroom for a fast profile — a perfectly healthy CPU whose IMC can't sustain DDR4-3600 or DDR5-6000 — which looks identical to "bad RAM" until you test at defaults. At that point the practical answer is vendor diagnosis, because you can't test or replace a memory controller in isolation from the CPU, and swapping CPUs to confirm is a last-resort experiment, not a repair step.

Two more patterns round out the picture. For the board: if the fault follows a channel or a slot and the modules are proven clean, the answer is the board — traces, the slot itself, or the power delivery around it — and that's a service-level issue, not a parts-bin one. For firmware: BIOS updates change how memory is trained and which timings the board supports, so instability that appeared right after a BIOS update should be tested against the previous firmware version (where the vendor allows downgrading) before you conclude the hardware changed. Firmware is a variable like any other in this matrix — one that most people forget to log.

The matrix exists to end in one of a few concrete actions, so here they are, matched to the evidence. If the evidence isolates a DIMM — it errors in every slot you tried it in, the other modules are clean, and the configuration was at defaults — stop troubleshooting memory and RMA or replace the module. Then re-run the matrix on the replacement (singles, full configuration, defaults and profile) so you know the fault is actually gone rather than merely moved. Keep the failing module for the RMA; the records you wrote are the evidence that makes a warranty claim fast.

If the evidence points at the slot, the channel, or the board — or at the CPU's memory controller — the honest answer is that you're past safe home-repair territory. Reseating and visual inspection are fair; anything deeper is vendor diagnostics and warranty. Do not buy "more RAM" as a fix for a board or controller problem: it won't fix it, and the new modules will inherit the same fault pattern, which is exactly the result that sends people on a second, more expensive round of guessing.

If every test passes — at defaults and at the profile, with extended duration — take that seriously as a result, not a failure. The memory subsystem has been tested under the conditions that matter, and it held. Crashes that continue despite that are more likely to be drivers, storage, updates, or power, and the correct move is to return to the full BSOD workflow with the knowledge that memory is off the list. That's a real, time-saving conclusion, and it's what the whole exercise was for.

If you'd rather have a guided route than a matrix, answer a few questions and this will point you at the right stage of the process. It mirrors the workflow above: known state first, then initial test, then isolation, then profile comparison. It's a decision aid, not a diagnosis — the evidence still has to come from the tests.

Match your situation to a row below and start from its first test. Filter by the kind of behavior you're seeing. These are starting points — every row has more than one possible cause, which is exactly why the matrix above exists.

10 situations

Memory is one thread in the larger BSOD story. These guides from the wider library follow on naturally from here.