| Previous | Next |
| ERROR_CPU_SET_INVALID | ERROR_ENCLAVE_VIOLATION |
ERROR_ENCLAVE_NOT_TERMINATED
The specified enclave has not yet been terminated.
ERROR_ENCLAVE_NOT_TERMINATED is Win32 error 814 (0x32E) and belongs to trusted execution enclave lifecycle. 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 trusted execution enclave lifecycle rather than starting with a broad system repair.
Where the result appears
- This result can surface during DeleteEnclave or enclave cleanup.
- This result can surface during teardown after a worker entered trusted code.
- It can surface during process shutdown while enclave threads are active.
- It can surface during resource release following an earlier enclave failure.
Likely causes
- one or more enclave threads or references remain active.
- the caller attempted to free the address range before termination completed.
- asynchronous teardown is still draining trusted execution.
- a component lost track of an enclave user and initiated cleanup too early.
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 trusted execution enclave lifecycle because a blind retry can hide stale state or repeat a non-idempotent change.
- record enclave base address, type, and creation flags.
- record threads that entered or are still executing enclave code.
- record termination request time and completion notification.
- record outstanding handles, callbacks, and loader state.
- record the first error that triggered enclave teardown.
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 814, hexadecimal 0x32E, and the producing API even when a localized message is also shown.
State boundary to prove
The decisive boundary for it is whether one or more enclave threads or references remain active. Prove or disprove that proposition using enclave base address, type, and creation flags together with threads that entered or are still executing enclave code. 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: a host begins shutdown while a worker remains in enclave code. The corrected host joins the worker, terminates the enclave, and only then releases its reserved range. The negative case should keep the responsible condition unchanged and confirm error 814; the recovery case should change only that condition and verify a successful result without an unrecorded side effect.
Handling, retry, and recovery
Quiesce users of the enclave, complete the documented termination sequence, and release memory only after termination is confirmed. Repeated deletion while code is still executing can obscure the original lifecycle defect.
Retry it only after evidence shows a change in trusted execution enclave lifecycle. 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 814, hexadecimal
0x32E, and the producing API. - log the target object and observed trusted execution enclave lifecycle 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
This code reports incomplete teardown, whereas an enclave violation reports an illegal protected-memory access.
Practical example
A host begins shutdown while a worker remains in enclave code.
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 814, 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 814.
- Microsoft: Enclaves — reference for error 814.
- Microsoft: Enclave functions — reference for error 814.
Looking for a different code? Search another status or error code.