Windows won't boot but the disk is fine: rebuilding the EFI bootloader with diskpart and bcdboot

Two dead laptops landed on my bench this month with the same story. Power on, vendor logo, then "Boot Device Not Found", or just a black screen. Both drives were healthy, and every file the owners cared about was sitting right there when I mounted the disks from a USB stick.

Windows didn't lose the data. It lost the small partition that tells the firmware where Windows lives.

It's a FAT32 partition called the EFI System Partition, and it has no drive letter. Nobody notices until a cloning tool skips it, an image restore drops it, or a resize eats it. Then the machine looks bricked while it's completely fine underneath.

Here's the fix I use. Fifteen minutes, and nothing you run here touches your files.

What actually boots a Windows PC

The firmware doesn't go hunting for Windows. It reads a boot entry out of NVRAM and loads a file called bootmgfw.efi from the EFI System Partition (ESP for short). Microsoft's partition docs put it plainly: the device must contain a system partition, and on GPT drives that's the ESP, formatted FAT32.

Two separate things can break: the files inside the ESP, and the firmware's memory of where the ESP is. Most of the "but bcdboot said it worked" cases I've run into are the second one.

Three checks before you type anything

1. Is the drive visible in firmware setup at all? If your SSD isn't in the BIOS or UEFI storage list, stop. That's hardware, a cable, or a storage-mode change like RAID versus AHCI. Not a bootloader problem, and nothing below will help.
2. Is the firmware in UEFI mode or legacy/CSM? A GPT disk won't boot through CSM on its own. Microsoft's Secure Boot guidance says it plainly: to use a CSM you may also need to reformat the drive as MBR and reinstall Windows. If a CMOS battery swap reset your board to legacy mode, you just found your answer.
3. Is BitLocker on? Find the recovery key before you touch boot files, because changing them can trigger a recovery prompt on the next boot.

Get to a command prompt in WinRE

Two routes:

• From inside Windows: Settings > System > Recovery > Advanced startup > Restart now, then Troubleshoot > Advanced options > Command Prompt. Holding Shift while you click Restart from the power menu also works.
• From a USB stick: boot Windows install media, choose Repair your computer, then Troubleshoot > Advanced options > Command Prompt.

The X: drive you land on is the recovery environment's RAM disk, not your Windows install. Your Windows volume is somewhere else, often with no letter assigned.

Find the two partitions you care about

diskpart
list disk
select disk 0
list volume
exit

You want two entries: a big NTFS volume (Windows) and a small FAT32 volume with no letter, usually 100 to 300 MB. That small one is your ESP.

Mount them with letters so the next commands have something to talk to:

diskpart
select volume 3
assign letter=S
select volume 4
assign letter=W
exit

Use the volume numbers you actually saw, not mine. Then check what you're looking at before writing:

dir S:\EFI\Microsoft\Boot
dir W:\Windows\System32

If dir W:\Windows answers with File Not Found, you picked the wrong volume. Go back to list volume. Guessing here is how people end up wiping the wrong partition.

Rebuild the boot files

bcdboot W:\Windows /s S: /f UEFI

Expect Boot files successfully created. That means bcdboot copied a fresh set of boot files from your Windows install onto the ESP and built a new BCD store there. It's the documented repair path: Microsoft describes bcdboot as the tool for repairing a corrupted system partition by recreating those files from the Windows partition.

Why it can still refuse to boot

This is the detail I wish someone had handed me years ago. Per the bcdboot docs: by default, bcdboot adds a firmware entry in NVRAM pointing at the Windows Boot Manager and puts it first in the boot list. But if you use the /s option, that NVRAM entry is not created. bcdboot then relies on the firmware's default behavior, which by the UEFI 2.3.1 spec should open \efi\boot\bootx64.efi from the ESP.

So bcdboot can print success while your firmware still points at a stale entry from an old disk or a cloning tool. Two things fix that.

First, give the firmware the fallback path it's looking for. Your ESP is already mounted:

mkdir S:\EFI\Boot
copy S:\EFI\Microsoft\Boot\bootmgfw.efi S:\EFI\Boot\bootx64.efi

Then reboot into firmware setup and move "Windows Boot Manager" to the top of the boot order. From WinRE, bcdedit /enum firmware shows the firmware entries, and running bcdboot again without /s lets it create the NVRAM entry itself. Be careful with that one if the machine has more than one ESP, since without /s you're trusting it to pick the right disk.

If Secure Boot is in the picture, test one boot with it disabled to see whether the bootloader is even the problem, then turn it back on. Don't leave it off.

When the BCD store itself is missing

bootrec /scanos
bootrec /rebuildbcd

/scanos looks for Windows installations, /rebuildbcd builds a store from whatever it finds. The older /fixboot often just answers "Access is denied" on UEFI machines. I can't point you to an official page for that one, it's what I keep seeing, and my read is there's no legacy boot sector left for it to rewrite. Once bcdboot has written the ESP files you usually don't need bootrec.

What can't hurt your data, and what can

Safe, because none of these writes to your files: diskpart list, select, assign, bcdboot, bootrec, bcdedit. Assigning a letter just puts a name on a volume that already exists.

Never a first move: diskpart clean, format, convert gpt, deleting volumes. If the drive is clicking, or the files matter more than the machine boots, clone it and repair the clone.

The short version

USB stick, command prompt, diskpart to find the FAT32 ESP and the Windows volume, bcdboot W:\Windows /s S: /f UEFI, copy bootmgfw.efi to \EFI\Boot\bootx64.efi, set the boot order. That's the whole job.

I've only done this on straight UEFI and GPT single-disk machines, so your mileage will vary on RAID, Storage Spaces, or a legacy/MBR setup. And if the firmware can't see the drive at all, the hardware comes first. But for the "bricked" laptop with a perfectly good disk...... this one has saved me a reinstall more than once.