0X80310001

FVE_E_NOT_ENCRYPTED Fix: Drive Fully Decrypted, No Key

BitLocker throws 0X80310001 when a volume is fully decrypted or no key exists. Usually caused by a suspended protection, a wiped TPM, or a decrypted OS drive. Fix: re-encrypt or clear the key protectors.

Cause 1: BitLocker was suspended and the drive got fully decrypted

The most common reason you see FVE_E_NOT_ENCRYPTED (0X80310001) is that someone (or a Windows update) suspended BitLocker protection, and the drive then went through a full decryption. Windows doesn't always tell you it's decrypting — it just does it in the background. Check manage-bde -status to confirm. If the Conversion Status says Fully Decrypted, that's your answer.

Why does this happen? A typical scenario: you disabled BitLocker to run a disk tool or a firmware update, then forgot to re-enable it. Or a third-party backup tool called Disable-BitLocker and never turned it back on. The volume is now plaintext, and BitLocker has no key protectors because there's nothing to protect.

Fix: Re-encrypt the drive

Decryption isn't a fault — it's just an unencrypted drive. You need to turn BitLocker back on. The quickest way is via the GUI, but I prefer command line for speed. Open an elevated PowerShell or CMD:

manage-bde -on C: -used

That uses used-space-only encryption, which is fast. For a full encryption (more thorough, slower), drop -used. If you want to also enable auto-unlock, you'd need to add that after, but for now just get it encrypted.

If that command throws an error about no TPM, you may need to enable the TPM in BIOS, or set a PIN. But that's a different error — for 0X80310001, the volume is fully decrypted, so the drive is writable and the command should work.

Once it starts encrypting, wait for the status to show Fully Encrypted before you trust it. You can monitor with manage-bde -status.

Cause 2: TPM was reset or cleared

The second most common cause is a cleared TPM. If the TPM chip was reset (either via BIOS, or by running tpm.msc and selecting "Clear TPM"), the key protectors that reference the TPM become invalid. But here's the catch: if the drive is still fully encrypted, you'd normally get a different error like FVE_E_AUTH_INVALID_APPLICATION or a recovery prompt. Getting 0X80310001 specifically means the drive is actually decrypted — or the TPM reset also triggered a decryption.

Some laptops automatically decrypt the BitLocker drive when the TPM is cleared, as a safety measure. That's why you're here. The volume is plaintext again, and the TPM has no valid key. So the fix is similar: re-encrypt, but first repopulate the TPM.

Fix: Clear old protectors and re-encrypt

First, verify the TPM is ready:

Get-Tpm | Select-Object TpmReady

If TpmReady is True, you can simply re-encrypt as above. If it's False, you might need to initialize it via Initialize-Tpm or through the BIOS. But if the drive is decrypted, you don't need the TPM for the fix — just encrypt.

However, to avoid this happening again, I'd recommend clearing any stale key protectors before re-encrypting. This is rare, but sometimes a half-removed protector confuses things. Use:

manage-bde -protectors -delete C: -type TPM

Then re-encrypt with manage-bde -on C:. If you get an error about missing protectors, don't panic — just run the -on command and it will add new ones based on your policy.

Cause 3: OS drive was decrypted manually and the key is gone

This one is less common on laptops, but I see it all the time on desktops and VMs. Someone ran manage-bde -off C: to decrypt the system drive, expecting to re-encrypt later, but then forgot. Or they used a third-party tool to remove BitLocker entirely. When you later try to run any BitLocker command (like enabling a new protector), you get 0X80310001 because the volume has no key — there's nothing to protect.

Important: Don't bother looking for a recovery key or trying to recover data — the data is already decrypted, so there's no key to find. The error message is clear: "no key available" means the drive is open, not locked.

Fix: Just turn BitLocker back on

Same as Cause 1, really. But there's a nuance: if the drive was originally encrypted with a different algorithm (like XTS-AES-256), you might want to match that. Check your Group Policy or just use the default. To see the current encryption method:

manage-bde -status C:

Look for the Encryption Method line. If it's blank or says None, you're good to go with the default. If you want to specify a method, you can use:

manage-bde -on C: -EncryptionMethod XtsAes256

That's for Windows 10/11. For Windows 8.1 and earlier, use Aes256.

Quick-Reference Summary

What happenedDiagnosisFix
BitLocker suspended, drive decryptedmanage-bde -status shows Fully DecryptedRun manage-bde -on C:
TPM clearedTPM reset in BIOS, drive decrypted after bootRe-encrypt with manage-bde -on C:, then enable TPM protector
Drive manually decryptedNo protectors listed, status shows DecryptedRun manage-bde -on C: with desired encryption method

One last thing: if you're on a device that's managed by an organization, Group Policy might require a specific encryption method or TPM protector. If your command returns a policy error, call your IT admin. But if you're on a standalone machine, the above will get you back to encrypted state in minutes.

Related Errors in Cybersecurity & Malware
Fix encrypted email recipient can't open message Antivirus Real Time Scan Eating 100% Disk? Fix It Now 0XC021001A BitLocker 0xC021001A: TPM + PIN not working fix Heartbeat Lost Fix Endpoint Agent Heartbeat Lost on Windows 10 22H2

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.