When Your Dog Destroys Your Boot Loader: An NVMe Recovery Story

A few weeks ago I finished cloning my old drive to a new NVMe. The very next day, my dog chewed through the power cord while the PC was running. Twenty four hours of enjoying the new drive.

The result: corrupted NTFS Volume Bitmap and a destroyed UEFI Boot Configuration Data (BCD). The system would POST fine but Windows refused to load. Error 0xc000000f, and built-in Startup Repair looped endlessly. If you’re reading this because you searched “NVMe boot failure” at 2AM, here’s how I fixed it — and the mistake I made during the clone that made everything worse.

The Real Problem: Lazy Cloning

When I cloned the drive with Macrium Reflect, it worked. The system booted, Windows loaded, everything seemed fine. But I didn’t rebuild the boot loader after the clone. The BCD was still pointing at the old drive’s partition GUIDs and the EFI boot entries were held together with hope.

Windows is surprisingly forgiving about a sloppy boot config — until a power cut exposes it. The file system corruption was fixable. The real pain was the boot loader being half-configured to begin with.

If you clone drives, rebuild the boot loader. I skipped it because everything worked, and the next day my dog taught me a lesson about technical debt.

Phase One: Creating the Rescue USB

My Linux laptop was the only working machine, so I used Ventoy with a Windows ISO. Copy the ISO onto the drive, Ventoy handles the rest.

I got impatient and pulled the USB before the write finished. Ventoy booted but couldn’t actually load Windows — hung in wimboot mode. Redo the whole thing and wait for the write to finish. Don’t rush rescue media when you’re already stressed.

Phase Two: The Vanishing Drive

The first real scare was not the boot error. It was when the NVMe drive completely disappeared from BIOS. One moment it was there in the boot menu, the next it was gone. Not listed anywhere. The board explorer showed nothing.

My initial thought was that the drive itself had died. NVMe drives can enter a protective mode after failed self tests or sudden power events. Before you start pulling hardware, try this: unplug the PC completely, hold the power button for thirty seconds to drain any residual charge, then boot back into BIOS.

After the power cycle, the drive was still missing. The actual problem was subtle. On MSI motherboards, disabling Secure Boot can cause the BIOS to automatically switch to CSM Legacy mode. NVMe drives require UEFI mode to be visible. The drive was not dead. The BIOS just could not see it because it was looking in the wrong place.

Here is the trick that actually worked for me. Instead of disabling Secure Boot entirely, I used Ventoy’s manual key enrollment feature. You boot into Ventoy, select the VTOYEFI key enrollment option, and it adds the Ventoy signing key to your motherboard’s trusted key database. This lets you keep Secure Boot enabled while still booting unsigned ISOs through Ventoy. With Secure Boot on and UEFI mode intact, the NVMe drive was visible again.

Phase Three: File System Repair

With the drive visible again, I booted from the Windows installer USB. Immediately ran into another issue. The installer asked for media drivers, which is a common glitch with USB 3.0 ports or VMD configurations. The workaround is to skip the installer entirely. At the language selection screen, press Shift and F10 to open a command prompt. You do not need to go through the installer UI for repair work.

First step was checking the file system. In the recovery environment, drive letters get reassigned, so my C drive showed up as F. You can use diskpart and list vol to figure out which letter your Windows partition ended up with.

Running chkdsk f: /f /r revealed the damage. Volume Bitmap errors and an incorrect Master File Table bitmap attribute — the internal accounting structures Windows uses to track allocated vs free clusters. chkdsk took a while but repaired it.

After chkdsk I ran the offline system file checker: sfc /scannow /offbootdir=f:\ /offwindir=f:\windows. It found problems and fixed them. File system was healthy. System still wouldn’t boot.

Phase Four: The Boot Loader

The BCD was corrupted beyond what automatic repair could handle. bootrec /fixboot returned access denied, which is frustratingly common and means the standard approach won’t work.

The solution is to manually mount the EFI partition and rebuild the boot files from scratch. Open diskpart and list your volumes. Look for the small FAT32 partition, usually around 100MB to 500MB. This is your EFI System Partition. Select it and assign it a drive letter.

diskpart
list vol
sel vol 2
assign letter=S
exit

Once you have the EFI partition mounted, you can use bcdboot to recreate the entire boot configuration. The command takes your Windows directory and creates fresh boot files on the EFI partition.

bcdboot f:\windows /s s: /f UEFI

/s s: writes to the S drive where we mounted the EFI partition. /f UEFI forces UEFI-specific boot files. When it reports boot files created, reboot.

Mine booted. No data loss, no reinstall. A few hours of troubleshooting and a newfound appreciation for proper boot loader configuration.

Post Recovery Cleanup

If you reset BIOS defaults during troubleshooting, your XMP profile is probably disabled — re-enable it or your RAM will run at base speeds. Re-enable Secure Boot if you turned it off.

Run a backup.

Quick Reference Commands

For anyone who lands here from a search engine in the middle of their own crisis, here are the commands you need.

Check and repair the file system, replacing the drive letter with whatever your Windows partition is assigned in recovery:

chkdsk c: /f /r

Run the offline system file checker:

sfc /scannow /offbootdir=c:\ /offwindir=c:\windows

Mount the EFI partition and rebuild boot files:

diskpart
list vol
sel vol <EFI_PARTITION_NUMBER>
assign letter=S
exit
bcdboot c:\windows /s s: /f UEFI

The whole incident took longer than it should have because of the sloppy clone. If I’d rebuilt the boot loader the day before, the power loss would have caused file system corruption chkdsk could fix in minutes. Instead I spent hours fighting repair tools on a config that was already half broken.

The dog is fine, by the way. Completely unbothered. As dogs tend to be.