What does HRESULT 0x803100AF (FVE_E_EDRIVE_NO_FAILOVER_TO_SW) mean?

FVE_E_EDRIVE_NO_FAILOVER_TO_SW

The exact BitLocker boundary

FVE_E_EDRIVE_NO_FAILOVER_TO_SW (0x803100AF) identifies the point where hardware-encryption setup failed and policy forbids falling back to BitLocker software encryption. For FVE_E_EDRIVE_NO_FAILOVER_TO_SW, note: Hardware-encrypted drives add firmware, storage-driver and drive-security state below the normal BitLocker volume provider. When diagnosing FVE_E_EDRIVE_NO_FAILOVER_TO_SW, remember: BitLocker can reject the hardware path before conversion starts, and policy may or may not permit a fallback to software encryption.

For FVE_E_EDRIVE_NO_FAILOVER_TO_SW, note: If policy permits software fallback, verify the final method explicitly. When diagnosing FVE_E_EDRIVE_NO_FAILOVER_TO_SW, remember: A failed hardware dry run can otherwise leave an administrator assuming protection that never started.

Do not confuse it with a nearby failure

Keep this separate from FVE_E_EDRIVE_DISALLOWED_BY_GP, where hardware encryption itself is prohibited rather than required without fallback. For FVE_E_EDRIVE_NO_FAILOVER_TO_SW, that distinction determines whether the next check belongs to policy, protector inventory, volume geometry, firmware, account escrow or the calling application's buffer contract.

Evidence that distinguishes the condition

• For FVE_E_EDRIVE_NO_FAILOVER_TO_SW, record hardware-encryption policy, fallback setting, drive readiness, firmware/driver versions and dry-run failure. For FVE_E_EDRIVE_NO_FAILOVER_TO_SW, keep the full HRESULT and the first method that returned it because later cleanup calls can report a different state.
• For FVE_E_EDRIVE_NO_FAILOVER_TO_SW, capture manage-bde -status and the protector inventory for the exact volume GUID, not only the drive letter, because letters can change in WinRE, clusters and deployment environments.
• Export BitLocker operational events for the FVE_E_EDRIVE_NO_FAILOVER_TO_SW failure and note the boot session, caller identity and management source; that evidence separates this BitLocker condition from a generic access or storage error.

manage-bde -status
powershell -NoProfile -Command "Get-CimInstance -Namespace root/cimv2/security/MicrosoftVolumeEncryption -Class Win32_EncryptableVolume"

Safe corrective sequence

1. For FVE_E_EDRIVE_NO_FAILOVER_TO_SW, either correct the eDrive prerequisites or change policy to permit software encryption; do not assume the volume became encrypted.
2. After correcting the FVE_E_EDRIVE_NO_FAILOVER_TO_SW prerequisite, refresh protection, conversion and lock state before one controlled retry; a cached UI message is not proof that the FVE_E_EDRIVE_NO_FAILOVER_TO_SW condition is still active.
3. Before a FVE_E_EDRIVE_NO_FAILOVER_TO_SW remediation deletes protectors, changes firmware mode, resizes partitions or decrypts a production drive, verify that an independent recovery method is available and escrowed in the intended directory or account.

For FVE_E_EDRIVE_NO_FAILOVER_TO_SW, the boundary above identifies which BitLocker state must change before a retry can be meaningful; repeating the call without changing that state only adds noise.

State checks specific to FVE_E_EDRIVE_NO_FAILOVER_TO_SW

Verification after the change

For FVE_E_EDRIVE_NO_FAILOVER_TO_SW, success means more than the absence of a dialog. Confirm that the condition represented by FVE_E_EDRIVE_NO_FAILOVER_TO_SW now matches the intended design, that the protector inventory has not lost an independent recovery route, and that the next reboot or remount can unlock the volume. If the FVE_E_EDRIVE_NO_FAILOVER_TO_SW request advances to another HRESULT, record both values in order because that transition reveals the next unmet prerequisite.

References

Reference set for FVE_E_EDRIVE_NO_FAILOVER_TO_SW:

• Microsoft: Encrypted hard drives
• Microsoft: GetHardwareEncryptionStatus method
• Microsoft: BitLocker operations guide
• Microsoft: Configure BitLocker policy

Looking for a different code? Search another status or error code.