BSOD After Enabling XMP: What’s Actually Happening

What XMP actually changes (and why it’s not just frequency)

XMP (Extreme Memory Profile) is a set of parameters stored on the RAM module (in the SPD: Serial Presence Detect). When you enable XMP in BIOS/UEFI, the board reads that profile and applies it: memory frequency, primary timings (CL/tRCD/tRP/tRAS), command rate, and one or more voltages.

That sounds straightforward until you remember the rest of the system isn’t passive. Modern platforms have a memory controller inside the CPU (IMC), a BIOS “training” routine that tries to find a stable configuration at boot, and board-specific signal integrity constraints. You’re not only asking the RAM to go faster; you’re asking the entire memory subsystem to operate with tighter margins.

Key parameters XMP tends to touch

• DRAM frequency (e.g., DDR4-2133 → DDR4-3600, DDR5-4800 → DDR5-6000).
• Primary timings (CAS latency, etc.). Lower timings reduce time for signal settling and internal operations.
• DRAM voltage (e.g., 1.20V → 1.35V for DDR4; DDR5 has VDD/VDDQ and PMIC behavior that varies by kit).
• Memory controller related voltages (platform-specific): on AMD you’ll see SOC/VDDIO/CLDO VDDP; on Intel you’ll see VCCSA/VCCIO (names vary by board).
• Gear/Divider modes (Intel Gear 1 vs Gear 2; AMD ratios tied to Infinity Fabric). These affect latency and stability.
• Command rate and training behavior (1T/2T, memory context restore on AMD, “fast boot” memory training shortcuts).

When XMP is stable, it’s great: more bandwidth, lower latency, fewer bottlenecks in CPU-bound work and certain games, and faster memory-bound tasks like compilation or some analytics. When it isn’t stable, it fails in the ugliest way possible: corruption at the bit level. Which means the OS crashes in random places, apps throw nonsense exceptions, and storage can get involved if corrupted data gets written out.

One paraphrased idea from Werner Vogels (Amazon CTO) that fits reliability work: everything fails, all the time—design and operate as if it’s guaranteed. Memory overclocks aren’t exempt; they just fail more creatively.

Short joke #1: XMP is like “fast mode” on a rental car. It works until you discover the tires were also rentals.

Why BSODs happen after enabling XMP

A BSOD after enabling XMP is rarely “Windows being Windows.” It’s usually the CPU detecting a machine check condition (WHEA), the memory subsystem corrupting data, or a driver touching memory that silently flipped a bit and now points into the void.

Failure mode 1: IMC can’t handle the requested speed (even if the RAM can)

RAM vendors validate kits on a small set of platforms. Your CPU’s IMC is a silicon lottery item. Some chips run DDR4-3600 or DDR5-6000 at stock controller voltages all day. Others need more margin or won’t do it no matter how politely you ask.

Common pattern: system boots and feels fine, but under load you get WHEA errors, random reboots, or BSODs. Stress the CPU and RAM together and it falls over faster.

Failure mode 2: Board layout + DIMM population makes signal integrity worse

Two DIMMs are easier than four. One rank per channel is easier than two. Certain boards use daisy-chain routing optimized for two sticks; others use T-topology that behaves differently. DDR5 adds its own quirks, including on-module PMIC behavior and more complex training.

If you filled all slots because “more RAM is better,” you may have also bought yourself a lower stable maximum frequency. That’s not a moral failure; it’s physics.

Failure mode 3: BIOS memory training bugs or regressions

BIOS updates can fix XMP stability. They can also break it. Vendors ship new microcode, new training code, and new defaults. A previously stable profile can start failing after an update, especially on newer platforms where training is still maturing.

Failure mode 4: XMP profile itself is aggressive or misread

XMP profiles aren’t always “one size fits all.” Some kits ship profiles tuned for a specific chip family, with tight timings that are fine in a lab but borderline elsewhere. Also, boards sometimes apply extra “helpful” auto-settings (secondary/tertiary timings, voltages) that aren’t actually helpful.

Failure mode 5: Heat, power delivery, or transient behavior

DRAM and IMC stability can be temperature-sensitive. So can VRM behavior and transient droop. A system might pass a short test cold and then crash after an hour of gaming, compiling, or running VMs.

