| Previous | Next |
| TPM_E_NOT_FULLWRITE | TPM_E_MAXNVWRITES |
TPM_E_CONTEXT_GAP
Interpret the boundary first
TPM_E_CONTEXT_GAP (0x80280047) belongs to TPM 1.2 resources, delegation and contexts. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks the TPM 1.2 context counter has advanced too far for the saved context blob to be accepted safely.
Build the command transcript
| Question | Evidence for this HRESULT |
|---|---|
| What exact state was rejected? | the TPM 1.2 context counter has advanced too far for the saved context blob to be accepted safely |
| Which layer owns the result? | The TPM resource, context or delegation manager, sometimes mediated by TBS virtualization. |
| What must be correlated? | contextCount values, save/load order, number of intervening saves, boot or ownership events, TBS context identity, and blob age |
| What is the controlled comparison? | save and immediately reload one fresh context before introducing other context churn |
A useful this result trace links three code-specific timelines: the application call, the local TBS/provider or firmware event, and the raw command/response exchange. The result timestamps should describe one attempt; combining data from separate retries is particularly misleading for authorization sessions, context counters, DAA stages and lockout state.
Test one hypothesis
The one-variable check is to save and immediately reload one fresh context before introducing other context churn. Record the before/after state that the result command is allowed to change. If the operation can have side effects, use a disposable key, session, counter or NV index rather than production material.
- Capture this result and
0x80280047at the first code-specific return boundary. - Decode the result state: handle namespace, owning context, save/load history, family state and resource lifetime.
- Run the result controlled comparison once and preserve both binary transcripts.
- Verify the expected this result output or state transition instead of relying on absence of a UI message.
Do not merge these conditions
| Comparison code | Built-in distinction |
|---|---|
TPM_E_NOOPERATOR | No operator AuthData value is set — a separate checkpoint when compared with it. |
TPM_E_BAD_COUNTER | The counter handle is incorrect — a separate checkpoint when compared with it. |
TPM_E_RESOURCEMISSING | The resource pointed to by context is not loaded — a separate checkpoint when compared with it. |
It specifically answers whether the TPM 1.2 context counter has advanced too far for the saved context blob to be accepted safely. In contrast, TPM_E_BADCONTEXT rejects a malformed or invalid blob, while it specifically diagnoses the context-count gap.
A safe recovery path
To remediate it, stop persisting context blobs beyond their supported lifetime and recreate the resource or session after excessive churn. Do not persist volatile TPM or TBS handles as durable identifiers. A numeric handle can be valid only inside the creating context and lifecycle, even when its value looks unchanged after restart.
After correcting it, start with a fresh caller context where the protocol requires one, replay the original intended operation, and confirm that hardware-backed policy remains enforced.
Authoritative references
- Microsoft: Resource Virtualization in TBS — source for the checkpoint.
- Microsoft: Command Scheduling in TBS — source for the checkpoint.
- Microsoft: Using TPM Base Services — source for the checkpoint.
- TCG: TPM 1.2 Part 3 — Context commands — source for the checkpoint.
Looking for a different code? Search another status or error code.