| Previous | Next |
| TBS_E_NO_EVENT_LOG | TBS_E_PROVISIONING_NOT_ALLOWED |
TBS_E_ACCESS_DENIED
Technical interpretation
TBS_E_ACCESS_DENIED (0x80284012) belongs to the public and internal TPM Base Services path. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks Windows denied the caller permission to perform the selected TBS operation or command class.
The first producer to identify for TBS_E_ACCESS_DENIED is the TBS client library, local RPC service and command scheduler before or around device execution. For TBS_E_ACCESS_DENIED, tBS centralizes TPM access through a local RPC service. For TBS_E_ACCESS_DENIED, a failure can therefore occur in the caller contract, RPC/service startup, scheduling, buffer handling or TPM submission, and each layer requires different evidence.
Inputs and state to capture
Preserve these TBS_E_ACCESS_DENIED items before changing anything:
TBS_E_ACCESS_DENIEDand0x80284012, the exact returning method or command, and the first nested status.- caller token, integrity level, app-container state, command ordinal, TBS policy, process identity, and whether a higher-level API is available.
- The TPM generation, manufacturer/firmware revision, Windows build, caller identity and TBS/provider state for
TBS_E_ACCESS_DENIED. - The complete opaque
TBS_E_ACCESS_DENIEDrequest artifacts, redacting authorization secrets but not rewriting structure boundaries.
Validate without broad changes
Run this focused check: run a harmless allowed TBS call under the same token and compare with the protected operation without elevating the whole application. Do not combine the TBS_E_ACCESS_DENIED test with firmware updates, TPM clearing, account changes, key recreation and policy edits in the same trial; such a result cannot isolate this boundary.
| Checkpoint | Pass condition |
|---|---|
| Windows denied the caller permission to perform the selected TBS operation or command class | The original TBS_E_ACCESS_DENIED command reaches the next defined state without returning this result. |
| Security behavior | The TBS_E_ACCESS_DENIED verification still uses the intended TPM, authorization, locality and policy. |
| Output integrity | The object, digest, event log or state transition produced after TBS_E_ACCESS_DENIED validates independently. |
Neighboring response codes
| Related result | Separate meaning |
|---|---|
TBSIMP_E_BUFFER_TOO_SMALL | The specified buffer was too small — a separate checkpoint when compared with TBS_E_ACCESS_DENIED. |
TBS_E_BUFFER_TOO_LARGE | The input or output buffer is too large — a separate checkpoint when compared with TBS_E_ACCESS_DENIED. |
TBSIMP_E_CLEANUP_FAILED | The context could not be cleaned up — a separate checkpoint when compared with TBS_E_ACCESS_DENIED. |
The practical distinction is that TPM_E_COMMAND_BLOCKED is command-policy denial after TBS examines the command; this result is the public access-control failure.
Fix and verify
The supported direction is to use the documented privilege boundary or a higher-level key API and grant only the minimum required access. For TBS_E_ACCESS_DENIED, do not restart or disable TBS before capturing its service and event data. For TBS_E_ACCESS_DENIED, most caller-contract errors are reproducible without touching TPM ownership, firmware state or stored keys.
If the same bytes still return TBS_E_ACCESS_DENIED after the documented preconditions are satisfied, retain this code-specific trace for the platform vendor or Windows component owner rather than erasing state.
Technical references
- Microsoft: About TPM Base Services — source for the
TBS_E_ACCESS_DENIEDcheckpoint. - Microsoft: TBS return codes — source for the
TBS_E_ACCESS_DENIEDcheckpoint. - Microsoft: Tbsi_Context_Create — source for the
TBS_E_ACCESS_DENIEDcheckpoint. - Microsoft: Tbsip_Submit_Command — source for the
TBS_E_ACCESS_DENIEDcheckpoint.
Looking for a different code? Search another status or error code.