| Previous | Next |
| ERROR_TIMER_NOT_CANCELED | ERROR_BAD_STACK |
ERROR_UNWIND
What this result means
ERROR_UNWIND is a Windows system result. Stack unwinding is the process of walking back through active call frames during exception handling, cancellation, or nonlocal control transfer. This code signals that Windows is in or reporting an unwind condition.
Why it can appear
- an exception handler is being invoked during normal stack unwind
- code incorrectly treats an unwind notification as a new independent exception
- a language runtime, injected hook, or manual exception frame violates unwind rules
- corrupted stack metadata causes the unwinder to enter an abnormal path
Diagnostic workflow
- capture the original exception code, exception flags, instruction pointer, stack pointer, and full stack
- inspect whether the exception record has unwind flags set
- verify compiler, runtime, and module architecture consistency
- enable page heap, application verifier, or control-flow diagnostics when stack corruption is suspected
Correct recovery and handling
Do not swallow unwind notifications or resume execution from an invalid frame. Let the language runtime complete cleanup. If custom exception handling is present, follow the platform ABI and keep handlers minimal.
Administrator and support checklist
- For
ERROR_UNWIND, confirm whether the condition is isolated to one machine, one user, one file, or one application build. - Compare the host reporting
ERROR_UNWINDwith a known-good system using the same Windows edition and policy. - Review updates, drivers, security-policy changes, restores, and infrastructure incidents that preceded
ERROR_UNWIND. - Preserve logs and dumps associated with
ERROR_UNWINDbefore rebooting when the failure may be intermittent or destructive. - Use vendor-supported repair or rollback steps for
ERROR_UNWINDinstead of copying system files or disabling protections ad hoc.
Developer guidance
When handling ERROR_UNWIND, log the API or subsystem that returned it, the first lower-level failure, relevant object identifiers, process and thread context, and safe operation parameters. Preserve the original numeric value for ERROR_UNWIND rather than converting it to an unrelated HRESULT or NTSTATUS. Retry ERROR_UNWIND only when the evidence shows a transient dependency; deterministic ERROR_UNWIND cases involving policy, format, compatibility, or integrity should fail fast.
What to record in telemetry
- Windows build, architecture, and component version for the
ERROR_UNWINDevent - the first
ERROR_UNWINDtimestamp and the operation then in progress - process, thread, session, and target object associated with
ERROR_UNWIND - warnings or lower-layer status values immediately preceding
ERROR_UNWIND - whether retry, restart, rollback, or repair changed the
ERROR_UNWINDoutcome
Example investigation pattern
Investigate ERROR_UNWIND by reproducing the operation once with detailed logging, then correlate that timestamp with Windows events and lower-layer traces. Compare the affected object or process with a known-good one, change one variable at a time, and stop retrying when ERROR_UNWIND is deterministic. For ERROR_UNWIND, that method keeps the first relevant failure from being hidden by secondary cleanup messages.
Related and easily confused conditions
This is not itself proof of a crash. It may be an intermediate state during legitimate exception processing. The original exception and the handler that mishandled it are usually more important.
Operational note
Do not diagnose ERROR_UNWIND from its text alone. The ERROR_UNWIND result can cross subsystem boundaries and may summarize an earlier, more specific event. For ERROR_UNWIND, the first failure in time is normally more useful than the last message printed during cleanup.
References
Looking for a different code? Search another status or error code.