0X80310017

FVE_E_VOLUME_NOT_BOUND (0X80310017) – Fix BitLocker Volume Not Bound

Hardware – Hard Drives Intermediate 👁 13 views 📅 May 29, 2026

BitLocker says the volume isn't bound to the system. This happens after hardware changes, TPM issues, or missing secure boot keys. Here's how to fix it.

1. TPM Has Lost Its Binding Keys (Most Common)

What's actually happening here is that BitLocker uses a TPM (Trusted Platform Module) to lock the encryption keys to your specific hardware. The error FVE_E_VOLUME_NOT_BOUND means the volume's protector — usually the TPM — no longer matches what the system expects. This happens most often after you update your motherboard firmware, swap a hard drive, or if your TPM gets cleared by a BIOS update.

If you've recently updated your BIOS or TPM firmware, that's your culprit. The TPM's Platform Configuration Registers (PCRs) changed, and BitLocker sees the system as untrusted. Windows won't let you unlock the volume because it can't verify the binding.

How to fix it:

  1. Open an elevated Command Prompt (Run as Administrator).
  2. Run manage-bde -status C: (replace C with your drive letter). Check if the TPM protector shows as "OFF" or "Unknown".
  3. If the TPM protector is missing or broken, run this to re-bind it:
    manage-bde -protectors -disable C:
    manage-bde -protectors -enable C:
  4. That sequence forces BitLocker to re-evaluate and re-bind the TPM protector to the current hardware state.
  5. After that, reboot. If it still fails, try clearing the TPM from the BIOS menu (search for "TPM Clear" or "Clear TPM") then re-enable it in Windows with tpm.msc.

The reason step 3 works is that manage-bde -protectors -disable suspends BitLocker protection, wiping the current broken binding. The -enable command regenerates a fresh binding using the current PCR values. This is the nuclear option — it's safe because the volume stays encrypted, but the keys get re-mapped.

2. Secure Boot or UEFI Settings Got Changed

BitLocker on modern Windows (8.1 and later) uses Secure Boot as part of its measured boot process. If you disabled Secure Boot in your UEFI/BIOS, or switched between UEFI and legacy BIOS mode, the PCR measurements change. That breaks the binding. You'll see error 0x80310017 as soon as Windows tries to unlock the drive at boot.

This is especially common if you dual-boot Linux or mess with boot order. I've seen people toggle Secure Boot to "Other OS" instead of "Windows UEFI Mode" and get stuck.

How to fix it:

  1. Reboot into your UEFI/BIOS (usually F2, Del, F10 during boot).
  2. Set Secure Boot to "Enabled" or "Windows UEFI Mode".
  3. Make sure boot mode is UEFI, not Legacy/CSM.
  4. Save changes and boot to Windows. If it still errors, you need to re-bind the protectors as in fix #1.
  5. If you can't get into Windows at all, boot from a Windows installation USB, open Command Prompt (Shift+F10), and use manage-bde -unlock C: -RecoveryPassword with your 48-digit recovery key (from your Microsoft account or printout).

The key insight: BitLocker checks the Secure Boot state as part of PCR 7. If Secure Boot's off, PCR 7's value is different, so the TPM won't release the key.

3. Volume Was Bound to a Different System (Hardware Swap)

If you pulled that hard drive out of a dead laptop and plugged it into a new PC, the volume was encrypted with a TPM protector from the old motherboard. The new system's TPM has no idea about those keys. Windows will show you the "Volume is not bound" error.

This is the trickiest scenario because you can't just re-bind — the old TPM's key is gone. You need the recovery key.

How to fix it:

  1. Have your 48-digit BitLocker recovery key ready. If you don't have it saved anywhere (Microsoft account, printout, USB), you're locked out permanently.
  2. Boot the new system with the drive attached. At the BitLocker recovery screen, enter the recovery key.
  3. Once in Windows, open an elevated Command Prompt and remove the old TPM protector:
    manage-bde -protectors -delete C: -type TPM
  4. Then add a new TPM protector for the current hardware:
    manage-bde -protectors -add C: -TPM
  5. Reboot. BitLocker should now bind to the new system's TPM.

The reason step 3 works is that the old TPM protector is essentially a dead key — it's tied to hardware that no longer exists. Deleting it removes the orphaned binding, and adding a new TPM protector generates a fresh seal against the current machine's TPM. Without this step, you'll keep hitting 0x80310017 on every reboot.

Quick-Reference Summary

Cause Fix Command Notes
TPM keys lost after firmware update manage-bde -protectors -disable C: && manage-bde -protectors -enable C: Re-binds without losing data
Secure Boot disabled or boot mode changed Enable Secure Boot in UEFI, then re-bind protectors Check PCR 7 value with manage-bde -protectors -get C:
Drive moved to different hardware manage-bde -protectors -delete C: -type TPM then manage-bde -protectors -add C: -TPM Requires recovery key first
One more thing: If you're still stuck, run manage-bde -protectors -get C: and look for any RecoveryPassword entries. If none exist, you have no recovery key — and that's a bigger problem than the error itself. Always back up your recovery key before messing with TPM or hardware.

Was this solution helpful?