TPM_E_NOCONTEXTSPACE (0X80280063) Fix: No Room in Context List

1. BitLocker Has Locked Up the TPM Context List (Most Common)

Had a client last month whose entire laptop refused to boot past the BitLocker recovery screen. The event log showed TPM_E_NOCONTEXTSPACE (0x80280063). Turns out, BitLocker's encryption operations had filled every slot in the TPM's context list. The TPM can only hold a limited number of cryptographic contexts at once — think of it like a tiny notepad with 100 pages. Once it's full, new requests (like decryption or attestation) get rejected with this error.

The quick fix: clear the TPM context space without touching the TPM itself. This won't break BitLocker if done right.

Step-by-Step: Clear TPM Context List

1. Open PowerShell as Administrator. Don't use Command Prompt — PowerShell gives you Clear-Tpm cmdlet directly.
2. Run: Clear-Tpm. This wipes all contexts, not the TPM keys. BitLocker will reinitialize its contexts on next boot.
3. Reboot. Test if the error reappears. Most of the time it's gone.

If Clear-Tpm fails, run Get-Tpm first to check if the TPM is provisioned. If it shows True for TpmReady, the cmdlet should work. If it gives you an error like "The device is not ready," you've got a driver issue — move to cause #2.

2. Stale or Buggy TPM Drivers (Especially on Windows 10 21H2)

I see this a lot on older Dell OptiPlex 7070s and Lenovo ThinkCentre M720q. The TPM driver from 2020 doesn't release contexts properly after use. Each time Windows requests a TPM operation, the driver leaks a context slot. After a few weeks, you hit the wall.

The fix: update the TPM driver to the latest from your OEM, not from Windows Update. Windows Update often pushes a generic driver that doesn't handle context cleanup well.

Update TPM Driver Manually

1. Press Win + X and pick Device Manager.
2. Expand Security devices — you'll see "Trusted Platform Module 2.0" or similar.
3. Right-click it, choose Update driver > Browse my computer for drivers > Let me pick from a list.
4. Select the Microsoft driver from 2021 or later (dated 6/21/2021 or newer). If you have an OEM driver dated 2019 or older, switch to the Microsoft one.
5. Reboot.

I've seen this fix stick for years. On one HP EliteBook 840 G3, the OEM driver from 2018 caused the error every 3 months. Switching to Microsoft's 2021 driver ended the problem completely.

3. Too Many Active TPM Sessions From Multiple Apps

Sometimes it's not BitLocker or drivers — it's apps that hold TPM contexts open like they're saving seats at a busy bar. Common offenders:

• Virtual TPMs in Hyper-V or VMware Workstation
• Windows Defender System Guard (especially with Secure Launch enabled)
• Third-party encryption software (McAfee, Symantec endpoint encryption)
• Azure AD join processes that keep TPM handles open for device authentication

The TPM 2.0 spec allows up to 64 sessions (contexts) at once. Once you hit that limit, new requests fail with 0x80280063. The solution: kill the apps that are hogging handles, or reboot to clear them.

Identify and Free TPM Contexts

1. Open PowerShell as Admin.
2. Run Get-Tpm | Select-Object -ExpandProperty MaxContextCount — this shows your TPM's max context slots (usually 64).
3. Run Get-Tpm | Select-Object -ExpandProperty UsedContextCount — if this is close to the max, you're full.
4. Find the culprit: run Get-Tpm | Format-List * and look for ContextList — it'll show which processes/sessions have handles. It's not always readable, but if you see multiple entries from the same PID, that's your app.
5. Close the offending app. If it's a service, stop it: Stop-Service -Name "YourServiceName".
6. Check used count again — it should drop.

In a pinch, a reboot always resets the context list to zero. But if an app reopens contexts on startup, you'll need to reconfigure it. For Hyper-V VMs, reduce the number of active VMs or disable nested virtualization temporarily.

Quick-Reference Summary

Bottom line: Start with Clear-Tpm — it's the fastest fix and works for most people. If that doesn't stick, update the driver. Only dig into app-specific handles if the error keeps coming back after a reboot. This isn't a hardware failure — it's just software not playing nice with the TPM's limits.