Fix BitLocker Error 0x80310010 (FVE_E_BAD_INFORMATION)

BitLocker won't mount your drive because the metadata header got trashed. Usually a bad shutdown or damaged TPM key. Try the quick fixes first, then repair-bde.

So you've got a BitLocker volume that won't mount, and Windows is throwing FVE_E_BAD_INFORMATION (0x80310010) at you. Translation: the metadata header on the encrypted volume is unreadable. The volume control block — the little chunk of data that tells Windows how the drive is encrypted, what protector is in use, and where the keys live — is either corrupted or missing entirely. Without it, Windows has no clue how to unlock the drive even if you type the right recovery key.

I've seen this pop up after roughly three scenarios. A hard power-off during a Windows update that was mid-write to the volume. A USB drive yanked while still mounted. And bad sectors on the drive itself eating the metadata region. Laptops with dying SSDs are the worst offenders. If you're here because of one of those, buckle up. This is a triage flow — do the easy stuff first, stop as soon as you're back in.

Step 1: The 30-Second Fix — Rule Out the Stupid Stuff

Before you touch repair tools, confirm the basics. Half the people who hit 0x80310010 are actually looking at a different problem dressed up as this one.

Reboot cleanly. Hold Shift while clicking Restart in the Start menu. That forces a full shutdown instead of a hybrid one. BitLocker state gets re-read from disk on boot.
Try a different USB port or cable. If it's an external drive, a flaky USB 3.0 port on a cheap hub will absolutely cause read errors on the metadata region. Plug it directly into the motherboard.
Check if the volume shows up at all. Open an elevated Command Prompt and run:

manage-bde -status

You want to see the volume listed with a Conversion Status of anything — even Failed is fine. If the volume doesn't appear at all, you've got a bigger problem and this error is a symptom, not the disease. Check diskpart and see if the partition is even recognized.

If the drive isn't showing up in Disk Management at all, stop. You're looking at hardware failure, not BitLocker corruption. Get it to a data recovery shop before you write anything to it.

Step 2: The 5-Minute Fix — Rebuild the Protector and Retry

Assuming the volume is visible but won't unlock, the protector metadata is probably out of sync. This happens a lot on machines where the TPM was cleared, the BIOS was updated, or Secure Boot state changed. The drive is fine. Windows just can't match the key material to the volume.

Get your recovery key. 48 digits, usually in your Microsoft account under Devices, or in Active Directory if this is a domain machine. If you can't find it, this is where you stop and go hunting — no tool on earth will help you without that key.
Open elevated Command Prompt and try unlocking with the recovery password directly:

manage-bde -unlock E: -RecoveryPassword 111111-222222-333333-444444-555555-666666-777777-888888

Substitute E: for your actual drive letter. If this works, you're done — immediately run manage-bde -protectors -add E: -RecoveryPassword to add a fresh protector before the old one flakes out again.

If the unlock command throws 0x80310010, the metadata header itself is damaged. The recovery key is correct, but Windows can't read the structure that tells it where to apply the key. That's when you step up.

Also worth trying: the TPM clear

On domain machines where the recovery key is managed by AD, I've fixed this by clearing the TPM in the BIOS and re-provisioning. It sounds scary but it's reversible if you have the recovery key. Skip it if this is a personal machine — the recovery key is your only safety net and clearing TPM doesn't help if the volume header is the broken part.

Step 3: The 15+ Minute Fix — repair-bde and the BitLocker Recovery Environment

This is the real fix for FVE_E_BAD_INFORMATION. Microsoft shipped repair-bde for exactly this scenario. It reads the damaged volume, rebuilds the metadata using your recovery key, and writes the decrypted output to a separate drive. It does not repair in place. You need somewhere else to put the data.

What you need before you start

A second drive with enough free space for the entire decrypted volume (check the size in Disk Management — encrypted data doesn't shrink when decrypted)
Your 48-digit recovery key
Windows installation media or WinRE — repair-bde runs from the recovery environment reliably; from a live OS it sometimes can't get exclusive access to the volume

The actual command

Boot from Windows install media, choose Repair your computer, then Troubleshoot, then Command Prompt. From there:

repair-bde E: F: -rp 111111-222222-333333-444444-555555-666666-777777-888888 -f

E: is the broken volume. F: is the destination. -rp takes the recovery password. -f forces the operation even if the volume is mounted or in use — you want this.

You'll see progress output. On a 500GB drive expect 40 minutes to a couple hours depending on the source disk's health. If it's throwing read errors on the source, you're going to be there a while.

If repair-bde fails

Two common failures worth knowing:

"Cannot open the input volume" — the volume is offline or has no drive letter. Use diskpart and select volume X, then online volume and assign letter=E.
Immediate failure with a hex error — the header corruption is bad enough that repair-bde can't reconstruct it. At this point the FVEK (Full Volume Encryption Key) may still be recoverable from a backup protector, but you need commercial tools. Dislocker on Linux, Elcomsoft Forensic Disk Decryptor, or Passware. All paid, all aimed at forensics folks, but they can pull data where repair-bde can't.

Why This Actually Happens

BitLocker stores three copies of the metadata block across the volume — one at the start, two more at intervals. In theory, corruption in one copy shouldn't be fatal. In practice, when a drive has bad sectors or the partition table gets rewritten by a third-party tool (looking at you, Acronis and various partition resizers), all three copies can end up in the same unreadable state. Once they're gone, the volume is a brick to Windows.

I've also seen this on VMs where someone snapshotted a BitLocker-protected volume and restored it to a point where the encryption state was mid-flight. The header went out of sync with the encrypted data. No amount of rebooting fixes that.

Preventing It Next Time

Not much you can do once it's happened, but three habits will save you pain later:

Back up recovery keys to your Microsoft account AND print them. Cloud-only keys are useless if you lose account access.
Don't BitLocker USB drives you unplug constantly. Use VeraCrypt or just 7-Zip with AES-256 for portable encryption. BitLocker is designed for drives that stay attached.
Run CrystalDiskInfo on any drive showing this error. If SMART status shows reallocated sectors, the drive is dying and repair-bde is on a clock. Image the source disk first with ddrescue if the data matters.

And if you're stuck at 0x80310010 on a machine where the data is genuinely irreplaceable and repair-bde won't cooperate, stop poking it. Every write, every mount attempt, every "try one more thing" risks overwriting the metadata that a forensic tool might still recover. Pull the drive, hand it to a specialist, and let them try.