What does HRESULT 0x80280009 (TPM_E_FAIL) mean?

 
Previous Next
TPM_E_DISABLED_CMD TPM_E_BAD_ORDINAL

TPM_E_FAIL

Read the result in context

TPM_E_FAIL (0x80280009) belongs to TPM 1.2 command processing. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks the TPM 1.2 command reached a generic internal failure path after accepting enough of the request to start processing it.

The first producer to identify for TPM_E_FAIL is the TPM 1.2 command decoder and state machine. For TPM_E_FAIL, tPM 1.2 is a command/response device with strict binary structures and stateful resources. For TPM_E_FAIL, windows may present the device response as an HRESULT, but the diagnostic meaning still belongs to the command field, key, session, PCR, NV index or lifecycle check named by the TPM specification.

Fields worth decoding

QuestionEvidence for TPM_E_FAIL
What exact state was rejected?the TPM 1.2 command reached a generic internal failure path after accepting enough of the request to start processing it
Which layer owns the result?For TPM_E_FAIL, the TPM 1.2 command decoder and state machine.
What must be correlated?the command ordinal, request tag, parameter digest, power-transition history, vendor firmware revision, and any earlier self-test or transport event
What is the controlled comparison?submit the same command once through a minimal TBS context and compare it with a different known-good TPM command on the same device

For TPM_E_FAIL, record the original command or API call before TPM_E_FAIL retry logic mutates its nonces, handles, buffers or state. Also retain the full HRESULT as 0x80280009; signed decimal logging can hide the TPM_E_FAIL TPM/TBS facility and make searches less precise.

Controlled comparison

  1. Establish the TPM_E_FAIL baseline with the same device, Windows build, account and TPM generation.
  2. Perform one narrow experiment: submit the same command once through a minimal TBS context and compare it with a different known-good TPM command on the same device.
  3. Compare raw TPM_E_FAIL inputs and the first response, not only the final application dialog.
  4. Stop after the first changed TPM_E_FAIL checkpoint; a later error means this boundary was passed even if the whole workflow still fails.

Adjacent failure boundaries

ResultDifferent diagnostic question
TPM_E_SHA_THREADThere is no existing SHA-1 thread — a separate checkpoint when compared with TPM_E_FAIL.
TPM_E_SHA_ERRORThe calculation is unable to proceed because the existing SHA-1 thread has already encountered an error — a separate checkpoint when compared with TPM_E_FAIL.
TPM_E_BADTAGThe tag value sent to for a command is invalid — a separate checkpoint when compared with TPM_E_FAIL.

The decisive distinction for TPM_E_FAIL is that TPM_E_IOERROR reports host-to-TPM transfer trouble, while TPM_E_FAIL is a TPM-side command failure without a narrower legacy code. The short platform wording — “The operation failed.” — does not supply that differential diagnosis by itself.

Repair without destroying evidence

The corrective direction is to preserve the first response, update platform firmware where appropriate, and escalate with the exact command transcript rather than clearing ownership. For TPM_E_FAIL, do not clear ownership, delete keys or reset PCR-related state merely to see whether the message disappears; those actions can destroy the evidence and protected material while leaving serialization or command-order defects unchanged.

A verified TPM_E_FAIL repair reproduces the original request with the same intended security policy and passes this checkpoint. Replacing TPM_E_FAIL with a broader wrapper status, silently falling back to software keys, or suppressing verification is not proof of success.

Technical references


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