Crash (computing)

A crash is an abnormal loss of execution in a program or operating system. A process may terminate after an illegal memory access, an unhandled exception, a failed assertion, or an explicitly requested abort. Operating systems normally isolate processes so that one application crash does not bring down other programs; protection mechanisms such as virtual memory and privilege levels are central to that isolation.¹

Crashes arise from software defects, corrupted state, incompatible libraries, exhausted resources, device-driver failures, and, less commonly, failing hardware. A deadlock or infinite loop may look like a crash to a user because the interface stops responding, although the program has not necessarily terminated. Security vulnerabilities often exploit the same memory-safety faults that can cause ordinary crashes.

During a program crash, the operating system usually stops the affected process and records diagnostic state. On Unix-like systems, signals such as SIGSEGV and SIGABRT can identify classes of abnormal termination; on Windows, an unhandled exception is processed through Windows Error Reporting.²³

A crash report may contain the exception type, thread stacks, loaded modules, register values, operating-system version, and application metadata. A core dump or minidump preserves a larger snapshot for debugging, though privacy-sensitive data can also be captured. An operating-system crash is more severe: a kernel panic, bug check, or equivalent failure may stop scheduling, display a diagnostic screen, write a kernel dump, and reboot. The exact behavior depends on the platform and its recovery policy.

Reliable diagnosis begins by connecting a crash report to the exact program version, environment, and triggering action. Developers commonly inspect stack traces and symbols, reproduce the failure under a debugger, compare logs, and use address or thread sanitizers to expose memory errors and data races. Symbol files are especially important because machine addresses alone are difficult to interpret.

Prevention combines defensive programming, input validation, resource limits, automated testing, code review, dependency maintenance, and fault isolation. Production services often restart failed processes, route traffic away from unhealthy instances, and monitor crash rate as a reliability indicator; these measures restore service but do not remove the defect.⁴ Operating-system developers additionally use kernel debugging, minimized reproductions, and regression tests to prevent a fixed failure from returning.⁵

Not every apparent crash is a process crash, and the distinction matters for diagnosis. A watchdog may terminate a program that exceeds a time limit; an operating system may kill a process during memory pressure; and a user or administrator may force termination. These events can produce reports resembling faults but have different remedies.

Crash reporting also has a privacy and governance dimension. Reports can include file paths, account names, document fragments, network details, or sensitive memory contents, so collection systems commonly redact, sample, encrypt, or require consent. Distributed applications add another complication: one failed component may cause retries, timeouts, or cascading failures without a single machine crashing. Finally, a crash can be useful evidence in testing: deliberately injecting process or node failures reveals whether software recovers safely, preserves data, and records enough information for later analysis.⁴⁶

Core dump

A file containing a snapshot of a process's memory and execution state, usually created after abnormal termination.

Kernel panic

A fatal condition in a Unix-like operating-system kernel that prevents it from continuing safely.

Stack trace

A record of the active function calls and source locations leading to a failure.

Watchdog

A mechanism that detects a stalled or unresponsive component and takes corrective action, such as restarting it.