I disabled the AM5 BIOS setting everyone uses, and my random crashes finally stopped

Published Sep 29, 2026, 7:00 AM EDT His love of PCs and their components was born out of trying to squeeze every ounce of performance out of the family computer. Tinkering with his own build at age 10 turned into building PCs for friends and family, fostering a passion that would ultimately take shape as a career path. Besides being the first call for tech support for those close to him, Ty is a computer science student, with his focus being cloud computing and networking. He also competed in semi-pro Counter-Strike for 8 years, making him intimately familiar with everything to do with peripherals. For weeks, I had been plagued by random crashes in one of my favorite games, and nothing about my system had changed. The symptoms of these crashes would vary between full system lockups, a sudden game freeze and closure, and even BSODs. Because nothing about my system had changed, I figured it was just the game itself acting up, but then the crashing started happening during desktop tasks as well, and I knew the cause was something deeper. I suspected memory, and dropping my 64GB of DDR5 down from 6000MT/s to 5600MT/s solved the crashing, but I was giving up some performance. Months later, I had an epiphany—compared to DDR4, DDR5 tends to walk a much smaller tightrope of stability, balancing things like speed, voltage, and timings, and one of the things that helps keep things from spiraling into instability is the constant memory retraining that happens on boot. There's one setting on AM5 boards that gives you lightning-fast boot times, but sacrifices that lengthy retraining process, and it was the culprit. Memory Context Restore is the setting A great BIOS setting for lowering AM5 boot times Every time an AM5 system boots from scratch, the motherboard trains its memory. It runs a battery of read and write operations to tune signal timings and reference voltages until it finds settings the memory can reliably run at. With DDR5, especially at high capacities or with all four slots populated, that process is pretty slow, and AM5 earned a reputation for long boots early on because of it. Memory Context Restore solves that by saving the results of a successful training run after POST and uses those for later boots, skipping the retraining process entirely. This cuts boot times significantly. MCR doesn't cause bad memory training, and if the initial training result had healthy margins, you get fast boots with no downsides. For most systems and most memory configurations, it's a non-issue, but for some systems, it can be the difference between serious instability and a rock-solid system. Four sticks at 6000MT/s is actually a significant ask My system is running two different kits, too My memory setup made me a prime candidate for a marginal training result. I run two identical DDR5-6000 kits, 2x16GB each, for four DIMMs total. On AM5 that means two DIMMs per channel, which is the hardest configuration for the memory controller to drive. AMD's official spec for the 7800X3D is DDR5-5200 with two DIMMs, and just DDR5-3600 with four. Running four sticks at 6000 is well past what AMD guarantees. This is technically an overclock, even if an EXPO profile makes it a single toggle. I bought two Crucial kits of the same model instead of one 64GB kit, and this can be a factor in instability as well. Separately purchased kits can use different memory ICs or PCB revisions under the same part number, and when you combine that with the already marginal memory configuration, there's not a lot of room for error. Why memory tests passed just fine but games didn't An extended long-term test would've caught it eventually, but games stress memory in different ways Memory stress tests are where I expected to find the problem, but they all came out clean with relatively long runs. These aren't 24 hour tests, more like a few hours, but I figured that'd be long enough to weed out any potential instability. I was incorrect. One of my favorite games, Escape From Tarkov, was crashing seemingly at random. Some nights I could play without a crash, but others, it'd be every 30 minutes or so. The most likely explanation is that Tarkov's workload, which is heavy on RAM and constant asset streaming, stresses the memory in ways a test pattern doesn't. A pass in TestMem5 or OCCT is strong evidence of stability, but it isn't proof, and when dropping the speed from 6000 to 5600 fixed things, it pointed to a training margin problem rather than bad hardware or anything else. The cost: boot times I now wait around 60 seconds for my system to boot ​​​​​​​ From the time I press the power button to the time I see the Windows login screen is around 60 seconds, give or take. About five of those seconds are my Limine bootloader waiting to auto-select Windows, so the extra memory training adds somewhere around 30 seconds to a cold boot. MCR seriously sped things along, but it's not all-or-nothing here. I actually reflected for a moment on my power habits and found that I rarely shut down my computer anyway. The vast majority of the time it's either sitting on, idle, or in sleep mode. I really only wait for a cold boot when changing some settings, swapping operating systems, or returning from an extended time away. If you're running DDR5 on AM5, MCR is a setting worth taking a closer look at If you're running four sticks or mixed kits on AM5 and chasing crashes that memory tests won't reproduce, try turning off Memory Context Restore before you lower your EXPO speed. If the crashes continue, then dropping to a lower speed might be advisable, but there's always a possibility the cause isn't memory. For me, though, that one toggle was the difference between a system I couldn't trust and one I don't think about anymore, and it cost me about 25 seconds.