An unbootable Windows host is mostly a partition problem in 2026 — the legacy MBR / NTLDR class of failures has been replaced by EFI System Partition (ESP) corruption, a missing Boot Configuration Data (BCD) store, or a Bitlocker recovery path that nobody documented. The triage flow below has been refined over hundreds of recoveries and works on Server 2019, 2022, 2025 and Windows 10/11.
Table of Contents
Common symptoms
0xc000000f— boot configuration data file is missing.0xc000014c— BCD is corrupted.- Endless "automatic repair could not repair your PC" loop.
- UEFI firmware shows no Windows Boot Manager entry.
Boot into the recovery environment
The recovery environment (WinRE) gives you the command prompt you need. Three ways in: bootable Windows install media, the F11 menu on most OEM hardware, or three forced power-cycles in a row (Windows triggers WinRE on the third failed boot).
Enumerate the BCD
From the WinRE command prompt:
diskpart
list disk
list vol
exit
bcdedit /enum all
bcdedit /enum {default}Take a photo of the output. The two key entries are {bootmgr} (the Windows Boot Manager) and {default} (the OS loader). If {bootmgr} shows device partition=\Device\HarddiskVolumeN with no actual file, the ESP is the problem.
Inspect the EFI System Partition
diskpart
select disk 0
list partition
select partition 1 (the ESP - usually 100 MB FAT32, type System)
assign letter=S
exit
dir S:\EFI\Microsoft\BootYou should see BCD, bootmgfw.efi, and a Fonts directory. Missing bootmgfw.efi = ESP is gone, rebuild required.
Rebuild BCD safely
bcdboot C:\Windows /s S: /f UEFI /l en-USThis single command rewrites the BCD store on the ESP, copies bootmgfw.efi, registers the OS loader and points {bootmgr} at it. Reboot. 80% of EFI-class boot issues are fixed by this command alone.
If that fails:
bootrec /scanos
bootrec /rebuildbcdBitlocker considerations
If the system drive is Bitlocker-encrypted, WinRE will prompt for the recovery key the first time you read it. Have the key ready before you start. Without it the rebuild path is "save user data with a Linux live CD then reinstall".
manage-bde -unlock C: -RecoveryPassword 123456-...
manage-bde -status C:When to reach for SFC / DISM
If the host boots but with errors:
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannowFrom WinRE (offline):
DISM /Image:C:\ /Cleanup-Image /RestoreHealth /Source:WIM:E:\sources\install.wim:1
sfc /scannow /offbootdir=C:\ /offwindir=C:\WindowsPost-recovery checklist
- BCD store contains
{bootmgr}and{default}, both pointing to the right partitions. - UEFI firmware shows a "Windows Boot Manager" entry first.
- Bitlocker recovery key is documented in the IT password vault.
- System restore point taken before rebooting into normal mode.
- Event log Source = "Microsoft-Windows-Bootmgr" reviewed for the next 24h.
UEFI, Secure Boot and the BCD store on modern hardware
BCD on a UEFI system lives on the EFI System Partition (ESP), not on the Windows partition. The recovery commands you remember from BIOS-era machines (bootrec /fixmbr) are noise here — sometimes harmless, sometimes destructive. Knowing the firmware mode of the box you are repairing is step zero.
Identify the firmware mode before touching anything
# From any Windows session
$Env:firmware_type
# UEFI -> ESP-based BCD
# Legacy -> MBR-based BCD on the system reserved partition
# From WinRE / WinPE
bcdedit /enum {bootmgr}
# look for path \EFI\Microsoft\Boot\bootmgfw.efi -> UEFI
# look for path \bootmgr -> Legacy
Rebuild the BCD on UEFI without losing existing entries
bcdboot is the supported tool for UEFI systems. It copies the current Windows boot files to the ESP and recreates the BCD store, preserving any existing dual-boot entries that are still valid.
REM Mount the ESP as drive S: (assuming Windows is on C:)
diskpart
list disk
select disk 0
list partition
select partition 1 REM the EFI System Partition
assign letter=S
exit
bcdboot C:\Windows /s S: /f UEFI /v
If bcdboot reports "Failure when attempting to copy boot files", the ESP is full or corrupt. Format with format S: /fs:fat32 /q and re-run.
Secure Boot interactions you actually hit
If Secure Boot is enabled and the bootloader signature does not validate, the firmware refuses to launch the OS — no error, just a dropback to the firmware menu. After repairing the BCD always confirm:
Confirm-SecureBootUEFI # True = on, False = off
Get-ComputerInfo | Select BiosFirmwareType, OsArchitecture
If Secure Boot is on and the system still loops at boot, the most common cause is a third-party bootloader (Linux GRUB, certain hypervisors) whose certificate is not in the firmware's allowed-list. Either enrol the certificate or temporarily disable Secure Boot to confirm.
Common pitfalls
- Running
bootrec /fixmbron a UEFI system. Harmless on UEFI but solves nothing — wastes time during an outage. - Editing the BCD on the wrong drive. WinPE assigns drive letters non-deterministically. Always confirm with
dir C:\Windowsbeforebcdedit /set. - Recreating the BCD with default settings on a BitLocker volume. The TPM unseal binds to the boot configuration. Recreating the BCD requires the recovery key on next boot — have it ready.
- Forgetting the WinRE entry. A clean
bcdbootrebuild does not always restore the WinRE entry. Re-register withreagentc /enableafter the OS boots. - Trusting WinPE's
chkdskoutput. A clean chkdsk on the system drive is necessary but not sufficient; a corrupt BCD lives outside the file systemchkdskwalks.
A 30-minute BCD repair runbook for the on-call engineer
An unbootable Windows server at 3 a.m. is not the moment to be reading documentation. The runbook below assumes a UEFI host, BitLocker on, recovery key accessible, and a Windows installation USB at the console.
- Minute 0–5 — boot WinRE. Insert the USB, force-boot from it (firmware menu, usually F12). Choose "Repair your computer" → "Troubleshoot" → "Command Prompt".
- Minute 5–10 — identify drives.
diskpart→list disk→select disk 0→list partition. Note the EFI System Partition (FAT32, ~100 MB), the recovery partition, and the Windows OS partition. Assign letters:S:for ESP,R:for recovery,C:for Windows. Exit diskpart. - Minute 10–15 — unlock BitLocker.
manage-bde -unlock C: -RecoveryPassword <48-digit-key>. Without this, the next step writes to an encrypted volume and silently corrupts. - Minute 15–20 — rebuild BCD.
bcdboot C:\Windows /s S: /f UEFI /v. The verbose output should report "Boot files successfully created". Any error here means the ESP is full or the OS partition is unreadable. - Minute 20–25 — verify the WinRE entry.
bcdedit /enum {bootmgr}shows the boot manager.bcdedit /enum {default}shows the OS loader. Both should reference C: with sensible paths. - Minute 25–30 — reboot and validate. Remove the USB. Reboot. Confirm the OS reaches the lock screen. From a privileged PowerShell, run
reagentc /enableto re-register WinRE for next time.
If the server fails to reach the lock screen, the issue is not the BCD — it is the OS image, the disk, or a driver. Common follow-up commands: chkdsk C: /f from WinRE, sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows, and as a last resort DISM /Image:C:\ /Cleanup-Image /RestoreHealth /Source:WIM:<USB>\sources\install.wim:1.
Document the recovery key location before the outage. The most embarrassing IR conversation is "we have the runbook, but the recovery key is in BitLocker on the SCCM server which is also down".
Building boot resilience into the fleet
An unbootable server is always solvable, but the time to solve it ranges from twenty minutes (when the runbook is current and the recovery key is at hand) to several hours (when neither is true). The difference is preparation, and preparation is a fleet-level discipline more than an individual skill.
Start with BitLocker recovery key escrow. Every encrypted device should escrow its key to Active Directory or Microsoft Entra automatically, and the escrow should be verified weekly. A key in escrow that nobody can locate is no key at all. Spot-check the escrow by picking three random hosts each Friday and confirming an admin can retrieve the key in under five minutes. The first failed spot-check is when you discover the escrow has been silently broken for months.
Maintain a standardised recovery USB per environment. The USB image contains the matching Windows version (no Win10 USB to recover a Server 2022 host), the storage drivers for any non-trivial RAID controllers, and a small toolkit folder with sfc, dism, chkdsk, and a copy of the runbook in plain text. Refresh the image every quarter to track patch level and driver updates. The on-call engineer should never spend an outage downloading and burning media.
Document the boot-order standards. Every server in the fleet should have a known firmware boot order: internal disk first, network second, USB third. When the on-call needs to boot from USB, the override is a single F12 press, not a tour through the firmware menu trying to find the right list. Document the firmware password, store it in the same vault as the BitLocker keys, and rotate annually.
Rehearse the runbook quarterly on a non-production host. Pick a server, force-corrupt the BCD with bcdedit /delete {default}, and time the on-call team's recovery. The first rehearsal almost always reveals a gap — the recovery key is not where the runbook claims, the USB driver is missing, the firmware password has rotated. Each rehearsal closes a gap permanently.
Boot recovery is the kind of capability you only need at 3 a.m. and only need rarely. The investment in resilience does not pay off most weeks, and pays for itself many times over the week it does.
FAQ
What if there is no ESP at all?
diskpart can create one (create partition efi size=200) and bcdboot will populate it.
Does this work on dual-boot?
Yes — bcdedit can have multiple OS loader entries. Add Linux via the {bootmgr} menu only after the Windows entry boots cleanly.
What about Server Core?
Identical commands. The graphical recovery wizard is missing; use the command prompt path above.
Where is the BCD store on a UEFI system exactly?
S:\EFI\Microsoft\Boot\BCD after you mount the ESP. It is a registry hive — bcdedit is the supported editor; do not modify it with regedit.
Can I boot a Windows ISO without burning media?
Yes — write the ISO to a USB stick with the built-in diskpart + bootsect, or use the Windows Media Creation Tool. For UEFI-only systems, format the stick FAT32 and copy the ISO contents directly.
What is the difference between WinRE and WinPE?
WinRE is the recovery environment shipped with Windows (winre.wim). WinPE is the underlying preinstall environment used by enterprise tooling and bootable repair media. The repair commands work in both.
Will these steps work on Windows Server?
Yes. Server edition uses the same boot manager and BCD architecture. The only difference is that Server installations more often live on a hardware RAID; load the storage driver in WinPE before diskpart sees the volume.
