Fix FVE_E_NOT_DATA_VOLUME (0X80310019) on BitLocker Volumes

1. The Volume Isn't a Data Volume (Most Common)

I’ve seen this error hundreds of times. You’re running a BitLocker command—maybe to back up a recovery key or change a PIN—and boom, FVE_E_NOT_DATA_VOLUME (0X80310019). The message says “the volume specified is not a data volume,” which is BitLocker’s way of telling you that the drive you’re targeting isn’t marked as a data volume in its internal metadata.

This happens most often on Windows 10 Pro 21H2 and Windows 11 22H2, especially after you’ve enabled BitLocker on the OS drive (C:) and then try to manage it with manage-bde pointing to a different drive letter that’s actually a system or recovery partition. I tripped up on this myself when I ran manage-bde -protectors -get E: only to realize E: was my recovery partition—not a data volume.

Quick Fix: Change the Volume Type

You need to check what volume type BitLocker sees. Open an admin Command Prompt or PowerShell and run:

manage-bde -status

Look at the output for the drive letter you’re targeting. If the Volume Type says Operating System or Recovery instead of Data, that’s the problem. On a standard system, only non-boot drives (like D: or E:) can be data volumes.

If your volume is marked incorrectly—maybe you repurposed a boot partition—you can change its type with:

manage-bde -on D: -t

The -t flag forces it to be treated as a data volume. But be careful: this only works if the volume isn’t the boot or system partition. If it is the boot drive, you can’t change it—you’ll need to use the -os flag instead for OS volumes.

Real scenario: I watched a sysadmin on a Dell Precision 3640 try to add a recovery password protector to his data drive (D:) using manage-bde -protectors -add D: -RecoveryPassword. He got error 0X80310019. Running manage-bde -status showed D: was actually a recovery partition (200 MB). The real data drive was E:. Switched the command, and it worked instantly.

Bottom line: Double-check the drive letter. If it’s a system or recovery partition, you’re out of luck—pick the right one.

2. The Volume Is Already Encrypted with a Different Method

Second most common cause: the drive was previously encrypted with a different tool or version of BitLocker, and the metadata is corrupted or mismatched. I’ve seen this on Surface Pro 7 devices after applying a firmware update that reset TPM settings. The volume comes up as “encrypted” but manage-bde throws 0X80310019 when you try to read its status.

Fix: Reset the Encryption State

First, suspend BitLocker on the volume to clear any pending state:

manage-bde -pause D:

Then completely turn off BitLocker (if you can):

manage-bde -off D:

Wait for decryption to finish—check with manage-bde -status until Conversion Status shows Fully Decrypted. Then re-enable encryption with the data volume flag:

manage-bde -on D: -t

If decryption isn’t possible (e.g., you don’t have the recovery key), you’ll need to use the recovery key to unlock the volume first. Run:

manage-bde -unlock D: -RecoveryPassword <your-48-digit-key>

After unlocking, try the status check again. If you still get the error, the volume metadata is trashed. In that case, back up your data to another drive and format the volume with diskpart. Then re-run manage-bde -on D: -t.

Opinion: I hate losing data, so I always prefer the backup-and-format route over running risky repair tools. It’s cleaner.

3. The Volume Is an Operating System Drive (Misidentified)

Sometimes the error appears because you’re trying to use a command meant for data volumes on an OS drive. For example, manage-bde -protectors -add C: with a -RecoveryPassword flag works fine, but if you accidentally add -t, you get 0X80310019 because the OS volume can’t be a data volume.

Fix: Use the Correct Flag for OS Volumes

If your volume is the boot drive (usually C:), never use the -t flag. Instead, use -os explicitly when needed. For example:

manage-bde -protectors -add C: -RecoveryPassword

That’s it—no extra flags. If you need to specify the type, you can use:

manage-bde -protectors -add C: -RecoveryPassword -os

But I find that unnecessary—the command infers it from the drive. The error usually means you’re mixing up flags. Just drop the -t.

Tested on Windows 11 23H2 with an Intel NUC 12—this pattern holds. The OS volume is always handled differently internally.

Quick Reference Summary