What does Windows error code 815 (ERROR_ENCLAVE_VIOLATION) mean?

ERROR_ENCLAVE_VIOLATION

An attempt was made to access protected memory in violation of its secure access policy.

ERROR_ENCLAVE_VIOLATION is Win32 error 815 (0x32F) and belongs to enclave memory protection. The system description identifies the immediate condition but does not identify the caller, object, policy, device, service instance, or transition that produced it.

Interpret this result at the API boundary that returned it. Capture it before logging, cleanup, or another Windows call can replace the thread-local last-error value. Compare the recorded inputs with the documented precondition for enclave memory protection rather than starting with a broad system repair.

Where the result appears

• This result can surface during trusted code reading or writing outside its permitted enclave pages.
• This result can surface during host code dereferencing an enclave pointer with the wrong access path.
• It can surface during an enclave call using a stale or unvalidated buffer.
• It can surface during protection changes that conflict with enclave page policy.

Likely causes

• an address lies outside the enclave or outside an allowed page range.
• page permissions do not permit the attempted read, write, or execute operation.
• pointer validation failed across the enclave boundary.
• a use-after-free or corrupted offset targeted protected memory.

Diagnostic sequence

Diagnosis of it starts with the exact request type: read, write, create, transition, validation, cancellation, or administrative action. Identify the object generation and subsystem owner, then decide whether the failure happened before side effects, during a partial transition, or after completion. This ordering matters in enclave memory protection because a blind retry can hide stale state or repeat a non-idempotent change.

• record faulting instruction and address from a dump or debugger.
• record enclave base, size, page type, and protection map.
• record input pointer validation and marshaling lengths.
• record thread call stack across the trusted/untrusted transition.
• record recent enclave page additions, protection changes, or termination.

Correlate it with the owning component’s operational log, the Windows System log, and any subsystem trace. Telemetry for it should preserve native identifiers such as a path or file ID, handle generation, node or peer identity, policy ID, object version, offset and length, or transaction token. Retain decimal 815, hexadecimal 0x32F, and the producing API even when a localized message is also shown.

State boundary to prove

The decisive boundary for it is whether an address lies outside the enclave or outside an allowed page range. Prove or disprove that proposition using faulting instruction and address from a dump or debugger together with enclave base, size, page type, and protection map. When observations for it disagree, preserve both and inspect the transition between them instead of choosing the more convenient value.

A focused validation for it should recreate the relevant part of this situation: trusted code computes an offset from untrusted input without checking overflow. The resulting address leaves the permitted buffer and triggers this violation; strict length validation removes the fault. The negative case should keep the responsible condition unchanged and confirm error 815; the recovery case should change only that condition and verify a successful result without an unrecorded side effect.

Handling, retry, and recovery

Treat the result as a security and correctness fault, not a transient access denial. Stop the operation, preserve a dump where policy allows, validate every boundary pointer, and correct the page or marshaling contract before rerunning.

Retry it only after evidence shows a change in enclave memory protection. Initialization, asynchronous completion, recall, or service readiness can justify bounded backoff; malformed metadata, invalid identifiers, policy rejection, unsupported versions, and integrity failures require correction. Before repeating a write or configuration operation after it, query completion state explicitly.

What to log for support and telemetry

• log decimal 815, hexadecimal 0x32F, and the producing API.
• log the target object and observed enclave memory protection state.
• log caller identity, process and thread IDs, machine or node identity, and UTC time.
• log attempt number, elapsed time, previous result, and any partial side effect.
• retain the first lower-level or component-specific error before Win32 translation.

Difference from nearby codes

Unlike ERROR_ENCLAVE_NOT_TERMINATED, this code concerns an access that violated the enclave security boundary rather than incomplete cleanup.

Practical example

Trusted code computes an offset from untrusted input without checking overflow.

Developer and administrator guidance

Code that handles it should keep its Win32 domain visible across exceptions, RPC responses, and JSON or REST wrappers. Administrators should verify the subsystem evidence before changing policy, deleting state, forcing failover, or replacing storage. Recovery is demonstrated only when a test observes 815, changes the responsible condition, and confirms that the same operation succeeds without hidden data loss.

References

• Microsoft: System Error Codes (500–999) — reference for error 815.
• Microsoft: Enclaves — reference for error 815.
• Microsoft: Enclave functions — reference for error 815.

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