Windows 10 Windows 10 IoT Enterprise LTSC 2021 - "Bad System Config Info" BSOD After Power Outage

Discover

Member
Joined
Jan 29, 2026
Messages
4
I’m currently facing a boot issue with a virtual machine running Windows 10 IoT Enterprise LTSC 2021 on VMware Workstation.

The problem started after a sudden power outage caused the host PC to shut down unexpectedly. Since then, the virtual machine fails to boot and displays a "Bad System Config Info" blue screen error.

At the moment, the VM is unable to boot into Windows. It either gets stuck in a boot loop or automatically enters the Windows Recovery Environment. Attempting Automatic Repair does not resolve the issue.

Troubleshooting steps I have tried so far:
  • Restarting the virtual machine multiple times
  • Running Automatic Repair from the recovery environment
Unfortunately, the issue still persists.

Based on my understanding, this error may be caused by corrupted system files, damaged Boot Configuration Data (BCD), or registry issues-possibly due to the improper shutdown during the power outage.

System details:
  • Environment: VMware Workstation (Guest OS)
  • OS: Windows 10 IoT Enterprise LTSC 2021
  • Error: "Bad System Config Info" (BSOD)
  • Trigger: Sudden power outage / improper shutdown
I would greatly appreciate any advice or recommended troubleshooting steps, especially:
  • How to repair BCD or registry via Command Prompt in recovery mode
  • Any reliable way to recover the system without performing a full reinstall
  • Whether this type of issue is common after an unexpected shutdown in a virtual machine
  • Any additional diagnostic steps to identify the root cause
Thank you in advance for your help!
 
Hi,
Yes — a sudden power loss can absolutely cause this, even in a VM. From your description, the most likely causes are:
  • NTFS/file-system corruption inside the guest
  • damaged BCD / boot files
  • corrupted SYSTEM registry hive or related registry data
  • less commonly, corruption in the virtual disk files on the host
The good news is that this does not always require a reinstall.

First: protect the VM before trying repairs​

Because the VM is already in a bad state, I strongly recommend:
  • Power the VM off completely
  • Make a copy of the entire VM folder on the host first
    • .vmx
    • .vmdk
    • any split VMDK segments
    • .nvram
  • If possible, work on the copy
That gives you a rollback point in case a repair attempt makes things worse.

Recommended repair order​

1) Open Command Prompt in WinRE​

From the Windows Recovery Environment:
Troubleshoot > Advanced options > Command Prompt

2) Identify the Windows and EFI/System partitions​

Drive letters in WinRE are often different from normal boot.
Run:
Code: 
diskpart
list vol
exit
Look for:
  • the Windows partition: usually NTFS, largest partition, contains Windows
  • the EFI partition on UEFI systems: usually FAT32, often 100–300 MB
You can test a drive letter with:
Code: 
dir C:\
dir D:\
dir E:\
Keep note of:
  • Windows partition, for example: C:
  • EFI partition, for example: S:

3) Check the file system first​

Because the crash followed a power outage, this is the first real repair step.
If your Windows partition is C:, run:
chkdsk C: /f
If it reports a lot of errors, or you suspect deeper corruption, run:
chkdsk C: /r
Notes:
  • /f repairs logical file-system errors
  • /r is more thorough and takes much longer
If chkdsk finds and fixes errors, reboot once and test before doing more.

4) Repair offline system files​

If the VM still will not boot, run offline SFC:
sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows
If your Windows folder is on another letter, adjust accordingly.

5) Rebuild boot files / BCD​

This is usually more reliable than only using bootrec.

If the VM uses UEFI​

Assign a letter to the EFI partition if needed:
Code: 
diskpart
list vol
select vol <EFI volume number>
assign letter=S
exit
Then rebuild boot files:
bcdboot C:\Windows /s S: /f UEFI

If the VM uses Legacy BIOS / MBR​

Use:
bcdboot C:\Windows /f BIOS

Optional additional boot commands​

After that, you can also try:
Code: 
bootrec /scanos
bootrec /rebuildbcd
If bootrec /fixboot returns Access is denied, that is fairly common. In that case, rely on bcdboot instead.

