| Previous | Next |
| TPM_E_INVALID_HANDLE | TPM_E_EMBEDDED_COMMAND_BLOCKED |
TPM_E_DUPLICATE_VHANDLE
Interpret the boundary first
TPM_E_DUPLICATE_VHANDLE (0x80280402) belongs to Windows command mediation around the TPM. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks TBS received a TPM result that would create a virtual handle already present in the client mapping.
The first producer to identify for it is TBS command blocking, virtual-handle translation, retry or anti-hammering logic. Windows TBS schedules and mediates commands from multiple clients. It can block commands, translate virtual handles, request retry, and preserve anti-hammering policy before or after the raw device command path.
Build the command transcript
| Question | Evidence for it |
|---|---|
| What exact state was rejected? | TBS received a TPM result that would create a virtual handle already present in the client mapping |
| Which layer owns the result? | TBS command blocking, virtual-handle translation, retry or anti-hammering logic. |
| What must be correlated? | returned physical handle, existing virtual mapping, command code, context identity, resubmission history, and preceding resource-load responses |
| What is the controlled comparison? | close the test context, create a new context and submit the command once without replaying a cached response |
Separate caller data from platform state. The result caller data includes the command, structures, lengths, handles and flags; platform state includes TPM generation, provisioning, locality, lockout, resource inventory, firmware and the TBS service lifecycle. This result is actionable only after the rejected side is identified.
Test one hypothesis
Use the following verification sequence:
- Capture the unmodified failing input and
0x80280402. - Close the test context, create a new context and submit the command once without replaying a cached response.
- Compare the first result divergent field or state transition.
- Repeat this result only after restoring the same baseline, with a bounded retry policy where the specification permits retry.
Do not merge these conditions
| Other code | Why a different remedy follows |
|---|---|
TPM_E_EMBEDDED_COMMAND_BLOCKED | The command within the transport was blocked — a separate checkpoint when compared with this result. |
TPM_E_INVALID_HANDLE | The specified handle was not found — a separate checkpoint when compared with it. |
TPM_E_EMBEDDED_COMMAND_UNSUPPORTED | The command within the transport is not supported — a separate checkpoint when compared with it. |
TBSIMP_E_DUPLICATE_VHANDLE is the internal implementation-layer counterpart. The result difference determines whether to change serialization, authorization, resource lifetime, firmware/PPI state, command policy or only retry timing.
A safe recovery path
Correct the original boundary by choosing this direction: discard the inconsistent mapping and resubmit through a fresh context; investigate firmware or duplicate command delivery if it recurs. Do not disable command policy globally to make one test pass. First establish the caller, command code and supported higher-level alternative, because command blocking is a security boundary.
A successful it outcome preserves the intended hardware trust boundary, passes the original request, and produces verifiable output. Masking it, swallowing this HRESULT or switching silently to a software provider is not remediation.
References used for this checkpoint
- Microsoft: Command Blocking in TBS — source for the checkpoint.
- Microsoft: Using TPM Base Services — source for the checkpoint.
- Microsoft: Tbsip_Submit_Command — source for the checkpoint.
- TCG: TPM 1.2 Main Specification — source for the checkpoint.
Looking for a different code? Search another status or error code.