Failure mode 6: “Stable enough” until you hit the wrong instruction mix

Memory errors are statistical. You can run for days without a visible issue and then crash five minutes into a specific workload that happens to hammer a particular pattern.

That’s why anecdotal “it ran fine yesterday” evidence is worthless in memory-overclock debugging. You need logs, reproducible tests, and a method that reduces variables.

Fast diagnosis playbook (first/second/third)

This is the sequence I use when I’m trying to stop the bleeding quickly, then decide whether to keep XMP, tune it, or abandon it.

First: Determine whether the crash is memory/IMC/WHEA vs drivers

1. Check Windows Event Viewer for WHEA-Logger entries around the crash. If present, treat it as hardware instability until proven otherwise.
2. Look at the bugcheck code (e.g., WHEA_UNCORRECTABLE_ERROR, MEMORY_MANAGEMENT, IRQL_NOT_LESS_OR_EQUAL). These aren’t perfect, but they’re clues.
3. Disable XMP and retest the same workload. If stability returns, you have your smoking gun: the memory OC is involved.

Second: Reproduce with targeted stress

1. Run a memory test (Windows Memory Diagnostic is a quick screen; better tools exist, but we’ll stay practical).
2. Run a CPU+RAM load (compilation, compression, or any deterministic workload). If it fails fast, you can iterate quickly.

Third: Choose a stabilization strategy

1. Update BIOS if you’re on an early revision or known-bad release. But don’t update blindly mid-incident if you can’t recover quickly.
2. Reduce frequency one step (e.g., DDR4-3600 → 3466/3200, DDR5-6000 → 5600). This is the highest impact / lowest risk change.
3. Relax timings slightly or increase DRAM voltage modestly within safe ranges (and only if you know what you’re doing).
4. If you need maximum stability (workstation, storage box, VM host): run JEDEC defaults or a conservative profile you’ve validated with long tests.

Interesting facts and historical context (the stuff that explains today’s mess)

• XMP started as an Intel spec for storing memory overclock profiles in SPD; AMD later supported similar behavior (often marketed as DOCP/EOCP on boards).
• JEDEC defines baseline memory standards; XMP typically exceeds JEDEC voltage/timing bins, which is why it’s effectively an overclock.
• Memory controllers moved onto CPUs (mainstream beginning with AMD K8 era, Intel Nehalem era). That improved latency and bandwidth—while making IMC quality a key variable.
• DDR4 popularized 1.35V as the “OC norm” for many kits, while JEDEC defaults stayed lower—so enabling XMP often changes more than just clocks.
• DDR5 introduced on-module PMICs and more complex power and training behavior, which is part of why early DDR5 platforms had plenty of “it depends” stability stories.
• WHEA (Windows Hardware Error Architecture) exists to surface machine-check style hardware faults; WHEA-Logger events often precede or accompany memory/CPU instability.
• Command rate and rank count matter because they change electrical load and timing margin; “same frequency” can be stable with 2x16GB but unstable with 4x16GB.
• Motherboard memory QVLs exist because validation is finite; absence from the list doesn’t mean “won’t work,” but it means “you’re the test lab now.”

Hands-on tasks: commands, outputs, decisions (12+)

Below are practical tasks you can run on a Windows machine using built-in tools (plus a few generic admin commands). Each task includes: the command, what the output means, and the decision you make.

Task 1: Confirm bugcheck history in Event Viewer (quick triage)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=1001)]]" /c:3 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WER-SystemErrorReporting
  Event ID: 1001
  Level: 2
  Description: The computer has rebooted from a bugcheck.  The bugcheck was: 0x00000124 ...
Event[1]:
  Provider Name: Microsoft-Windows-WER-SystemErrorReporting
  Event ID: 1001
  Level: 2
  Description: The computer has rebooted from a bugcheck.  The bugcheck was: 0x0000001a ...

What it means: 0x124 commonly maps to WHEA hardware errors; 0x1A is MEMORY_MANAGEMENT. Both are consistent with unstable RAM/IMC.

Decision: Treat as hardware instability. Disable XMP to confirm causality, then proceed with controlled tuning.

