| Previous | Next |
| TPM_E_KEY_OWNER_CONTROL | TPM_E_NOT_FULLWRITE |
TPM_E_BAD_COUNTER
The decisive TPM checkpoint
TPM_E_BAD_COUNTER (0x80280045) 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 monotonic-counter handle does not identify the counter expected by the TPM 1.2 command.
The first producer to identify for this HRESULT is the TPM resource, context or delegation manager, sometimes mediated by TBS virtualization. TBS can virtualize finite TPM resources, but a saved TPM context and a TBS virtual handle are not durable application IDs. Their validity depends on resource type, owning client context, TPM lifecycle and the exact save/load history.
Before changing the platform
Preserve these this result items before changing anything:
- This result and
0x80280045, the exact returning method or command, and the first nested status. - counter handle, label, creation and release history, owner state, saved application mapping, and whether the TPM was cleared.
- The TPM generation, manufacturer/firmware revision, Windows build, caller identity and TBS/provider state for this HRESULT.
- The complete opaque request artifacts, redacting authorization secrets but not rewriting structure boundaries.
Test the contract
Run this focused check: enumerate current counter information and create a disposable counter instead of trusting a persisted handle. Do not combine the result test with firmware updates, TPM clearing, account changes, key recreation and policy edits in the same trial; such a result cannot isolate this boundary.
| Checkpoint | Pass condition |
|---|---|
| the monotonic-counter handle does not identify the counter expected by the TPM 1.2 command | The original this result command reaches the next defined state without returning it. |
| Security behavior | The result verification still uses the intended TPM, authorization, locality and policy. |
| Output integrity | The object, digest, event log or state transition produced after it validates independently. |
Why another code is not equivalent
| Related result | Separate meaning |
|---|---|
TPM_E_CONTEXT_GAP | The gap between saved context counts is too large — a separate checkpoint when compared with it. |
TPM_E_KEY_OWNER_CONTROL | The key is under control of the TPM Owner and can only be evicted by the TPM Owner — a separate checkpoint when compared with it. |
TPM_E_NOOPERATOR | No operator AuthData value is set — a separate checkpoint when compared with it. |
The practical distinction is that TPM_E_BAD_HANDLE is broader; it identifies the monotonic-counter namespace.
Evidence of success
The supported direction is to refresh the counter handle after lifecycle changes and store a stable application identifier separately. 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.
If the same bytes still return it after the documented preconditions are satisfied, retain this code-specific trace for the platform vendor or Windows component owner rather than erasing state.
Technical 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.