Diagnose unstable RAM or memory settings behind boot BSODs and restart loops

Windows crashes during startup with changing bug checks, changing named modules, checksum failures, decompression errors, or spontaneous restarts because memory data is not stable. The cause may be a faulty DIMM, an unstable XMP/EXPO profile, CPU memory-controller limits, a bad slot, incorrect voltage or timing, mixed modules, or motherboard/firmware behavior. No single Windows code proves defective RAM; the pattern and controlled tests do.

Searchable Windows error codes and exact messages

Search the exact code, parameter values, motherboard/computer model, CPU, memory-kit part number, and whether XMP or EXPO is enabled. Do not search only the .sys filename when each crash names a different file.

Use this procedure when crashes vary across boots, protected files repeatedly corrupt, Windows installation or recovery intermittently fails, a memory profile or overclock is enabled, new RAM was installed, or a memory test reports an error.

Do not assume RAM when repeated dumps consistently identify one third-party driver and a controlled driver rollback fixes the problem. Do not open sealed or soldered-memory hardware beyond the manufacturer's service procedure. Do not reseat components while power is connected.

The exact Windows build and faulty address may remain unknown. The module population, memory-kit part numbers, current profile/settings, test configuration, which DIMM was in which slot, and whether errors follow a module or slot may not remain unknown.

• The system or motherboard service manual
• Antistatic precautions and safe physical access, if RAM is removable
• Windows Memory Diagnostic when Windows or Safe Mode starts
• A reputable bootable memory test or manufacturer diagnostics for extended testing
• A known-good compatible DIMM when available
• Paper or a file for a test matrix; every module and slot must be labeled

Record all firmware memory, CPU, and voltage settings before changing them. Photograph DIMM placement and labels. Shut down, disconnect AC power, and follow the manufacturer's power-discharge and antistatic procedure before touching removable RAM.

1. Preserve recent dumps and note whether stop codes or named modules vary.

2. Record whether any of these preceded the first failure:

   • XMP/EXPO was enabled or changed
   • CPU, fabric, base-clock, GPU, or memory overclocking changed
   • Firmware was updated or reset
   • DIMMs were added, mixed, moved, or replaced
   • The computer was physically moved or serviced

3. Enter firmware setup and record:

   • Installed memory amount
   • Detected DIMM slots
   • Memory speed
   • XMP/EXPO/profile state
   • Memory voltage and timings when shown
   • CPU or memory-controller overclock state

4. Load documented optimized/default settings or individually return CPU and memory settings to Auto/default. Disable XMP/EXPO for diagnosis. Preserve unrelated settings such as boot mode and controller mode.

5. Cold-start Windows twice. If the loop ends at default memory settings, the profile is unstable until proven otherwise.

6. If Windows starts, run Windows Memory Diagnostic:

   mdsched.exe
   

   Choose Restart now and check for problems only after saving work. After Windows returns, preserve the MemoryDiagnostics result from Event Viewer.

7. A pass is not absolute proof of good memory. Intermittent failures can require extended bootable tests, cold starts, and module/slot isolation.

Branch A — Default settings stop the crashes

1. Leave XMP/EXPO and overclocking disabled.

2. Run the memory test and a representative workload at defaults.

3. Verify the memory kit is supported for the board/CPU combination and installed in the recommended slots.

4. If the owner later chooses to tune memory, change one documented setting at a time and treat any error as instability. A Windows repair writeup should not prescribe higher voltage.

5. Repair Windows files only after memory is stable:

   dism /Online /Cleanup-Image /RestoreHealth
   sfc /scannow
   

Branch B — Test removable DIMMs one at a time

1. Power down completely and follow the service manual.

2. Label modules A, B, and so on. Label motherboard slots using the manual's names, not assumed left-to-right numbers.

3. Install one module in the board's recommended single-DIMM slot.

4. Cold-start and run the same extended memory test. Record pass/fail, test version, pass count, error addresses, and temperature/environment if relevant.

5. Repeat the same module in the same slot to confirm a failure is reproducible.

6. Test each remaining module in that same known test slot.

7. If one module fails there while others pass, replace that module or the matched kit according to the vendor's warranty rules.

8. If every module fails in the same slot, test a known-good compatible module in another manual-approved slot.

Branch C — Distinguish module, slot, and memory-controller failures

Use a controlled matrix:

1. Keep frequency, timings, voltage, and test version identical throughout the matrix.

2. Do not mix modules from different kits even when their marketed specifications match, unless the platform vendor supports that population.

3. Inspect socket/contact or board issues only within the system manufacturer's service procedure.

4. Replace or service the component indicated by repeatable cross-testing.

Branch D — Memory becomes stable but Windows files remain damaged

1. Back up data.

2. Check the Windows volume and storage events.

3. Run DISM and SFC from stable Windows as shown above, or their offline equivalents from the matching file-repair writeup.

4. If corruption returns with known-stable memory, investigate storage, power, filters, and the controller path.

• Defaults eliminate all failures: The memory/CPU profile was unstable; no DIMM replacement is proven necessary.
• Errors follow one module: Replace the module or matched kit.
• Errors follow one slot/channel: Escalate motherboard, socket, or CPU memory-controller diagnosis.
• All memory tests pass but repeated dumps name one driver: Return to the driver-specific writeup.
• 0x124 persists at defaults: Analyze WHEA records; do not assume RAM.
• Windows files remain corrupt after hardware stabilization: Repair them only now, then verify they remain clean.

• Do not increase memory, SoC, or CPU voltage as a generic repair.
• Do not call a single quick pass conclusive.
• Do not test multiple changing variables at once.
• Do not mix DIMMs or slots without labeling each configuration.
• Do not keep reinstalling Windows while memory is demonstrably unstable.
• Do not update firmware during severe power or memory instability unless the vendor's recovery procedure specifically requires it.

Restore the photographed firmware settings only after the hardware is proven stable, and do not restore the setting that reproduced errors. Reinstall the original module population only if it passes the controlled tests. Windows file repairs roll back through the verified system image or backup, not by restoring corrupt files.

• Firmware detects the expected memory amount on every cold start.
• XMP/EXPO remains off unless a later deliberate stability test proves it.
• Extended memory testing completes without errors in the final configuration.
• Windows starts normally multiple times and survives a cold start and representative workload.
• No new changing-module bug checks or checksum failures occur.
• DISM/SFC remains clean after memory is stable.
• The module/slot test matrix is retained.

Confidence is high when errors reproducibly follow one module or disappear at documented defaults. It is moderate when only one Windows memory test reports an error without isolation. Stop physical testing when memory is soldered, access would void or risk the system, all modules fail unpredictably, independent media crashes, or power/thermal instability is present.