FVE_E_TPM_SRK_AUTH_NOT_ZERO (0X80310025) – Quick Fix

Yeah, this one's annoying. You're trying to enable BitLocker or maybe you just saw it pop up during a TPM check. The error code 0x80310025 means your TPM's Storage Root Key (SRK) has a non-zero authorization value. That's not what Windows expects. The fix is straightforward. No need to panic.

Fix It in Two Minutes

The culprit here is almost always a leftover TPM owner auth from a previous setup or a motherboard firmware change. Here's the quickest way to clear it:

1. Press Win + R, type tpm.msc, hit Enter.
2. In the right-hand pane, click Clear TPM.
3. Your PC will reboot. During reboot, you'll need to press F12 (or whatever key your BIOS shows) to confirm clearing the TPM.
4. After Windows loads, open tpm.msc again. It should show "The TPM is ready for use."
5. Now try your BitLocker setup. It'll work.

Don't bother with the "Prepare TPM" option in Group Policy — that rarely helps here. The issue is the SRK auth value, not the TPM state.

PowerShell Alternative

If you're on a server or prefer command line, run PowerShell as admin:

Clear-Tpm -Force
Restart-Computer

Same result. The -Force flag skips the confirmation prompt. After reboot, check with Get-Tpm — TpmReady should be True.

Why This Works

BitLocker requires the TPM's SRK to have an authorization value of zero. That's the default. When something changes it (like a previous TPM owner, a BIOS update, or switching from Intel to AMD), the auth value gets set to something non-zero. BitLocker sees that and throws 0x80310025. Clearing the TPM resets the SRK auth back to zero. You're essentially factory-resetting the TPM chip.

One thing: clearing the TPM wipes any keys stored in it. That means if you had BitLocker running with TPM-only protection, you'll lose access to that drive unless you have the recovery key. Keep that recovery key handy. You were told.

Less Common Variations

1. Firmware TPM (fTPM) on AMD Systems

If you're on an AMD Ryzen board, the TPM is embedded in the CPU firmware. Clearing via tpm.msc sometimes doesn't stick. You'll need to go into the UEFI/BIOS, find the fTPM setting (usually under Security or Advanced), and disable it. Save and exit. Boot into Windows, then shut down, go back into BIOS, re-enable fTPM. That clears the SRK auth every time.

2. Hyper-V Virtual TPM

Running BitLocker inside a VM with a virtual TPM? The error can occur if you migrated the VM from one host to another without resetting the virtual TPM. Fix: In Hyper-V Manager, open the VM settings, go to Security, and Remove the Virtual TPM. Then add a new one. Power on the VM. You'll need to re-enroll BitLocker.

3. BitLocker Already Running with a Password

Sometimes 0x80310025 appears when you try to switch from password-protected BitLocker to TPM-only. The TPM still has an auth value from a prior enrollment. Solution: Suspend BitLocker first (Manage-bde -protectors -disable C:), clear the TPM, then resume. This avoids the full decrypt.

Prevention for Next Time

• Before a motherboard swap or BIOS update, suspend BitLocker. Then clear the TPM using tpm.msc. Do the hardware change. After boot, re-enable BitLocker.
• Don't set a TPM owner password manually unless you absolutely need to (and almost nobody does). If you did, clear it via Clear-Tpm.
• Keep that recovery key printed or in your Microsoft account. It's your only way out if the TPM gets cleared unexpectedly.

That's it. You're not the first person to hit this, and you won't be the last. But now you know exactly what to do.