Task 2: Pull WHEA-Logger events (hardware error smoking gun)

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-WHEA-Logger']]]" /c:5 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WHEA-Logger
  Event ID: 18
  Level: 2
  Description: A fatal hardware error has occurred.
  Reported by component: Processor Core
Event[1]:
  Provider Name: Microsoft-Windows-WHEA-Logger
  Event ID: 19
  Level: 3
  Description: A corrected hardware error has occurred.
  Reported by component: Memory

What it means: Corrected errors (ID 19) are early warnings; fatal errors (ID 18) often align with crashes. “Memory” reported is highly suggestive of RAM/IMC issues.

Decision: Stop chasing drivers. Stabilize memory: reduce frequency, relax timings, or increase controller margin.

Task 3: Check current memory speed (verify XMP actually applied)

cr0x@server:~$ wmic memorychip get speed,configuredclockspeed,manufacturer,partnumber /format:list
ConfiguredClockSpeed=6000
Speed=4800
Manufacturer=Micron
PartNumber=ABCD16G60XMP

What it means: “ConfiguredClockSpeed” indicates what the platform is trying to run. “Speed” can reflect SPD/JEDEC. If configured is high, XMP is active.

Decision: If crashes correlate with configured speed jump, back down one step and retest.

Task 4: Confirm BIOS mode and secure boot state (helps when you’re flipping settings)

cr0x@server:~$ bcdedit
Windows Boot Manager
--------------------
path                    \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI

Windows Boot Loader
-------------------
path                    \Windows\system32\winload.efi

What it means: You’re booting UEFI. That matters when BIOS updates/reset settings change boot behavior.

Decision: Before resetting BIOS to defaults to clear XMP, confirm you know your boot mode so you don’t create a second outage.

Task 5: Dump basic system info (capture before you change things)

cr0x@server:~$ systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"System Manufacturer" /C:"System Model"
OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22631 N/A Build 22631
System Manufacturer:       Micro-Star International Co., Ltd.
System Model:              MS-7Dxx

What it means: Anchors your incident report: OS build and hardware platform.

Decision: Use this to correlate with known BIOS issues and to avoid “it changed somehow” confusion later.

Task 6: List loaded drivers near crash analysis time (drivers can be victims, not causes)

cr0x@server:~$ driverquery /fo table /nh | findstr /i "nvlddmkm storport"
nvlddmkm.sys                 Display           Running
storport.sys                 SCSIAdapter       Running

What it means: GPU and storage drivers are present. Memory instability can make either look guilty.

Decision: Don’t reinstall GPU drivers as your first move if WHEA/memory errors exist. Fix memory first.

Task 7: Check disk health signals (because RAM errors can corrupt writes)

cr0x@server:~$ wmic diskdrive get status,model
Model                            Status
Samsung SSD 990 PRO 2TB           OK
WDC WD40EFRX-68N32N0              OK

What it means: This is a shallow check, but it tells you whether the system is already reporting obvious disk problems.

Decision: If status is not OK or you’ve had repeated hard resets, schedule deeper storage checks before trusting the filesystem.

Task 8: Run a filesystem check (post-crash hygiene)

cr0x@server:~$ chkdsk C: /scan
Stage 1: Examining basic file system structure ...
Windows has scanned the file system and found no problems.
No further action is required.

What it means: No detected filesystem issues in an online scan.

Decision: If errors appear, stop tuning and focus on data integrity: backups, offline repair, and minimizing further unstable operation.

Task 9: Check Windows memory diagnostics results (quick, not definitive)

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-MemoryDiagnostics-Results']]]" /c:1 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-MemoryDiagnostics-Results
  Event ID: 1202
  Level: 2
  Description: The Windows Memory Diagnostic tested the computer's memory and detected hardware errors.

What it means: If Windows’ basic diagnostic finds errors, things are very unstable.

Decision: Disable XMP immediately. If errors persist at JEDEC, suspect faulty RAM/slot/IMC and start RMA-style isolation.

Task 10: Verify crash dump configuration (so you can actually debug)

cr0x@server:~$ wmic recoveros get DebugInfoType,MiniDumpDirectory,OverwriteExistingDebugFile
DebugInfoType=7
MiniDumpDirectory=%SystemRoot%\Minidump
OverwriteExistingDebugFile=TRUE

