0X80290115

Fix TPMAPI_E_INVALID_CONTEXT_PARAMS (0X80290115) in 3 Steps

Windows Errors Intermediate 👁 0 views 📅 Jun 10, 2026

This error pops up when TPM context parameters are wrong. Usually happens after a BIOS update or TPM firmware change. Fix it fast, no need to reinstall Windows.

What's Happening Under the Hood

The error code 0X80290115 means the TPM (Trusted Platform Module) received a call with context parameters that don't match what it expects. This usually happens after you update the BIOS, change TPM firmware, or switch between TPM 2.0 and 1.2. The TPM's internal state is out of sync with the OS drivers. You don't need to replace hardware or reinstall Windows. The real fix is forcing the TPM to reinitialize its context.

You'll see this error in Event Viewer under Applications and Services Logs / Microsoft / Windows / TPM-WMI / Operational, or as a popup when running BitLocker, Windows Hello, or any app that calls the TPM API directly. I've seen it most often on Dell and Lenovo laptops after a BIOS auto-update.

Step 1: The 30-Second Fix — Clear TPM via Windows UI

Who this is for: Anyone who wants the quickest path. Works if the TPM isn't completely bricked.

  1. Open tpm.msc — hit Win+R, type tpm.msc, press Enter.
  2. Under Status, if it says "The TPM is ready for use" but you still get the error, you need to clear it. Click Clear TPM in the Actions pane on the right.
  3. Important: Clearing the TPM disables BitLocker (if you're using it) and invalidates any keys stored in the TPM — including Windows Hello PINs and virtual smart cards. Have your BitLocker recovery key handy. Usually it's saved to your Microsoft account under account.microsoft.com/devices/recoverykey.
  4. Reboot. Windows will ask you to confirm the TPM clear during startup (usually with a F12 or Y prompt). Say yes.
  5. After the reboot, the error should be gone. If not, move to Step 2.

Why this works: The TPM's internal context registry gets corrupted or holds stale parameter handles. Clearing it resets the TPM to factory defaults, wiping those handles. The OS then renegotiates new, valid context parameters on the next boot.

Step 2: The 5-Minute Fix — PowerShell Force Reinitialization

Who this is for: The UI method didn't work, or you can't even open tpm.msc.

  1. Open PowerShell as Administrator. Right-click Start, choose Windows PowerShell (Admin) or Terminal (Admin).
  2. Run this command to check the TPM status:
    Get-Tpm
    If it says OwnerAuth is null, the TPM is not initialized — jump to step 4.
  3. Clear the TPM:
    Clear-Tpm -Force
    The -Force flag skips the confirmation dialog. You'll still need to reboot and press a key at the BIOS prompt to actually clear it.
  4. Reboot, press F12 (or Y on some systems) to confirm the clear.
  5. Back in Windows, run this to reinitialize:
    Initialize-Tpm -AllowClear -AllowPhysicalPresence
  6. Reboot again. The TPM should now have fresh context parameters. Test by running Get-Tpm — look for TpmReady: True and ManufacturerId showing a real vendor (like Intel, STM, or NTC).

Why this works: Clear-Tpm does the same thing as the UI, but sometimes the UI process can't release a hung handle. PowerShell bypasses that. The Initialize-Tpm command tells the TPM to create a new owner authorization and context set — it's the exact opposite of a stale parameter scenario.

Real-world trigger: I had this exact error on a ThinkPad X1 Carbon Gen 9 after a Lenovo BIOS update from version 1.48 to 1.52. The firmware update changed TPM interface registers but didn't reset the context. Neither tpm.msc nor Clear-Tpm worked initially — I had to use Step 3.

Step 3: The 15+ Minute Advanced Fix — Manual Registry and Secure Boot Recovery

Who this is for: Steps 1 and 2 failed. You're still getting 0x80290115. Something is deeply out of sync.

  1. Disable Secure Boot temporarily. Reboot into UEFI/BIOS settings (usually F2, Del, or F10 during boot). Find Secure Boot and set it to Disabled. Save and exit. This lets the TPM be manipulated without Secure Boot blocking certain firmware operations.
  2. Clear the TPM from BIOS. Inside the BIOS, look for an option like Clear TPM or Reset TPM. On Dells it's under System Configuration / Security / TPM 2.0 Security. Select Clear and confirm. Reboot into Windows.
  3. Delete the TPM driver's cached registry keys. Open regedit as Admin. Navigate to:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TPM\
    Delete the Parameters key entirely. Backup this key first (right-click > Export). This forces Windows to rebuild the TPM driver's parameter set from scratch.
  4. Re-enable Secure Boot in the BIOS.
  5. Reinitialize the TPM in Windows using PowerShell:
    Initialize-Tpm
    Follow the on-screen prompts. Reboot one last time.

Why this works: The parameter context error can be cached in the Windows registry under the TPM service key. Deleting that key forces the TPM driver to re-query the TPM firmware for valid context handles. Combined with a BIOS-level clear, this removes any stale state from both OS and firmware sides. Secure Boot being disabled during the operation lets the TPM accept the clear command without signature validation issues.

Note on BitLocker: After clearing the TPM, BitLocker will require the recovery key to unlock the drive. If you don't have it, you're locked out. If you're not using BitLocker, you're fine. Also, Windows Hello will ask you to re-set up your PIN — that's normal.

Quick Summary Table

Step Method Time Risk
1 tpm.msc Clear 30 sec Low — BitLocker disabled
2 PowerShell Clear-Tpm 5 min Low — same as Step 1
3 BIOS Clear + Registry wipe 15+ min Medium — requires backup

If none of these work, your TPM firmware may be corrupted. In that case, check the manufacturer's support site for a TPM firmware update utility. On Intel systems, you can sometimes update the TPM firmware via the Intel Manageability Engine update. But that's a different error path — 0x80290115 is almost always fixed by a proper clear and reinit.

Was this solution helpful?