Site icon EfmSoft

What does HRESULT 0x80290205 (TBSIMP_E_HASH_BAD_KEY) mean?

 
Previous Next
TBSIMP_E_TPM_ERROR TBSIMP_E_DUPLICATE_VHANDLE

TBSIMP_E_HASH_BAD_KEY

What failed and what did not

TBSIMP_E_HASH_BAD_KEY (0x80290205) belongs to TBS resource virtualization. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks an internal TBS hash table lookup cannot find the key that should identify a context, resource or mapping entry.

The first producer to identify for this HRESULT is the TBS context and virtual-resource manager that maps finite TPM slots for multiple clients. TBS resource virtualization maps client-visible virtual handles to finite physical TPM key, authorization and transport slots. Cleanup, eviction and context ownership determine whether a mapping can be restored.

Read this result as its own boundary in a sequence, not as a verdict that every TPM feature is broken. The sequence reaches an internal TBS hash table lookup cannot find the key that should identify a context, resource or mapping entry, and the component returns 0x80290205 before the application can safely assume that later key, attestation, boot or licensing work occurred.

Collect a useful trace

Narrow experiment

Repeat with one newly created resource and no concurrent context operations. Keep every other this result test condition unchanged. If the comparison reaches a later checkpoint, then the original the condition has been isolated even when a second defect remains.

Observed outcomeInterpretation
The exact request succeedsThe changed condition belongs to the rejected an internal TBS hash table lookup cannot find the key that should identify a context, resource or mapping entry.
A more specific earlier code appearsPreserve the earlier result in the result trace; the previous trace probably lost the first producer.
The same code returns with identical bytesEscalate the persistent it with firmware, service and command evidence rather than broad configuration changes.
The code disappears only after destructive resetThe result experiment is not diagnostic because original protected state and evidence were removed.

Similar-looking outcomes

Nearby constantWhy it is different
TBSIMP_E_DUPLICATE_VHANDLEThe specified virtual handle matches a virtual handle already in use — a separate checkpoint when compared with it.
TBSIMP_E_INVALID_CONTEXT_PARAMAn invalid context parameter was specified — a separate checkpoint when compared with it.
TBSIMP_E_LIST_NO_MORE_ITEMSThe specified list is empty, or the iteration has reached the end of the list — a separate checkpoint when compared with it.

For this page, the useful contrast is: TBSIMP_E_LIST_NOT_FOUND is a list lookup failure rather than a hash-table key miss.

Operational response

Apply the narrow remedy: correct lifetime races in the caller and preserve logs for a reproducible service mapping defect. Do not confuse a TBS virtual handle with a physical TPM handle or copy it to another process. Resource virtualization intentionally scopes mappings to a client context.

Close the incident only when the same API or TPM command passes with the intended hardware-backed behavior and the expected output can be independently validated.

References


Looking for a different code? Search another status or error code.

Exit mobile version