What it means: Minidumps are enabled; you’ll have artifacts to inspect if you choose to.

Decision: If dumps are disabled, enable them before further testing. Debugging without evidence is performance art.

Task 11: Capture thermal/power hints (stability can be temperature-sensitive)

cr0x@server:~$ powercfg /energy /duration 10
Enabling tracing for 10 seconds...
Energy efficiency problems were found.
See C:\Windows\system32\energy-report.html for more details.

What it means: Not a memory tool, but it helps catch aggressive power management that can interact with instability and sleep/resume crashes.

Decision: If BSODs cluster around sleep/wake, evaluate BIOS power settings and memory context restore options.

Task 12: Confirm virtualization status (VM stacks can stress memory differently)

cr0x@server:~$ systeminfo | findstr /i "Hyper-V Requirements"
Hyper-V Requirements:      A hypervisor has been detected. Features required for Hyper-V will not be displayed.

What it means: A hypervisor is active (Hyper-V, WSL2, some security features). This can change memory pressure and timing of faults.

Decision: Reproduce with your real workload. If your crashes only happen during VM use, prioritize stability over peak memory clocks.

Task 13: Inspect recent installs/updates (don’t ignore coincident changes)

cr0x@server:~$ wmic qfe get InstalledOn,HotFixID | sort /r | more
HotFixID   InstalledOn
KB503xxxx  1/30/2026
KB503yyyy  1/14/2026

What it means: Shows recent updates. Sometimes a BSOD coincides with a patch and XMP is blamed unfairly.

Decision: If disabling XMP doesn’t restore stability, revisit updates/drivers and widen the hypothesis set.

Task 14: Check for repeated unexpected shutdowns (correlate with stress tests)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=41)]]" /c:5 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-Kernel-Power
  Event ID: 41
  Level: 1
  Description: The system has rebooted without cleanly shutting down first.

What it means: Kernel-Power 41 often follows hard resets from instability.

Decision: If these spike after enabling XMP, treat it as confirmation. Stop “testing” by crashing your system repeatedly; switch to methodical tuning.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

A team rolled out a new batch of developer workstations for CI-heavy local builds. The procurement sheet said “fast DDR5, premium kit.” Someone toggled XMP across the fleet image checklist because it felt like free performance. They assumed “advertised speed” equals “supported speed.” That assumption is the root of most XMP incidents.

The failures were weird. Not instant boot loops—those are easy. These boxes would run for hours, then crash during a compile, or while running container workloads. The bugchecks weren’t identical. Some were MEMORY_MANAGEMENT, some were IRQL_NOT_LESS_OR_EQUAL, and a few showed WHEA entries that got dismissed as “Windows noise.” Meanwhile, developers blamed the toolchain and the CI scripts, because that’s what was visibly failing.

IT swapped SSDs. Then GPUs. Then reimaged. The crashes persisted because none of those parts were the failure domain. Eventually someone correlated WHEA-Logger corrected errors with XMP being enabled and saw the pattern: certain CPU lots were simply less tolerant at the chosen memory speed, especially with two dual-rank DIMMs.

The fix was boring: a standardized, validated memory configuration—one notch below the kit’s XMP frequency—with a BIOS update and memory training defaults restored. Performance barely changed for the real workloads. Uptime did. The postmortem action item was blunt: treat XMP as an overclock that requires validation, not as a checkbox for “doing it right.”

Mini-story 2: The optimization that backfired

A small enterprise had a Windows-based file server that also hosted a couple of light VMs. Not ideal, but it existed, and it was stable. Someone noticed memory bandwidth benchmarks looked mediocre and decided to “unlock performance” by enabling XMP. Same RAM, same CPU, same everything—just a BIOS toggle.

The system didn’t crash immediately. Instead, it started throwing occasional corrected WHEA memory errors. Nobody watched the logs because the box “felt fine.” A week later, a VM booted with a corrupted application database. Then a second VM had a strange file checksum mismatch. Finally, the host hit a fatal WHEA error and rebooted mid-write.

The optimization had backfired in the most expensive way: silent corruption risk. The team got lucky—backups worked, and the scope was limited. But they lost time doing restores and validations, and the business learned a lesson about “small” changes on systems that touch data.

