| Previous | Next |
| ERROR_CHECKING_FILE_SYSTEM | ERROR_PREDEFINED_HANDLE |
ERROR_FATAL_APP_EXIT
A process deliberately reported a fatal application exit
ERROR_FATAL_APP_EXIT corresponds to Win32 error value documented as: {Fatal Application Exit} %hs This status is emitted when application code chooses a fatal-exit path rather than when Windows detects an arbitrary crash. The accompanying text often comes from the application itself and may identify the failed invariant or startup stage.
Where the result appears in real systems
- Native applications using FatalAppExit or an equivalent runtime termination path.
- Service startup code that cannot continue after configuration validation.
- Compatibility layers that surface an application-supplied fatal message.
Evidence to collect before changing the system
capture the complete message text, executable version, command line, current user, and the last application log records; check whether Windows Error Reporting produced a dump even though the termination was deliberate; reproduce with the same configuration and environment variables
Keep the original numeric value, symbolic name, API return path, thread and process identity, and the exact timestamp in one diagnostic record. Those fields prevent later layers from replacing this specific result with a generic failure and make correlation with ETW or Event Viewer practical.
Handling and recovery
Do not retry the same launch indefinitely. Correct the input, dependency, or configuration named by the fatal message, then start a fresh process. A supervisor should preserve the original exit context instead of replacing it with a generic service failure.
Code that receives this result should classify it according to the operation that produced it: completion information, a recoverable environmental condition, or a programming defect. The result classification should be made at the API boundary where the caller still knows the handle, object, flags, and expected state.
What not to infer from this code
Unlike an access violation, this result says that software intentionally entered a fatal termination path. The real defect may still be internal, but the immediate event is controlled and usually has a human-readable explanation.
Implementation guidance
Preserve this result through logging and telemetry instead of immediately converting it to free-form text. When it crosses an HRESULT boundary, record both the original Win32 value and the converted HRESULT; when it crosses RPC, JSON, or another protocol, include an explicit error-domain field so the receiver does not convert it twice.
A useful automated test for this Win32 error should reproduce the relevant state transition, assert the exact returned value, and verify cleanup after both the normal and exceptional path. The test for this Win32 error should also check that a retry is performed only when the underlying state can genuinely change, because unconditional retries often hide ownership, architecture, power, or resource-negotiation defects.
References
Looking for a different code? Search another status or error code.