| Previous | Next |
| FVE_E_EDRIVE_NO_FAILOVER_TO_SW | FVE_E_EDRIVE_DISALLOWED_BY_GP |
FVE_E_EDRIVE_BAND_IN_USE
Where the operation stops
The value 0x803100B0, named FVE_E_EDRIVE_BAND_IN_USE, is returned when the self-encrypting drive band is already owned or activated by another hardware-encryption configuration. It belongs to the hardware-encrypted drive negotiation part of BitLocker rather than to generic file I/O.
If policy permits software fallback, verify the final method explicitly. A failed hardware dry run can otherwise leave an administrator assuming protection that never started. Hardware-encrypted drives add firmware, storage-driver and drive-security state below the normal BitLocker volume provider. BitLocker can reject the hardware path before conversion starts, and policy may or may not permit a fallback to software encryption.
| Question | What to verify |
|---|---|
| Which object failed? | The exact volume GUID, protector GUID, certificate or API target supplied by the caller. |
| Which state matters? | drive security protocol state, band ownership, vendor management history, BitLocker hardware status and firmware tools used. |
| What is the nearest false lead? | a volume merely unlocked by BitLocker; band ownership is persistent device state below the filesystem. |
Build a minimal diagnostic record
- Record drive security protocol state, band ownership, vendor management history, BitLocker hardware status and firmware tools used.
Change only the failed prerequisite
determine the existing band owner and securely revert or migrate it using supported vendor/BitLocker procedures before reprovisioning.
manage-bde -status
powershell -NoProfile -Command "Get-CimInstance -Namespace root/cimv2/security/MicrosoftVolumeEncryption -Class Win32_EncryptableVolume"The drive security band already has an owner
Self-encrypting drives maintain security-band state below partitions and filesystems. A previous operating system, vendor utility or provisioning attempt can activate the band before BitLocker reaches it. Reformatting NTFS or deleting partitions does not necessarily release that hardware ownership.
Identify the existing owner and use a supported secure-revert or migration procedure with full data-loss planning. Do not issue vendor reset commands until recovery and backup requirements are satisfied.
State checks specific to FVE_E_EDRIVE_BAND_IN_USE
| Stage | How to interpret it |
|---|---|
| Before the call | Record the target identity and the pre-call hardware-encrypted drive negotiation state. The self-encrypting drive band is already owned or activated by another hardware-encryption configuration. |
| At failure | Preserve drive security protocol state, band ownership, vendor management history, BitLocker hardware status and firmware tools used. This proves whether this result came from BitLocker itself or from a wrapper translating another result. |
| After correction | Determine the existing band owner and securely revert or migrate it using supported vendor/BitLocker procedures before reprovisioning. |
Official documentation
Looking for a different code? Search another status or error code.