Random crashes and corruption — testing for bad memory
Bugchecks that vary from boot to boot, with no single driver named, are the signature of failing memory or an unstable memory configuration.
What you see
Different bluescreens each time — MEMORY_MANAGEMENT, PFN_LIST_CORRUPT, IRQL_NOT_LESS_OR_EQUAL, KMODE_EXCEPTION — plus occasional file corruption and applications closing without warning.
What is actually wrong
A failing module, a module seated badly, or an XMP/EXPO profile the memory controller cannot actually sustain. On servers, a single failing DIMM that ECC has stopped being able to correct.
Codes and articles
Fixes (3)
Test the memory properly, one module at a time
Varying bugchecks with no consistent driver.
Look at the recent bugchecks to confirm they vary rather than repeat.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} -MaxEvents 20 | Format-Table TimeCreated,Message -WrapRun the built-in test first — it is quick and a failure there is conclusive.
mdsched.exeThe built-in test passing proves very little. Run MemTest86 from a USB stick for at least four full passes, overnight.
Windows Memory Diagnostic runs a short pattern set for a few minutes. Marginal memory routinely passes it and fails on pass three of a proper test. A single error in eight hours is still a failed module.
If errors appear, test each module individually in the same slot to identify which one, then test the good module in each slot to rule out the slot itself.
Reseat everything before concluding — a module not fully home in its slot produces identical symptoms to a failed one.
Test at the memory's actual rated speed
An XMP, EXPO or DOCP profile is enabled. Do this before an overnight memory test — it is faster and it is frequently the answer.
Enter the BIOS and disable the memory profile, returning the modules to their JEDEC default speed.
Run the machine at the default for a few days. If the crashes stop, the memory was being asked to run faster than the controller can manage in this configuration.
An XMP profile is a factory overclock. It is validated for the module, not for the combination of that module, that board and that CPU's memory controller — and four modules are much harder to run at profile speed than two.
If you want the speed back, re-enable the profile but reduce it by one step, or raise the memory controller voltage slightly within the board's recommended range.
Check the board's memory support list — populating all four slots often requires a lower speed than two slots, and the board documents it.
Read what ECC has already recorded
A server. ECC has almost certainly logged the failing DIMM by name.
Read the WHEA records — these name the physical DIMM slot.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object ProviderName -like '*WHEA*' | Format-List TimeCreated,Id,MessageCheck the management controller — iDRAC, iLO, IMM or equivalent — for correctable error counts per DIMM. A rising correctable count precedes an uncorrectable failure by days or weeks.
This is the value of ECC: the failure is visible before it takes the machine down. A DIMM with a climbing correctable count should be replaced at the next window, not after the outage.
Replace the identified DIMM and clear the counters in the management controller.
If several DIMMs on the same channel report errors, suspect the CPU socket or a bent pin rather than the memory.
Get-WinEvent -LogName System -MaxEvents 200 | Where-Object ProviderName -like '*WHEA*' | Measure-Object | Format-List CountRelated faults
Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.