TPMAPI_E_INVALID_PARAMETER (0x80290104) fix for BitLocker and TPM tools

You're staring at 0x80290104

It usually pops up when you try to manage BitLocker, check TPM status in tpm.msc, or run a PowerShell cmdlet like Get-Tpm. The error text says "One or more input parameters are invalid" — but that's misleading. The TPM hardware itself is fine. What's actually happening here is the TPM's internal base key (the Storage Root Key, or SRK) is corrupted, or the certificate chain the OS passes to the TPM doesn't match what the TPM expects.

The real fix: clear the TPM base key

You don't need to clear the entire TPM, which wipes all your BitLocker keys. Instead, you reset just the SRK. This takes 30 seconds and doesn't touch your encrypted drives if you have the recovery key.

1. Back up your BitLocker recovery key first. You'll need this if something goes sideways. Run manage-bde -protectors -get C: in an admin command prompt to find it, or check your Microsoft account under devices > BitLocker recovery keys.
2. Open an elevated PowerShell window (Win+X, Terminal Admin).
3. Run this command:
   

   Clear-Tpm -Provider MicrosoftPlatformCryptoProvider

   This resets the SRK without touching other TPM structures. The -Provider flag is key — without it, the command does nothing useful here.
4. Reboot. The TPM will re-provision itself on boot, recreating the SRK from scratch.
5. Now run Get-Tpm in PowerShell. You should see IsReady = True and the error is gone.

If you get an access denied error on Clear-Tpm, your BIOS is probably blocking TPM commands. Reboot into UEFI settings, find TPM under Security, and disable then re-enable it. Don't clear the TPM from BIOS — that's overkill and can cause boot loops with BitLocker.

Why clearing the SRK works

The TPM's SRK is the root of a key hierarchy. When Windows calls a TPM function like TPM2_CreatePrimary with a specific key template — say, an ECC P-256 key with certain policy — the TPM checks whether the SRK already exists and matches that template. If the SRK was created with a previous version of Windows (like during an upgrade from Win10 21H2 to Win11) or by a different TPM driver, the template parameters won't match. The TPM sees an existing key but with mismatched attributes, so it throws 0x80290104 instead of overwriting it. This is a deliberate security design: the TPM refuses to silently clobber keys.

Note: This error can also happen if you passed a malformed parameter to a TPM call via code. The fix is the same — clear the SRK. It's the most common root cause.

Less common variations and their fixes

1. The certificate chain is wrong

Some TPM-backed services (like Windows Hello for Business or vTPM in Hyper-V) pass a certificate chain during TPM provisioning. If the chain is expired or self-signed in an unexpected way, the TPM rejects it with the same error. Check Event Viewer under Applications and Services > Microsoft > Windows > TPM-WMI > Operational for event ID 773 or 774. If you see certificate-related text, run certutil -verify -store Tpm and look for expired certs. Delete any expired ones and re-provision the service.

2. Corrupted TPM driver

After a Windows update that swapped the TPM driver (common when moving from the Microsoft inbox driver to a vendor-specific one), the interface version doesn't match. Open Device Manager, find Security devices > Trusted Platform Module 2.0, right-click > Update driver > Browse my computer > Let me pick > select "Microsoft TPM 2.0" (or your vendor's driver, whichever you weren't using). Reboot. The error usually disappears because the driver now speaks the same protocol version.

3. BitLocker stuck in provisioning

If BitLocker is partially enabled and you see this error in a log but not in a dialog, run manage-bde -status. If protection is off for a drive but the converter shows "Encrypted", the TPM key protector is stale. Remove it with manage-bde -protectors -delete C: -type tpm, then add it back with manage-bde -protectors -add C: -tpmsrp. The SRP (Software Restriction Policy) key type is more reliable than plain -tpm in some Windows builds.

Prevention: Avoid this error in the future

• Never upgrade Windows versions with BitLocker off. If you suspend BitLocker during a feature update, re-enable it immediately after. The TPM state change during upgrade is what corrupts the SRK most often.
• Keep your TPM driver on the Microsoft inbox driver unless you have a specific reason to use the vendor one (like an OEM utility that requires it). The inbox driver gets tested more thoroughly across updates.
• Don't clear the TPM in BIOS. It's a nuclear option that forces a full key regeneration and can lock you out of BitLocker if you don't have the recovery key. Use Clear-Tpm with the right provider flag instead.
• If you're writing code that uses the TPM, always call TPM2_CreatePrimary with the same key template on every boot. Store the template hash and reuse it. In C#, use the Tpm2Lib library and pass a consistent AuthValue (even if empty) to avoid parameter mismatches.

That's it. The 0x80290104 error is a paper tiger — it looks scary but has a clean surgical fix. Clear the SRK, move on.