If “Bad System Config Info” still continues​

This stop code is often tied to registry corruption, especially the SYSTEM hive.

6) Check whether RegBack contains usable registry backups​

Run:
dir C:\Windows\System32\Config\RegBack
If the files there are non-zero size, you may be able to restore them.

Back up current hives first​

Code: 
md C:\HiveBackup
copy C:\Windows\System32\Config\SYSTEM C:\HiveBackup\
copy C:\Windows\System32\Config\SOFTWARE C:\HiveBackup\
copy C:\Windows\System32\Config\SAM C:\HiveBackup\
copy C:\Windows\System32\Config\SECURITY C:\HiveBackup\
copy C:\Windows\System32\Config\DEFAULT C:\HiveBackup\

Then restore from RegBack​

Code: 
copy C:\Windows\System32\Config\RegBack\SYSTEM C:\Windows\System32\Config\
copy C:\Windows\System32\Config\RegBack\SOFTWARE C:\Windows\System32\Config\
copy C:\Windows\System32\Config\RegBack\SAM C:\Windows\System32\Config\
copy C:\Windows\System32\Config\RegBack\SECURITY C:\Windows\System32\Config\
copy C:\Windows\System32\Config\RegBack\DEFAULT C:\Windows\System32\Config\
Then reboot and test.

Important note​

On newer Windows 10 builds, RegBack is often empty or not automatically populated, so this method only works if those files actually contain data.

Useful diagnostics from WinRE​

7) Read the Automatic Repair log​

This can sometimes point to the exact failure:
type C:\Windows\System32\LogFiles\Srt\SrtTrail.txt

8) Inspect current BCD entries​

bcdedit /enum all
If the Windows path or device entries are obviously wrong, that supports a BCD issue.

Additional recovery options before reinstalling​

9) Try System Restore​

If restore points exist:
Troubleshoot > Advanced options > System Restore
This is often one of the safest ways to recover from registry/boot damage.

10) Attach the VMDK to another working VM​

If in-guest repair fails, a very practical VMware option is:
  • create a second working Windows VM
  • attach the broken VM’s VMDK as a secondary disk
  • copy important data off it
  • inspect the Windows folder
  • run offline checks from the helper VM
This is often the best “no reinstall” path if the original guest will not recover cleanly.

Is this common after an unexpected shutdown in a VM?​

Yes. It is not unique to VMware.
A VM is still running a real NTFS file system and real Windows registry hives inside a virtual disk. If power is cut during writes, you can get:
  • dirty NTFS metadata
  • incomplete registry hive writes
  • damaged BCD
  • pending update/servicing corruption
So this kind of failure is entirely plausible after a host power outage.

My suggested sequence for your case​

If I were repairing this VM, I would do it in this exact order:
  1. Clone the VM folder
  2. Boot to WinRE Command Prompt
  3. Identify correct letters with diskpart
  4. Run:
    chkdsk C: /f
  5. Run:
    sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows
  6. Rebuild boot files with:
    bcdboot C:\Windows /s S: /f UEFI
    or
    bcdboot C:\Windows /f BIOS
  7. Reboot and test
  8. If still failing, inspect SrtTrail.txt
  9. If still failing, check RegBack
  10. If still failing, mount the VMDK on another VM and recover data / continue offline repair

One caution specific to VMware​

If multiple VMs or files were affected on the host after the outage, also check the host disk and host file system. Sometimes the guest is only part of the problem, and the actual damage happened to the .vmdk or host storage layer.
If you want, I can give you a clean step-by-step command set for either UEFI or Legacy BIOS, depending on how this VMware guest was configured.
 
On my side:
  1. bootrec /fixboot returns Access is denied
  2. Step 6: C:\Windows\System32\Config\RegBack - Folder Empty
 
That narrows it down quite a bit.
  • bootrec /fixboot returning “Access is denied” is a very common outcome in modern recovery scenarios and does not by itself mean the VM is unrecoverable. In similar boot-repair discussions, the next step is usually to stop relying on fixboot and rebuild boot files with bcdboot after confirming the correct system partition.
  • An empty C:\Windows\System32\Config\RegBack means the easy registry-hive rollback path is unavailable, so I would shift focus away from registry restore and toward disk/file-system checks + boot-file reconstruction. Older recovery advice often uses RegBack successfully, but that depends on those backups actually existing.

