Fix STATUS_FVE_VOLUME_NOT_BOUND (0XC021000B) Fast

You're staring at STATUS_FVE_VOLUME_NOT_BOUND (0XC021000B) and wondering why BitLocker suddenly hates you. I've seen this exact error on hundreds of machines over the years. The culprit is almost always one of two things: the TPM lost its mind after a firmware update, or the boot configuration got jumbled. Sometimes it's just a dumb Windows update that messed with the secure boot keys.

Don't panic. You're not locked out yet — the drive is encrypted but the system can't bind the keys. Here's the troubleshooting flow. Start at step one and only move down if it doesn't work. Most people are done in under a minute.

Quick Fix (30 seconds) - Check TPM Status

Open an elevated command prompt (Win+X, then select “Command Prompt (Admin)” or “Terminal (Admin)”). Run:

tpm.msc

Look at the status. If it says "The TPM is ready for use," you're fine. If it says "Compatibility mode" or worse, "Not supported," that's your problem. But even if it looks fine, sometimes the TPM just needs a nudge.

Here's the quick kick in the pants:

1. Disable BitLocker temporarily with manage-bde -protectors -disable C: (or your drive letter).
2. Reboot.
3. Re-enable with manage-bde -protectors -enable C:.

That clears the binding state and forces Windows to re-read the TPM. I've fixed maybe 30% of these cases just by doing that. If the error persists, move on.

Moderate Fix (5 minutes) - Repair Boot Configuration

If the key reset didn't do it, the boot configuration is probably corrupted. This happens after a failed Windows update or a dual-boot setup gone sideways. You'll want to rebuild the BCD store.

Boot into the Windows Recovery Environment first. You can do this by holding Shift while clicking Restart, or using a Windows installation USB.

From the recovery menu, go to Troubleshoot > Command Prompt. Then run these commands in order:

bootrec /fixmbr
bootrec /fixboot
bootrec /scanos
bootrec /rebuildbcd

Reboot and try BitLocker again. If it still throws 0XC021000B, you might need to manually mount the EFI system partition and verify it's intact. Here's the check:

diskpart
list disk
select disk 0
list partition

Look for a small partition (100MB or so) labeled EFI or System. Assign it a drive letter temporarily:

select partition 1
assign letter=S:
exit

Then check if the boot files are there:

dir S:\EFI\Microsoft\Boot

If that directory is empty or missing, you've got a bigger problem — jump to the advanced fix. If the files are there, try this: run manage-bde -lock C: then manage-bde -unlock C: -recoverypassword your-key (you did save your recovery key, right?). That sometimes re-establishes the binding.

Advanced Fix (15+ minutes) - Clear TPM and Rebind

When the boot repair doesn't cut it, the TPM state is likely toast. This is what I call the "nuclear option," but it works. You'll need to clear the TPM, which means you'll lose the existing encryption keys, so make sure you have your BitLocker recovery key and a backup of any critical data. You'll also need to enter your BIOS to re-enable TPM after clearing.

First, clear the TPM from Windows (this doesn't wipe your data):

tpm.msc
# Click "Clear TPM" on the right side

Reboot into BIOS (usually Del or F2 during boot). Find the TPM or Security section and set it to "Disabled," save, and reboot one more time. Then go back into BIOS and re-enable TPM. Boot back into Windows.

Now you've got a clean TPM. Re-encrypt the drive with BitLocker from scratch. This takes a while, but it's the cleanest fix. If you're in a hurry, you can suspend protection instead of a full re-encrypt:

manage-bde -protectors -disable C:

But honestly, if you've gotten this far, just re-encrypt. The TPM key is gone anyway.

One more thing — if you're on a virtual machine, this error shows up when you clone a VM without capturing the TPM state. The fix is to run sysprep or use the VM vendor's tool to reset the TPM. For Hyper-V, that means disabling and re-enabling the TPM in the VM's security settings.

Why This Happens

Every time I've seen 0XC021000B, it's been one of these scenarios:

• TPM firmware update from the OEM (Dell, HP, Lenovo) that didn't properly retain the keys.
• Windows update that changed the secure boot policy.
• Someone messed with the boot manager (EasyBCD, bootable USB tools).
• BIOS/UEFI settings changed — Secure Boot got toggled off or on.

The error means the volume's encryption key can't be sealed to the TPM because the system state changed underneath it. So the fix is always about re-establishing that trust. The quick reset handles most cases because it just re-seals the key.

If you're still stuck after all this, don't waste time guessing. Check the Windows event log for TPM errors under "Applications and Services Logs > Microsoft > Windows > TPM-Services." That'll tell you exactly which TPM command is failing. And if you have a recovery key, you can always access the drive via the recovery console — so you're never truly locked out.

Good luck. You'll probably need that recovery key somewhere in this process, so dig it out now.