| Previous | Next |
| E_SKYDRIVE_ROOT_TARGET_VOLUME_ROOT_NOT_SUPPORTED | TPM_E_AUTHFAIL |
TPM_E_ERROR_MASK
Read the result in context
TPM_E_ERROR_MASK (0x80280000) belongs to HRESULT decoding and logging. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks the HRESULT bit pattern used to recognize Windows mappings of TPM hardware responses, not a command outcome by itself.
The first producer to identify for it is Windows error classification rather than TPM command execution. Windows defines masks alongside concrete HRESULT values so software can classify facilities and embedded device responses. The mask has no independent command checkpoint, retry rule or remediation.
Fields worth decoding
| Question | Evidence for it |
|---|---|
| What exact state was rejected? | the HRESULT bit pattern used to recognize Windows mappings of TPM hardware responses, not a command outcome by itself |
| Which layer owns the result? | Windows error classification rather than TPM command execution. |
| What must be correlated? | the original 32-bit value before a wrapper converts it to signed decimal, plus the low TPM response-code bits and the API that surfaced it |
| What is the controlled comparison? | apply the mask to a captured HRESULT and separately decode the embedded TPM return code; do not issue a TPM command merely to reproduce the mask constant |
Record the original command or API call before this result retry logic mutates its nonces, handles, buffers or state. Also retain the full HRESULT as 0x80280000; signed decimal logging can hide the result TPM/TBS facility and make searches less precise.
Controlled comparison
- Establish the result baseline with the same device, Windows build, account and TPM generation.
- Perform one narrow experiment: apply the mask to a captured HRESULT and separately decode the embedded TPM return code; do not issue a TPM command merely to reproduce the mask constant.
- Compare raw this result inputs and the first response, not only the final application dialog.
- Stop after the first changed the checkpoint; a later error means this boundary was passed even if the whole workflow still fails.
Adjacent failure boundaries
| Result | Different diagnostic question |
|---|---|
TPM_E_FAIL | The operation failed — a separate checkpoint when compared with this result. |
TPM_E_SHA_THREAD | There is no existing SHA-1 thread — a separate checkpoint when compared with it. |
TPM_E_SHA_ERROR | The calculation is unable to proceed because the existing SHA-1 thread has already encountered an error — a separate checkpoint when compared with it. |
The decisive distinction for it is that a concrete TPM_E_* value describes a failed checkpoint; this mask only classifies a family of values. The short platform wording — “This is an error mask to convert TPM hardware errors to win errors.” — does not supply that differential diagnosis by itself.
Repair without destroying evidence
The corrective direction is to change the decoder or telemetry schema so it preserves the full hexadecimal value and then diagnose the actual embedded TPM code. Do not report the mask constant as if the TPM returned it. A mask is useful for classification only after the complete HRESULT has been retained.
A verified it repair reproduces the original request with the same intended security policy and passes this checkpoint. Replacing it with a broader wrapper status, silently falling back to software keys, or suppressing verification is not proof of success.
Technical references
- TCG: TPM 1.2 Main Specification — source for the checkpoint.
- TCG: TPM 1.2 Part 2 — Structures — source for the checkpoint.
- TCG: TPM 1.2 Part 3 — Commands — source for the checkpoint.
- Microsoft: TPM Base Services portal — source for the checkpoint.
Looking for a different code? Search another status or error code.