What I would do next​

1) Confirm whether the VM is UEFI or Legacy BIOS​

In VMware Workstation, this matters a lot.
  • If the VM was installed as UEFI/GPT, the important partition is the small FAT32 EFI System Partition
  • If it was installed as BIOS/MBR, the repair path is different
If you’re not sure, from WinRE Command Prompt run:
Code: 
diskpart
list disk
select disk 0
list part
list vol
exit
Clues:
  • A small FAT32 partition usually means UEFI
  • An EFI System Partition strongly suggests UEFI
  • No EFI partition + active NTFS system partition usually means Legacy BIOS
This kind of partition check is repeatedly emphasized in boot-repair threads because drive letters and boot partitions in recovery mode are easy to misidentify.

2) Run CHKDSK first if you have not already​

Because the trigger was a hard power loss, file-system corruption is still one of the most likely causes.
If Windows is on C:, run:
chkdsk C: /f
If it reports significant corruption, follow with:
chkdsk C: /r
If CHKDSK repairs errors, reboot once and test before doing more.

3) Rebuild boot files with BCDBOOT instead of fighting bootrec /fixboot​

This is the main next move.

If the VM is UEFI​

Use DiskPart to assign a letter to the EFI partition, for example S::
Code: 
diskpart
list vol
select vol <EFI volume number>
assign letter=S
exit
Then rebuild boot files:
bcdboot C:\Windows /s S: /f UEFI
If your Windows folder is actually on D: or another drive in WinRE, replace C: accordingly.

If the VM is Legacy BIOS / MBR​

Use:
bcdboot C:\Windows /f BIOS
or, if you identify the system partition explicitly:
bcdboot C:\Windows /s C: /f BIOS
The reason I’d prioritize bcdboot is that it is specifically used to copy fresh boot files from the Windows directory and recreate the boot environment/system partition, which is exactly the failure pattern you’re describing.

4) If bcdboot fails, verify you are targeting the correct Windows install​

A classic failure pattern is running repair commands against the wrong partition. In older cases, users saw fixboot/rebuildbcd fail simply because they were not actually pointed at the real Windows partition.
Check with:
Code: 
dir C:\Windows
dir D:\Windows
dir E:\Windows
Whichever one clearly contains the installed OS is the one to use with bcdboot.

5) Also dump the current boot configuration and repair log​

These are high-value diagnostics now:
Code: 
bcdedit /enum all
type C:\Windows\System32\LogFiles\Srt\SrtTrail.txt
If C: is not the Windows volume in WinRE, adjust the drive letter.
This can tell you whether:
  • the boot entry points to the wrong partition
  • the OS loader path is broken
  • Automatic Repair is failing on a specific file or registry step

About the old bootsect /nt60 sys workaround​

You may run into old advice suggesting bootsect /nt60 sys before retrying bootrec /fixboot; that workaround does appear in older forum material.
However, in your case I would not jump to that first unless you confirm the VM is Legacy BIOS/MBR.
Why:
  • on UEFI systems, the cleaner route is usually to repair the EFI partition with bcdboot
  • bootsect is more relevant to BIOS/MBR-style boot code repair
So I’d treat bootsect as a BIOS-only fallback, not the primary next step.

If it still won’t boot after bcdboot​

At that point I would try this order:
  1. Offline SFC
    sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows
    Adjust letters as needed.
  2. System Restore from WinRE, if restore points exist
  3. Mount the VMDK in another VM and copy data out before more invasive repair
  4. If the VM remains unbootable, consider an in-place repair install or reinstall after backup

My practical recommendation for your exact situation​

Since:
  • fixboot is denied
  • RegBack is empty
  • the issue began after abrupt power loss
I would now focus on this exact sequence:
Code: 
diskpart
list vol
exit
Identify:
  • Windows partition
  • EFI/system partition
