| Previous | Next |
| TPM_E_DAA_WRONG_W | TPM_E_BAD_DELEGATE |
TPM_E_BAD_HANDLE
Locate the first producer
TPM_E_BAD_HANDLE (0x80280058) 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 a TPM 1.2 command handle does not identify a valid object, session, counter or other resource for that command.
Data to retain
| Question | Evidence for this HRESULT |
|---|---|
| What exact state was rejected? | a TPM 1.2 command handle does not identify a valid object, session, counter or other resource for that command |
| Which layer owns the result? | The TPM resource, context or delegation manager, sometimes mediated by TBS virtualization. |
| What must be correlated? | handle value, handle namespace, creating command, TBS virtual mapping, owning context, flush history, and power-cycle boundary |
| What is the controlled comparison? | create a fresh object of the required type and use the returned handle immediately in the same context |
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.
Verification sequence
The one-variable check is to create a fresh object of the required type and use the returned handle immediately in the same context. 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
0x80280058at 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.
Codes that answer different questions
| Comparison code | Built-in distinction |
|---|---|
TPM_E_BAD_DELEGATE | Delegation is not correct — a separate checkpoint when compared with it. |
TPM_E_OWNER_CONTROL | Attempt to context save a owner evict controlled key — a separate checkpoint when compared with it. |
TPM_E_BADCONTEXT | The context blob is invalid — a separate checkpoint when compared with it. |
It specifically answers whether a TPM 1.2 command handle does not identify a valid object, session, counter or other resource for that command. In contrast, TPM_E_INVALID_AUTHHANDLE is limited to authorization sessions, while it is a broader handle failure.
Exit condition for the incident
To remediate it, stop persisting volatile handles and refresh them after flush, context close, service restart, sleep or reboot. 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.