They reverted to JEDEC memory settings and built a rule: any performance change on storage-adjacent systems requires a soak test under representative load plus integrity checks. It was less exciting than XMP. It was also how you avoid spending weekends babysitting restores.

Mini-story 3: The boring but correct practice that saved the day

A company ran a mixed fleet of Windows workstations used for CAD and simulation. The workload was heavy, the deadlines were real, and crashes were expensive. They had a practice that sounds painfully unglamorous: every BIOS change required a short runbook, a rollback plan, and a standardized test suite with pass/fail thresholds.

When they trialed faster memory profiles, they didn’t start with “max XMP everywhere.” They picked a representative machine, updated BIOS, enabled XMP, and then ran long memory tests plus real simulation workloads while collecting WHEA logs. They also captured baseline metrics so they could answer the question, “Did this help enough to be worth it?”

During the trial, one platform showed corrected WHEA memory errors only when the GPU and CPU were both loaded. That detail mattered. Instead of arguing about whose component was “at fault,” they treated corrected errors as a red alert and backed down memory speed until the errors disappeared.

When rollout time came, they deployed the validated settings, not the marketing settings. The team avoided a slow-motion reliability incident, and the users never knew a disaster was scheduled and then quietly canceled. That’s what good operations looks like: preventing drama by being predictably dull.

Common mistakes: symptom → root cause → fix

1) Symptom: WHEA_UNCORRECTABLE_ERROR (0x124) soon after enabling XMP

Root cause: IMC instability at requested frequency/voltage; sometimes exacerbated by high temps or aggressive auto voltages.

Fix: Drop memory speed one step; update BIOS; disable “fast memory training” shortcuts; keep controller voltages within sane limits (don’t blindly overvolt).

2) Symptom: MEMORY_MANAGEMENT (0x1A) or random app crashes

Root cause: Bit errors under load; timing margin too tight; unstable secondary/tertiary timings applied by motherboard.

Fix: Keep XMP frequency but relax timings slightly, or drop frequency; consider using the less aggressive XMP profile if the kit provides multiple.

3) Symptom: IRQL_NOT_LESS_OR_EQUAL (0xA) that points at random drivers

Root cause: Memory corruption making innocent drivers look guilty.

Fix: Validate memory stability first. Only after stability is proven do driver reinstalls make sense.

4) Symptom: Boot loops or failure to POST after enabling XMP

Root cause: Training failure; board can’t train at the selected speed/timings with current DIMM configuration.

Fix: Clear CMOS; boot JEDEC; update BIOS; enable XMP then manually select a lower frequency; try two sticks instead of four.

5) Symptom: Crashes only on cold boot, but stable after reboot

Root cause: Training variance; memory context restore / fast boot skipping full training; marginal voltages at cold conditions.

Fix: Disable memory context restore (AMD) or disable “fast boot” memory training shortcuts; allow full training; slightly reduce OC.

6) Symptom: Crashes during sleep/resume or hibernate

Root cause: Power state transitions interacting with marginal memory settings; BIOS power management quirks.

Fix: Test with XMP off; then test with conservative memory settings; update BIOS; consider disabling deep sleep states if needed (last resort).

7) Symptom: “Stable” in short tests, fails during real workloads (VMs, compiles, games)

Root cause: Workload-specific access patterns; combined CPU+GPU+IO heat and transient load triggers errors.

Fix: Validate with representative workloads for hours, not minutes; treat corrected WHEA errors as instability even without BSOD.

Short joke #2: If your stability plan is “it booted once,” you don’t have a plan. You have a motivational speech for electrons.

Checklists / step-by-step plan

Checklist A: Stop the bleeding (get back to a stable system)

1. Disable XMP and boot at JEDEC defaults.
2. Confirm stability with your normal workload and at least one memory diagnostic run.
3. Check WHEA logs for corrected errors. You want “none,” not “fewer.”
4. Run filesystem checks if you hard-reset repeatedly.
5. Only then re-enable XMP for tuning, if you still want the performance.

Checklist B: Safe XMP tuning (the least reckless path)

