1usmus
patreon
Recommended BIOS options to reduce Zen 5 hard-freezes under overclocking
🕑 Added 2025-11-16 08:18:42 +0000 UTCOn many Zen 5 desktop systems, an unstable overclock can result in a complete system freeze with no BSOD, no WHEA error and no automatic reboot.
The BIOS settings below are aimed at:
Letting the platform detect serious Data Fabric / SMU faults faster
Converting them into a reset or WHEA bugcheck instead of a silent deadlock
Disabling some deep power-saving features that can interact badly with high clocks and voltages
These options do not make an unsafe overclock “safe”, but they can make instability easier to catch and debug.
Recommended profile (AMD CBS menu)
Platform First Error Handling = Disabled
SMU and PSP Debug Mode = Disabled
Power Supply Idle Control = Typical Current Idle
Disable DF to external downstream IP Sync Flood Propagation = Sync flood enabled
Disable DF sync flood propagation = Sync flood enabled
Freeze DF module queues on error = Enabled
DF Cstates = Disabled
Option-by-option explanation
Platform First Error Handling = Disabled
This option controls who handles certain hardware errors first: the platform firmware (“platform first”) or the operating system.
With Platform First enabled, some PCIe / bus / RAS errors may be swallowed or mishandled by firmware, which can sometimes end up as a silent freeze under heavy overclock.
With Platform First disabled, more responsibility is pushed to the OS (WHEA on Windows), which tends to result in a visible WHEA error, BSOD, or reboot instead of a complete system lock.
Goal: Prefer a clean bugcheck or reset over a system that simply stops responding with no logs.
SMU and PSP Debug Mode = Disabled
This controls internal debug features of the SMU (System Management Unit) and PSP (Platform Security Processor).
Debug modes are useful for internal bring-up and validation, but they can change how asserts and internal errors are handled.
For daily overclocking, you want the standard, production error-handling path.
Goal: Make sure SMU/PSP behave like a retail system and do not interfere with normal watchdog / reset behavior during instability.
Power Supply Idle Control = Typical Current Idle
This setting affects how aggressively the CPU drops to very low current states at idle.
Low Current Idle can save a bit of power but is known to cause random lockups on some PSUs, especially when the CPU is heavily overclocked and rapidly jumping between idle and boost.
Typical Current Idle keeps the rails under a more stable load and avoids edge cases where the PSU briefly misbehaves at extremely low current.
Goal: Reduce random “black screen / freeze at idle or light load” that is actually a PSU + deep C-state interaction.
Disable DF to external downstream IP Sync Flood Propagation = Sync flood enabled
This controls whether a fatal Data Fabric error is propagated as a sync flood to external downstream blocks (for example, I/O IPs).
Setting “Sync flood enabled” means we allow catastrophic DF errors to propagate and trigger a global error condition.
Instead of some parts of the chip continuing to run on corrupt state, the platform treats it as fatal and can reset.
Goal: Make serious DF errors produce a hard, global fault that the system can actually respond to.
Disable DF sync flood propagation = Sync flood enabled
Similar idea, but for internal propagation of sync flood inside the Data Fabric.
“Sync flood enabled” tells the fabric to propagate that fatal condition through the whole internal network.
This again favors a deterministic reset / bugcheck over a stuck or partially-dead system.
Goal: If something goes catastrophically wrong in the fabric at high clocks, it should bring the whole system down cleanly, not leave it frozen.
Freeze DF module queues on error = Enabled
This option controls what happens to outstanding traffic in the Data Fabric once an error is detected.
With Freeze on error enabled, DF will stop its internal queues when a serious error is seen.
That increases the chances that the error-handling path (including sync flood and machine check) actually completes instead of getting lost in a storm of in-flight transactions.
Goal: Make sure DF error handling can run to completion and trigger a reset instead of hanging mid-way.
DF Cstates = Disabled
DF C-states are deep power-saving states for the Data Fabric itself.
At high fabric clocks (FCLK) and aggressive overclocks, entering and leaving deep DF power states can become a corner case.
Disabling DF C-states keeps the fabric fully awake and responsive, trading a bit of idle power for more predictable behavior.
Goal: Keep the Infinity Fabric in a stable, always-on mode during overclocking to reduce random, hard-to-reproduce lockups.
When to use these settings
You are overclocking a Zen 5 desktop CPU and see hard-freezes under load or at idle, with no WHEA logs and no automatic reboot.
You prefer a WHEA error / BSOD / reboot over a frozen system that forces a manual power-cycle.
You are okay with slightly higher idle power and temperature in exchange for cleaner error behavior.
Important notes
These options do not guarantee stability. If your voltage, clocks or memory timings are too aggressive, the system will still crash.
They simply increase the chance that an unstable configuration will fail in a visible, debuggable way instead of a silent hang.
Always combine these settings with proper stability testing (stress tests, real-world workloads) and keep in mind that every CPU and board is different.
Comments
Paolo Luppi
Hi Yuri, I recommend editing the Windows registry with two instructions and pressing two keys on the keyboard. If your PC freezes, the system reboots with an artificial BSOD without the shutdown/start or reset button. When Microsoft rolled out .NET Framework 4.8.1 to Windows 10, where the native version is 4.8 (the 4.8.1 adaptation for Windows 10 is terrible), with Hydra running two or three times a day, the system would freeze. On this webpage https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/windows-based-computer-freeze-troubleshooting, Microsoft describes the correct modification to make to the Windows registry and the keys to press to artificially release the BSOD and restart your PC. Upgrading to Windows 11 solved this problem for me (.NET Framework 4.8.1 for Windows 11 is native).
alpha54
You might have already done this so apologies for wasting your time in that case, but on my Asus mobo, none of the options were directly in the AMD CBS menu - I had to go to different sub menus for the various options. The first three were under AMD CBS\CPU Common Options, and the last three were under AMD CBS\DF Common Options. Worth having a browse thru all the sub menus just in case you didn't already do so :)
alpha54
Great stuff - v insightful - and as always I appreciate that you do such a great job explaining what the settings do and why to change them, rather than the "trust me bro" that has become so prevalent in any tech related guides these days... 👍
TomCatT
Looks like only two options out of that list above my MSI board supports.
