Windows isn’t considered as malleable as Linux is when it comes to lower-level system tweaks and fixes, but you might be surprised to learn that the recovery tools built in to Windows are actually pretty powerful. Recently, my friend was playing Detroit: Become Human when her PC suddenly froze. After a reboot, she was hit with an “inaccessible boot device” error, and subsequent reboots were met with a screen that required her BitLocker key. Entering it looped back around to the inaccessible boot device screen.
That system, powered by an Intel Core i5-14600K and an Intel Arc A770, appeared to be dead entirely. Startup repair couldn’t fix it, and Bitlocker’s refusal to unlock the drive with the provided key had me fearing the worst. Thankfully, she keeps backups of all important data, but it seemed odd; how could this happen? And was it salvageable?
Bitlocker turned a bad situation worse
But it wasn’t actually the problem
Taking a look at the computer myself, the first thing I saw was a BitLocker recovery screen. I pulled up the recovery key from her Microsoft account, typed it in carefully, and gave it a moment. The system rebooted and landed on an inaccessible boot device screen, before rebooting again and landing right back on a screen that asked for the key again. It accepted the input, did nothing useful with it, and looped. At this point, I thought the drive was dead, but that still didn’t make sense; it’s a Corsair MP700, and it’s barely been used since I bought it.
Instead, I opted to take another approach, to first evaluate whether the drive was even alive. I booted into Clonezilla from a Ventoy USB stick and ran ntfsfix to check the partition. The NTFS volume mounted cleanly, and the filesystem itself appeared intact. At this point, it seemed clear to me that the boot configuration itself, somewhere in the chain, was corrupted.
However, what exactly was damaged was unclear to me. At first, I thought it was the EFI, but I didn’t know that the crash had also damaged the Boot Configuration Data, also known as the BCD. On a modern Windows system, here’s how the boot sequence looks:
- UEFI firmware
- EFI boot manager
- \EFI\Microsoft\Boot\bootmgfw.efi
- BCD store
- winload.efi
- Kernel initialization
- Boot-start drivers
- SYSTEM hive
- Userland
When the EFI boot files and BCD were corrupted, the measured boot environment no longer matched what the TPM had sealed the BitLocker key against. This meant that it refused to release the encryption key automatically, and while manually entering the correct recovery key overrides this, it couldn’t help because there was nothing valid to actually boot into.
In other words, with the partition decrypted, Windows could proceed to winload, but the corrupted BCD entries pointed to the wrong device path. When the kernel attempted to mount the system volume, it failed and threw INACCESSIBLE_BOOT_DEVICE. It turned out that repairing the EFI part would only solve half of the problem.
Most people never open it
Windows Recovery Environment offers a handful of graphical repair options, like Startup Repair, System Restore, and Reset this PC, and they’re the ones most people reach for. None of them could fix this. But buried under Advanced Options is a command prompt, and that’s where the real recovery power lives. I knew the drive’s data was okay given that I had mounted it from Clonezilla, so it was worth trying to figure out how to reconstruct the boot sequence appropriately.
First, I needed to unlock the BitLocker-encrypted drive. One thing worth knowing about WinRE is that drive letters don’t always match what you see in normal Windows. Your C: drive might show up as D: or E: in the recovery environment, so I used `diskpart` to list the volumes and identify the right one before doing anything else. From there, I ran “manage-bde -unlock C: -RecoveryPassword” followed by the 48-digit key, then”`manage-bde -protectors -disable C:” to temporarily suspend BitLocker protection. That way I could work on the boot files without getting locked out again mid-repair.
The next step was getting access to the EFI System Partition. It’s a small, hidden FAT32 partition, usually around 100 MB, that holds the Windows Boot Manager and the BCD store. It has no drive letter by default, and WinRE doesn’t assign one automatically either. Back in “diskpart”, I selected the disk, listed the volumes, found the EFI partition, and assigned it the letter S manually. I did this after manage-bde had thrown a “parameter incorrect” error, and forcing the drive letter assignment is what resolved it.
With the EFI partition accessible at S:, I ran “bcdboot C:\Windows /s S: /f UEFI”. That single command does all of the heavy lifting. It copies the necessary boot files from the Windows installation to the EFI partition, generates a fresh BCD store from a built-in template, and configures the boot manager to point at the correct Windows partition. With just that one command, the entire boot chain gets rebuilt from scratch. I ran “bcdedit /enum” to verify the new entries looked correct, rebooted, and Windows loaded normally. Everything was intact.
Once I was back in Windows, I re-enabled BitLocker from an elevated command prompt with “manage-bde -protectors -enable C:”.
And Microsoft keeps adding to them
The thing that got me wasn’t the fix itself. It’s that these tools, namely “bcdboot”, “bcdedit”, “manage-bde”, and “diskpart”, have shipped with Windows for years… yet most people don’t know they exist. The default instinct when Windows won’t boot is to grab an installer USB and start over, and I get it. The recovery environment doesn’t exactly go out of its way to advertise what its command line can do. But these tools can save you from wiping a drive that’s perfectly healthy, and they’re far more capable than most people realize.
Microsoft has been quietly improving the recovery environment too. Windows 11 now pulls network drivers from the main OS install into WinRE, meaning the recovery environment can actually connect to the internet without you having to inject drivers manually first. That’s what enables Quick Machine Recovery, a feature directly inspired by the CrowdStrike incident in 2024, which can automatically download targeted fixes when a device keeps failing to boot. There’s even a Point-in-Time Restore feature in preview that would let you roll back to an exact previous system state rather than just the nearest restore point.
Of course, there’s some irony in all of this. Microsoft’s own updates have repeatedly triggered BitLocker recovery prompts like the one I ran into. The October 2025 security update sent Intel-based PCs into that same sequence (though it was a one-time unlock, as opposed to reptitive), and a companion bug broke USB keyboard input in WinRE, meaning affected users couldn’t even type their recovery key to get out of it. Microsoft patched it within a week, but if you were stuck in that loop without knowing these commands, you’d have been completely out of luck. Startup Repair won’t always save you, and when it can’t, the command prompt is the next best thing.
That PC is running perfectly now. I didn’t need to reinstall, no data was lost, and that meant an evening without needing to set everything back up from scratch. The tools were right there in Windows the whole time, and I’m glad that I knew to try them out first.