1. Update BIOS to a stable release (not necessarily newest beta). Record the old version first.
2. Enable XMP but manually set memory frequency one step lower than the profile to establish a baseline (especially with 4 DIMMs).
3. Leave most voltages on Auto initially. Yes, Auto can be dumb, but you need one variable at a time.
4. Test for corrected WHEA during stress. Corrected errors mean you’re still not stable.
5. Only if needed: slightly relax primary timings or slightly raise DRAM voltage within safe norms for your platform/kit.
6. Soak test with representative workloads (VMs, compiles, games, renders) for multiple hours.
7. Document the final settings so you can reproduce or roll back.

Checklist C: When to give up on XMP (and feel good about it)

• If the machine stores important data and you can’t afford corruption risk.
• If you see any corrected WHEA memory errors during normal use.
• If stability requires high controller voltages that increase heat and long-term risk.
• If you’re running 4 DIMMs and need capacity more than speed.
• If the performance gain doesn’t move your real workload, not a benchmark.

Checklist D: Isolation steps if instability persists even at JEDEC

1. Reseat DIMMs; check they’re in the recommended slots.
2. Test with one DIMM at a time (rotate through sticks and slots).
3. Check for BIOS defaults that set odd voltages.
4. Inspect CPU cooler pressure and mounting; IMC issues can be aggravated by bad seating on some platforms.
5. If errors follow a stick: suspect RAM. If they follow a slot: suspect board. If they follow the CPU: suspect IMC.

FAQ

1) Is enabling XMP “safe”?

Safe-ish for hobby rigs, not something I’d enable blindly on a machine that must never corrupt data. It’s an overclock. If you run it, validate it.

2) Why does XMP work for my friend but not for me with the same RAM?

Different CPU IMC quality, different motherboard routing, different BIOS version, different DIMM ranks, and different thermals. Same kit doesn’t mean same electrical environment.

3) If I get BSODs, is my RAM defective?

Not necessarily. Most of the time, the RAM is fine at JEDEC. The unstable part is the overclocked operating point (frequency/timings/voltages). Test at JEDEC to separate “bad stick” from “bad configuration.”

4) What’s the single best fix when XMP causes crashes?

Reduce memory frequency one notch and retest while monitoring WHEA logs. Frequency reduction tends to buy stability faster than timing micro-tuning.

5) Should I increase DRAM voltage to fix XMP instability?

Sometimes, modestly, and only within sane bounds for your kit and cooling. But don’t use voltage as a universal solvent: controller-related voltages and timings can matter more, and excessive voltage can create heat and long-term risk.

6) Why do I see corrected WHEA errors but no BSOD?

Because the hardware corrected an error before Windows died. That’s not “fine.” It’s your early warning system. If corrected errors show up during normal use, treat it as instability.

7) Does BIOS updating really matter for XMP?

Yes. Memory training code and microcode updates can materially change stability, especially on newer platforms. But update with a rollback plan; BIOS updates can introduce regressions.

8) Are four sticks always worse than two for XMP?

Usually harder, yes. More electrical load, more training complexity, often a lower stable frequency ceiling. If capacity forces four sticks, accept that the stable speed may be below the kit’s XMP rating.

9) My system passes a quick memory test. Can I trust it?

No. Quick tests catch obvious failures. Marginal XMP instability often needs long runs and representative workloads to surface. Also, watch for corrected WHEA events.

10) Can unstable XMP damage my SSD or files?

It can corrupt data that gets written to disk, and repeated hard resets are rough on filesystems. It usually doesn’t “damage” the SSD hardware, but it can absolutely damage your data.

Practical next steps

If you enabled XMP and started seeing BSODs, don’t treat it like a mystery. Treat it like an incident with a known change and a small number of likely failure domains.

1. Revert to JEDEC and confirm stability. If it’s still unstable, you have a deeper hardware issue.
2. Pull WHEA and bugcheck evidence using the commands above. Corrected errors are not “fine.”
3. Choose your goal: maximum performance or maximum reliability. For anything that stores important data or runs critical work, choose reliability and sleep better.
4. If you keep XMP, tune conservatively: one step lower frequency, then test; only then adjust timings/voltage.
5. Document the final settings like you would any production change. Your future self is a different person and will not remember.

Most XMP BSODs are solvable. The trick is to stop guessing, stop swapping unrelated parts, and start operating the system like you mean it.