| Previous | Next |
| ERROR_INSTALL_SERVICE_SAFEBOOT | ERROR_INSTALL_REJECTED |
ERROR_FAIL_FAST_EXCEPTION
A fail-fast condition terminated the process immediately.
ERROR_FAIL_FAST_EXCEPTION is Win32 error 1653 (0x675). It denotes a deliberate nonrecoverable termination path used when continuing could be unsafe, for example after detecting stack corruption, an invalid security invariant, or an explicitly raised fail-fast exception. Normal structured and vectored exception handlers are not a reliable recovery mechanism for this condition. The useful artifact is usually the crash dump and its fail-fast subcode, not a retry count.
Why software deliberately fails fast
- runtime security checks detect corrupted control data or an impossible internal invariant
- code calls
RaiseFailFastExceptionor a framework equivalent for an unrecoverable state - a library reports corrupted heap, stack cookie, invalid parameter, or contract violation
- a security mitigation converts a dangerous operation into immediate process termination
- an application chooses fail-fast to prevent damaged state from being persisted or exposed
Crash evidence to retain
Collect a full user-mode dump when policy allows, exception code and parameters, fail-fast subcode, faulting instruction, call stack for all relevant threads, loaded module versions and hashes, process mitigation settings, recent input identifiers, and Windows Error Reporting bucket data. Log only stable request or document identifiers needed for correlation; the process may be compromised, so treat in-memory values as potentially corrupted.
Investigation approach
Open the dump at the termination point and inspect the exception record before looking for catch blocks. Determine whether the caller explicitly invoked fail-fast or whether the runtime generated it. The exception parameters or subcode often distinguish stack-cookie failure, range-check failure, invalid indirect call, or application-defined fatal state.
Trace backward to the first corruption or invariant break, which can occur much earlier than termination. Use PageHeap, Application Verifier, sanitizers, compiler security checks, or targeted tracing in a reproducible environment. Do not add a broad exception handler to suppress the termination; fail-fast intentionally bypasses ordinary recovery.
Operational response
Restart the affected process only after preserving diagnostics. If it handles durable work, verify transaction recovery and quarantine partially written output. Roll back a recent module or policy change when evidence links it to the failure, and prioritize updates that fix memory-safety or validation defects.
Developers should keep fail-fast sites narrowly scoped, attach actionable context before termination when safe, enable crash collection, and make restart idempotent. A service monitor may restart the process, but repeated fail-fast crashes must trigger escalation rather than an endless loop.
Difference from an ordinary unhandled exception
An unhandled access violation may still pass through configured exception machinery before process termination. Fail-fast is designed to bypass that path. Error 1653 should therefore not be interpreted as permission failure, timeout, or a catchable business exception.
Example
A parser detects that an internal length invariant has been violated after processing an untrusted file and raises fail-fast. The service manager restarts it, but the dump shows the same input and subcode each time. Blocking that file and fixing the bounds error is correct; wrapping the parser in try/catch is not.
References
- Microsoft: System Error Codes (1300–1699)
- Microsoft: RaiseFailFastException
- Microsoft: Fail Fast Exception C0000409
Looking for a different code? Search another status or error code.