How to Fix the BAD_SYSTEM_CONFIG_INFO Blue Screen on Windows 11

The BAD_SYSTEM_CONFIG_INFO stop code means Windows found a problem in its configuration data, most often a corrupted registry hive or a damaged Boot Configuration Data (BCD) store. It frequently shows up after a failed update, an interrupted shutdown, or a botched software install. Because it usually strikes during boot, you will be working from the Windows Recovery Environment (WinRE) rather than the desktop. Here is the repair sequence that resolves the great majority of cases.

Key takeaways

• The error points at a corrupt registry or broken BCD, not a single failed app.
• Many cases are cleared by a simple restart or by repairing the boot configuration.
• You will likely work from WinRE, reached by forcing three failed boots.
• CHKDSK, BCD rebuild, and registry hive restore are the core repairs, applied in that order.
• A failed update is a frequent trigger; uninstalling it or using System Restore often fixes it in one move.

Step 1: Restart and try Startup Repair

Occasionally this BSOD is a one-off from a bad shutdown.

• Restart normally once. If Windows boots, run sfc /scannow and dism /online /cleanup-image /restorehealth from an elevated prompt to clean up, and you are done.
• If it loops, force three failed boots (power off during the spinning dots) to trigger Automatic Repair, then choose Advanced options > Startup Repair.

Here is the full repair ladder so you know what each step costs and risks before you run it:

Step	What it fixes	Risk	Rough time
Restart / Startup Repair	One-off boot glitch, minor BCD damage	None	5 to 10 min
CHKDSK /f /r	Filesystem and disk errors	None to data; slow on /r	30 min to hours
Rebuild BCD	Damaged boot configuration	Low	5 min
Restore registry hives	Corrupt registry	High if drive letter is wrong	10 min
Uninstall update / System Restore	A bad quality update	None to personal files	10 to 20 min
Memory test	Failing RAM causing repeat corruption	None	Overnight

Work from the top down and stop at the first step that clears the BSOD.

Step 2: Run CHKDSK from WinRE

Disk errors corrupt the very files this stop code complains about.

1. In WinRE, open Advanced options > Command Prompt.
2. Run:

chkdsk C: /f /r

3. Let it complete (it can take a while on /r), then restart and test.

Step 3: Repair the Boot Configuration Data

A damaged BCD store is a classic cause. From the WinRE Command Prompt, run these in order:

bootrec /repairmbr
bootrec /repairbcd
bootrec /osscan
bootrec /rebuildbcd

When bootrec /rebuildbcd finds a Windows installation, type Y to add it. Restart and check whether the BSOD clears.

Step 4: Restore the registry hives

If the BCD repair did not help, a corrupt registry hive is the likely cause. Windows keeps a backup set in the RegBack folder. From the WinRE Command Prompt (confirm your Windows drive letter first, it may not be C: in WinRE):

cd C:\Windows\System32\config
ren DEFAULT DEFAULT.old
ren SAM SAM.old
ren SECURITY SECURITY.old
ren SOFTWARE SOFTWARE.old
ren SYSTEM SYSTEM.old
copy C:\Windows\System32\config\RegBack\* C:\Windows\System32\config\

Restart. If the RegBack files are 0 bytes (recent Windows builds stopped auto-populating them), this step will not help and you should use System Restore instead.

Step 5: Uninstall a recent update or use System Restore

If the BSOD began after an update, undo it.

• In WinRE, choose Advanced options > Uninstall Updates and remove the most recent quality update.
• Or choose System Restore and pick a restore point from before the crashes started. This rolls back the registry and system configuration without deleting personal files, and is often the cleanest fix when RegBack is empty. For update-specific failures, our guide to Windows 11 update error 0x800f0922 covers related boot-config repairs. If the BCD rebuild reports it cannot find the Windows installation at all, the disk may be the issue, which our Inaccessible Boot Device fix addresses.

Why the registry is so often the culprit

The registry is Windows' central configuration database, and this stop code fires when the part Windows reads early in boot does not match what it expects. The hives you rename in Step 4 each hold a different slice of that configuration: SYSTEM stores driver and service startup data, SOFTWARE holds installed-application settings, and SAM and SECURITY hold account and policy data. When an update or a bad shutdown leaves one of these inconsistent, Windows cannot trust its own configuration and halts rather than booting into an unknown state. That is also why the fix is rarely a single tool: depending on which hive is damaged and why, the right repair could be a clean re-read of the disk (CHKDSK), a rebuilt boot record (BCD), a restored hive, or a full rollback. Matching the repair to the cause is what the ordered ladder above is really doing.

Step 6: Check memory if it keeps coming back

Unstable RAM corrupts the registry as it is written, recreating the error after every repair.

Run Windows Memory Diagnostic (mdsched.exe) or, better, MemTest86 from a USB stick overnight. Any error means a failing module that must be reseated or replaced. This is the same hardware check used in our guide to the CRITICAL_PROCESS_DIED blue screen.

What to do right now

If you are staring at this BSOD, work the ladder in order and stop at the first fix that sticks:

• Restart once. A surprising share of these are one-off corruption from a bad shutdown.
• If it loops, force three failed boots to reach WinRE, then run Startup Repair.
• From the WinRE Command Prompt, run chkdsk C: /f /r and let it finish.
• Rebuild the boot config with bootrec /rebuildbcd and answer Y when it finds Windows.
• If it still fails, check whether the RegBack files are real (not 0 bytes) before restoring hives; otherwise use Uninstall Updates or System Restore.
• If the BSOD returns after every repair, test RAM with MemTest86 overnight, since failing memory re-corrupts the registry no matter how many times you fix it.

Stopping it from coming back

Once the system boots cleanly, a few habits keep this stop code from returning. Let Windows finish updates rather than forcing a power-off mid-install, since interrupted writes to the registry and BCD are the single most common trigger. Keep at least one System Restore point and, ideally, a recent full image so a future failure is a ten-minute rollback rather than a reinstall. If the machine has ever shown other configuration-related crashes, run a memory test proactively; intermittent RAM faults often surface first as a registry-corruption BSOD like this one before anything more obvious appears.

Frequently asked questions

Why does this happen right after a Windows update?

An update writes new registry and boot-configuration data. If the write is interrupted or a file is damaged, Windows reads inconsistent configuration on the next boot and throws this stop code. Uninstalling the update or restoring a pre-update point usually fixes it.

My RegBack folder is empty. Did I do something wrong?

No. Recent Windows builds no longer automatically copy hives into RegBack to save space, so the files are often 0 bytes. Skip the hive-restore step and rely on System Restore or an update rollback instead.

Can I fix this without losing my files?

Yes. CHKDSK, the BCD rebuild, hive restore, update removal, and System Restore all preserve your personal files. A full reset is the last resort, and even that offers a "keep my files" option.

What if none of the WinRE steps work?

Persistent failures after every repair usually mean failing hardware, RAM or the system drive. Test memory with MemTest86 and check the drive's SMART health. If the hardware is sound, an in-place repair install of Windows preserves files and apps while replacing the system.

Quick recap

Start with a restart and Startup Repair, then run CHKDSK and rebuild the BCD from WinRE. If the BSOD persists, restore the registry hives (only if RegBack has real files), or use Uninstall Updates and System Restore. Test RAM if the error keeps returning after every fix.