0X80284009

TBS_E_TOO_MANY_TBS_CONTEXTS (0X80284009) Fix

You're hitting the TPM's context limit, usually from leftover Trusted Platform Module sessions. Here's how to clear them and stop it coming back.

This error means your TPM is full of hanging contexts

The error TBS_E_TOO_MANY_TBS_CONTEXTS (0X80284009) shows up when something—often BitLocker, Windows Hello, or a misbehaved app—opens TPM contexts (abstract sessions that hold cryptographic state) and never closes them. The TPM 2.0 chip in your machine can hold around 100 to 200 contexts at once, but once you hit the limit, anything new fails. You'll see this in Event Viewer, in PowerShell when you try to read TPM data, or when a program that relies on the TPM just silently refuses to work.

The real fix: drain the contexts via PowerShell

Skip the reboot dance—that sometimes works but only because the TBS (TPM Base Services) service resets and drops all contexts. The more reliable method is to flush the contexts directly. You'll need admin rights.

  1. Open PowerShell as Administrator.
  2. Run Stop-Service TBS -Force. This kills the TPM Base Services service, which is the Windows-side manager for TPM contexts. The contexts live in kernel memory managed by TBS, so stopping it terminates them.
  3. Wait 2 seconds, then run Start-Service TBS. That restarts the service clean.
  4. Verify: Get-Tpm should return a healthy status without errors.

If Get-Tpm still shows errors, try a full TPM clear—but only if you've backed up your BitLocker recovery keys and Windows Hello credentials. Run Clear-Tpm in the same admin PowerShell. This resets the TPM to factory state, wiping all contexts and keys. Then reboot and re-enable BitLocker or reconfigure Hello.

What's actually happening here

The TPM chip itself has a fixed number of context slots. Each slot can hold a session—like a BitLocker encryption key, a Windows Hello PIN verification state, or a virtual smart card authentication context. The TBS service manages these slots on Windows. When an application opens a context but doesn't close it (maybe it crashed, or the programmer forgot to call Tbsip_Context_Close), the slot stays occupied. Over time, especially if you have multiple apps hitting the TPM, you fill up.

The reason step 3 works is that restarting TBS doesn't just restart the service—it tears down the kernel-mode TPM driver stack and rebuilds it. That forces all contexts to be released, even the leaky ones. It's like turning the lights off and on again, but at the driver level.

Less common variations of the same issue

Virtual machines and nested TPMs

If you're running Hyper-V with a virtual TPM (vTPM) for a VM, the host TPM's context limit can also be hit by vTPM operations. The fix is the same, but you'll also want to shut down the VM that's using the vTPM first. After restarting TBS on the host, restart the VM. This is common on Windows 10/11 Pro or Enterprise with nested virtualization.

Third-party apps that hammer TPM

Some old VPN clients or custom encryption software open contexts repeatedly without closing them. If the error returns days later, check Task Manager's services tab for any process that calls TPM or BitLocker related DLLs. Tools like Process Monitor can filter for Tbsip_Context_Open calls. Kill that process, then repeat the flush.

BitLocker's hidden context leak

On some systems with BitLocker and suspend/resume cycles (laptops), BitLocker may leave contexts open after turning off BitLocker protection temporarily for a firmware update. The permanent fix is to suspend BitLocker completely (Suspend-BitLocker -MountPoint "C:" -RebootCount 0), then restart TBS, then resume BitLocker. This clears the BitLocker-specific contexts that hang around.

Preventing this from coming back

The root cause is always a leaky application or driver that doesn't close TPM contexts. You can't change the TPM's slot limit—that's hardware—but you can track down the culprit.

  • Monitor TPM context usage: PowerShell script to check current context count? There's no direct cmdlet, but you can poll Get-CimInstance Win32_Tpm -Namespace root/cimv2/Security/MicrosoftTpm and look for orphaned sessions. If that returns nothing useful, fall back to checking the System event log for TBS warnings (Event ID 519, 520).
  • Update your TPM firmware: Motherboard manufacturers sometimes ship buggy TPM firmware that leaks contexts. Check your BIOS vendor (Dell, Lenovo, HP, ASUS, etc.) for a TPM firmware update. This is rare but worth a shot if the error persists after clearing everything.
  • Reduce the number of TPM-reliant features: If you don't need Windows Hello or BitLocker, you can turn them off. But that's a nuclear option—most people need at least BitLocker. Instead, identify the specific app that's misbehaving and either update it or replace it.

I've seen this error most on Dell Latitude laptops after a Windows 11 22H2 upgrade, where the built-in fingerprint reader driver left contexts open on every scan. The fix in that case was updating the Dell ControlVault driver to version 4.0.9 or later. If you don't know what's leaking, updating all TPM-related drivers (Intel MEI, TPM driver from your OEM) often resolves it.

One last thing: don't bother with the registry key HKLM\SYSTEM\CurrentControlSet\Services\TBS\Parameters—there's no MaxContexts value you can tweak. That's a myth. The TPM chip's slot count is fixed in hardware, and Windows doesn't let you override it.

Related Errors in Windows Errors
0X00000963 Fix 0X00000963 (NERR_BadPasswordCore): Share Name or Password Invalid 0X00001AA4 Fix ERROR_ENLISTMENT_NOT_SUPERIOR (0X00001AA4) on Windows 10/11 0X80110600 COMQC_E_APPLICATION_NOT_QUEUED (0X80110600): Fix Queued Moniker Error 0XC0000129 STATUS_TOO_MANY_THREADs 0XC0000129: The Real Fixes

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.