Fix TBSIMP_E_INVALID_CONTEXT_PARAM 0x80290203

You're setting up a new laptop, you hit the Windows Hello fingerprint prompt, and instead of the PIN screen you get a red banner: TBSIMP_E_INVALID_CONTEXT_PARAM (0x80290203). Or you're enabling BitLocker on a ThinkPad T14 and right after you click Turn on BitLocker, the wizard bails with the same code. Sometimes it shows up in Event Viewer under TPM-WMI with no visible prompt at all, and you only find it when device encryption silently refuses to start.

This isn't a Windows bug and it isn't your motherboard dying. It's the TPM subsystem telling the rest of Windows that a command was handed a context blob it doesn't recognize. Fix that mismatch and the error disappears.

What the error actually means

Windows talks to your TPM through a service called the TPM Base Services, or TBS. When an app (Windows Hello, BitLocker, Credential Guard, a biometric driver) wants to do something with the TPM, it opens a context, sends commands, and closes the context. The context is a chunk of state the TPM hands back so it knows which session it's in.

TBSIMP_E_INVALID_CONTEXT_PARAM fires when that swap goes wrong. The caller sends a context handle the TPM doesn't recognize, or the context size doesn't match what the TPM expects, or the TPM was reset (flushed) mid-session and the caller kept using the old handle.

In plain English: your software and your TPM are out of sync. Something reset the chip, or you've got a driver and firmware that speak slightly different dialects of TPM 2.0.

The scenarios that trigger it most often

Firmware updated but the TPM driver wasn't — common after a BIOS flash on Dell Latitude 5000-series and HP EliteBook 800-series laptops.
Windows Hello enrollment on a machine where the TPM was cleared but the biometric service still had a stale session cached.
BitLocker enablement on a VM or a machine with an fTPM (AMD Ryzen 5000/7000 desktops) after a chipset driver roll-back.
Third-party security software (some older endpoint agents) hooking TBS.dll and issuing malformed context calls.
A machine that was restored from an image onto different hardware. The old TPM context is baked into the profile.

The fix, step by step

Do these in order. Don't skip step 1 — half the time it's the whole fix.

Confirm the TPM is even healthy. Press Windows key + R, type tpm.msc, and hit Enter. You should see "The TPM is ready for use" and a spec version (usually 2.0). If it says "The TPM is not ready" or the status is unknown, stop here and check BIOS — the chip might be disabled or hidden.
Clear the TPM. From the same tpm.msc window, click Clear TPM on the right. You'll get a warning that data tied to the TPM will be lost — suspend BitLocker first if it's on, or you'll be typing a 48-digit recovery key at the next boot. After clicking Clear, the machine may reboot. When it comes back, you should see "The TPM is ready for use" again with a fresh state.

If Clear TPM is greyed out, the TPM has an owner and you need to run it from an admin PowerShell: Clear-Tpm
Reinstall the TPM driver. Open Device Manager (right-click Start, Device Manager). Expand Security devices. Right-click your TPM entry (usually labeled "Trusted Platform Module 2.0") and choose Uninstall device. Tick the box to delete driver software if it appears. Reboot. Windows will reinstall a clean driver on the next boot. On some Intel systems the node shows up as "Intel Platform Trust Technology" instead — same procedure.
Register the TPM WMI provider. Open an elevated Command Prompt and run:
```
cd C:\Windows\System32\wbem
regsvr32 /s TpmWmiProvider.dll
```
No output means it worked. An error means the DLL is missing and you've got a corrupted Windows component store — run sfc /scannow and then DISM /Online /Cleanup-Image /RestoreHealth and retry.
Rebuild the TBS service state. Stop the service, delete its cache, start it again:
```
net stop tbs
rd /s /q C:\Windows\System32\LogFiles\TBS
taskkill /f /im tbsvc.exe
net start tbs
```
You should see "The TPM Base Services service was started successfully." If Taskkill reports the process wasn't running, that's fine.
Update TPM firmware. Check your PC maker's support site. Dell, HP, Lenovo, and Microsoft Surface all publish TPM firmware updaters separate from BIOS. On Surface devices, the firmware ships through Windows Update, so just run Settings → Windows Update → Check for updates and let it finish. After the flash, repeat step 1 to confirm the TPM still reports ready.
Reboot and retry the original action. Re-enroll Windows Hello from Settings → Accounts → Sign-in options, or turn BitLocker back on. If it completes without the red banner, you're done.

If it still fails

Run a targeted retry and watch the event log at the same time. Open Event Viewer, expand Applications and Services Logs → Microsoft → Windows → TPM, and reproduce the error. The event details often name the specific context bytes the TPM rejected, and that tells you which app is at fault.

Check these three things next:

Group Policy or registry locks. If you're on a managed machine, an admin may have disabled TPM use. Check HKLM\SYSTEM\CurrentControlSet\Control\Integrity — a TPM policy key here can block context creation. Worth a quick look before you spend an hour chasing hardware.
Third-party TPM hooks. Uninstall any endpoint security agent temporarily, or boot into Safe Mode and try the failing action there. If it works in Safe Mode, a driver is intercepting the TBS call.
Hardware fault. If Clear TPM fails outright, or the chip drops off Device Manager after a reboot, the TPM module itself is failing. On desktops with a discrete TPM (Asus, Gigabyte boards), reseat or replace the module. On laptops, that means a board-level repair — open a warranty case.

One more thing. If this machine was imaged from another system, don't fight it. Sysprep with /generalize and start clean. Cloned TPM state causes exactly this error and no amount of driver reinstalling will fix it.