| Previous | Next |
| FVE_E_OPERATION_NOT_SUPPORTED_ON_VISTA_VOLUME | FVE_E_FIPS_HASH_KDF_NOT_ALLOWED |
FVE_E_CANT_LOCK_AUTOUNLOCK_ENABLED_VOLUME
Why this is not a generic disk error
The practical meaning of FVE_E_CANT_LOCK_AUTOUNLOCK_ENABLED_VOLUME is that the data volume is configured for automatic unlock on this computer, so BitLocker refuses to lock it while that relationship remains active. The HRESULT is 0x80310097.
Three decisions before remediation
- Is the result target correct?
- Use the volume or protector GUID and confirm its role; do not rely only on a drive letter or friendly name.
- Is the result request allowed?
- Resolve effective policy, Windows edition, caller token and management source for the volume state and geometry operation.
- Is the result state stable?
- Record conversion, protection, lock and reboot status before modifying anything.
The BitLocker provider tracks encryption conversion, protection, lock state, metadata version, filesystem geometry and outstanding volume use independently. Two volumes can both appear “encrypted” in a UI while being in very different states for a management API. Avoid “repair” commands until the filesystem, partition and BitLocker metadata layers have been distinguished. A change at the wrong layer can remove evidence or make recovery harder.
Why a common workaround is wrong
This should not be diagnosed as FVE_E_FS_MOUNTED, where open use blocks locking even without an automatic-unlock key. That nearby condition needs a different corrective action and may produce a similar user-facing message.
Confirm the returning layer
- Record automatic-unlock status, OS-volume protection state, protector list, open handles and the lock method used.
manage-bde -status
powershell -NoProfile -Command "Get-BitLockerVolume | Format-List *"
Automatic unlock creates a deliberate dependency
For a fixed data drive, automatic unlock stores material on the protected operating-system volume so Windows can unlock the data volume after startup. Locking that data volume while its automatic-unlock relationship remains configured would leave the management state inconsistent with the intended boot workflow. Enumerate automatic-unlock status separately from ordinary open handles and filesystem mounts.
Disable automatic unlock for the named data volume, confirm the OS volume remains protected, and only then issue the lock. If the volume is still busy afterward, investigate handles as a second and distinct condition.
State checks specific to FVE_E_CANT_LOCK_AUTOUNLOCK_ENABLED_VOLUME
| Stage | How to interpret it |
|---|---|
| Before the call | Record the target identity and the pre-call volume state and geometry state. The data volume is configured for automatic unlock on this computer, so BitLocker refuses to lock it while that relationship remains active. |
| At failure | Preserve automatic-unlock status, OS-volume protection state, protector list, open handles and the lock method used. |
| After correction | Disable automatic unlock for the volume, confirm no consumers remain, and then lock it through the supported command or WMI method. |
References
Looking for a different code? Search another status or error code.