| Previous | Next |
| TPM_E_CONTEXT_GAP | TPM_E_NOOPERATOR |
TPM_E_MAXNVWRITES
What failed and what did not
TPM_E_MAXNVWRITES (0x80280048) belongs to TPM 1.2 nonvolatile-storage policy. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks the TPM 1.2 limit for owner-independent NV writes has been reached for the current lifecycle.
The first producer to identify for this HRESULT is the TPM 1.2 NV permission and lifecycle checks. TPM 1.2 NV indices combine permissions, authorization mode, locality masks and lock semantics. Two indices of the same size can behave differently because those attributes were fixed when each index was defined.
Collect a useful trace
| Question | Evidence for this HRESULT |
|---|---|
| What exact state was rejected? | the TPM 1.2 limit for owner-independent NV writes has been reached for the current lifecycle |
| Which layer owns the result? | The TPM 1.2 NV permission and lifecycle checks. |
| What must be correlated? | index attributes, authorization mode, successful write count, owner state, boot or reset events, and the exact command sequence |
| What is the controlled comparison? | compare an owner-authorized disposable write with an unauthenticated or owner-independent path without consuming production indices |
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 0x80280048; signed decimal logging can hide the result TPM/TBS facility and make searches less precise.
Narrow experiment
- Establish the result baseline with the same device, Windows build, account and TPM generation.
- Perform one narrow experiment: compare an owner-authorized disposable write with an unauthenticated or owner-independent path without consuming production indices.
- 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.
Similar-looking outcomes
| Result | Different diagnostic question |
|---|---|
TPM_E_NOT_FULLWRITE | The write is not a complete write of the area — a separate checkpoint when compared with this result. |
TPM_E_BAD_ATTRIBUTES | The NV area attributes conflict — a separate checkpoint when compared with it. |
TPM_E_WRITE_LOCKED | The NV area has already been written to — a separate checkpoint when compared with it. |
The decisive distinction for this HRESULT is that TPM_E_WRITE_LOCKED concerns an index’s own write state, while this code is a TPM-wide write-rate or count limit. The short platform wording — “The maximum number of NV writes without an owner has been exceeded.” — does not supply that differential diagnosis by itself.
Operational response
The corrective direction is to use owner-authorized writes where the policy permits or wait for the specification-defined lifecycle reset; do not loop retries. Do not undefine a production NV index until its public attributes and authorization policy have been recorded. NV policy is established at definition time, and destructive recreation can remove counters, certificates or provisioning state.
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 — NV structures and permissions — source for the checkpoint.
- TCG: TPM 1.2 Part 3 — NV commands — source for the checkpoint.
- Microsoft: Win32_Tpm class — source for the checkpoint.
Looking for a different code? Search another status or error code.