Then:
chkdsk <WindowsDrive>: /f
Then, for UEFI:
Code: 
diskpart
select vol <EFI volume>
assign letter=S
exit
bcdboot <WindowsDrive>:\Windows /s S: /f UEFI
Or for BIOS:
bcdboot <WindowsDrive>:\Windows /f BIOS
Then reboot and test.
If you want, reply with the output of:
Code: 
diskpart
list vol
and I can tell you exactly which bcdboot command to run for your VM.
 
Thanks — DISM Error: 87 usually means DISM does not like the command syntax or one of the parameters, rather than proving the image is beyond repair.
In your case, there are 3 likely causes:
  • the Windows partition is not actually C: in WinRE
  • the command needs a matching install source instead of relying on local component store repair
  • there is a syntax/parameter issue in the exact command entered
Older WindowsForum repair examples also show that when plain RestoreHealth fails, the next successful step is often to point DISM at a mounted ISO using /Source:WIM:... /LimitAccess.

Try this in order​

1) Confirm the real Windows drive letter in WinRE​

Run:
Code: 
dir C:\Windows
dir D:\Windows
dir E:\Windows
dir F:\Windows
Use the drive letter that actually shows your offline Windows installation.
Do not assume it is C: in recovery mode. Boot-repair guidance regularly stresses that WinRE drive letters can differ from normal boot.

2) Test simpler DISM commands first​

If your Windows folder turns out to be on D:, try:
Code: 
dism /Image:D:\ /Cleanup-Image /CheckHealth
dism /Image:D:\ /Cleanup-Image /ScanHealth
If these also return Error 87, then the issue is probably:
  • wrong path
  • unsupported parameter in the environment you booted from
  • bad copy/paste syntax

3) Use a matching Windows ISO as the repair source​

This is the most important next step.
Mount or boot from matching media for:
  • Windows 10 IoT Enterprise LTSC 2021
  • same architecture
  • same language
  • as close a build as possible
Then identify the media letter, for example X: or E:.

If the ISO contains install.wim​

First list indexes:
dism /Get-WimInfo /WimFile:E:\sources\install.wim
Then run:
dism /Image:D:\ /Cleanup-Image /RestoreHealth /Source:WIM:E:\sources\install.wim:1 /LimitAccess

If the ISO contains install.esd​

First list indexes:
dism /Get-WimInfo /WimFile:E:\sources\install.esd
Then run:
dism /Image:D:\ /Cleanup-Image /RestoreHealth /Source:ESD:E:\sources\install.esd:1 /LimitAccess
The /Source:WIM:... /LimitAccess pattern is the same approach shown in WindowsForum examples when RestoreHealth fails without a usable source.

4) Make sure the index matches your edition​

If the image has multiple indexes, choose the one that matches your installed edition.
For IoT Enterprise LTSC 2021, using the wrong index can cause repair failure even if the file exists.

5) If you still get Error 87, check for these exact problems​

Use plain keyboard characters only​

Re-type the command manually if possible.
Sometimes copied commands use:
  • smart dashes
  • hidden characters
  • broken spacing

Make sure the parameter format is exact​

Use this exact style:
dism /Image:D:\ /Cleanup-Image /RestoreHealth /Source:WIM:E:\sources\install.wim:1 /LimitAccess

Verify the source file exists​

Run:
Code: 
dir E:\sources\install.wim
dir E:\sources\install.esd

Important point​

For this boot problem, I would not rely on DISM alone.
Because your issue started after a sudden power loss, the highest-value repairs are still:
  1. chkdsk
  2. bcdboot
  3. then DISM/SFC if needed
So if you have not yet run bcdboot successfully, that is still a priority.

What I recommend next​

Please post the output of these commands:
Code: 
dir C:\Windows
dir D:\Windows
dir E:\Windows
diskpart
list vol
exit
dir E:\sources
With that, I can tell you the exact DISM command and the exact bcdboot command for your VM.
 
You must log in or register to reply here.

Similar threads

  • Article Article
Windows 10 IoT Enterprise LTSC 2021: Support Through 2032 Explained
Replies
0
Views
215
ChatGPT
K
  • Solved
Windows 8 Bad System Config Info on start up
Replies
1
Views
5K
Josephur