Crash (computing) · Lablypedia

Most crashes are the result of a software bug. Typical causes include accessing invalid memory addresses, incorrect address values in the program counter, buffer overflow, overwriting a portion of the affected program code due to an earlier bug, executing invalid machine instructions (an illegal or unauthorized opcode), or triggering an unhandled exception. The original software bug that started this chain of events is typically considered to be the cause of the crash, which is discovered through the process of debugging. The original bug can be far removed from the code that actually triggered the crash.

In early personal computers, attempting to write data to hardware addresses outside the system's main memory could cause hardware damage. Some crashes are exploitable and let a malicious program or hacker execute arbitrary code, allowing the replication of viruses or the acquisition of data which would normally be inaccessible.

Application crashes

An application typically crashes when it performs an operation that is not allowed by the operating system. The operating system then triggers an exception or signal in the application. Unix applications traditionally responded to the signal by dumping core. Most Windows and Unix GUI applications respond by displaying a dialogue box (such as the one shown in the accompanying image on the right) with the option to attach a debugger if one is installed. Some applications attempt to recover from the error and continue running instead of exiting.

An application can also contain code to crash after detecting a severe error.

Typical errors that result in application crashes include:

attempting to read or write memory that is not allocated for reading or writing by that application (e.g., segmentation fault, x86-specific general protection fault)
attempting to execute privileged or invalid instructions
attempting to perform I/O operations on hardware devices to which it does not have permission to access
passing invalid arguments to system calls
attempting to access other system resources to which the application does not have permission to access
attempting to execute machine instructions with bad arguments (depending on CPU architecture): divide by zero, operations on denormal number or NaN (not a number) values, memory access to unaligned addresses, etc.

Crash to desktop

A "crash to desktop" (CTD) is said to occur when a program (commonly a video game) unexpectedly quits, abruptly taking the user back to the desktop. Usually, the term is applied only to crashes where no error is displayed, hence all the user sees as a result of the crash is the desktop. There is often no apparent action that causes a crash to desktop. During normal function, the program may freeze for a shorter period of time, and then close by itself. Also during normal function, the program may become a black screen and repeatedly play the last few seconds of sound (depending on the size of the audio buffer) that was being played before it crashes to desktop. Other times, it may appear to be triggered by a certain action, such as loading an area. An example of a triggering CTD error can be found in Blender 3D. When the user is in edit mode, they can use ctrl+B to bevel an edge. If the user uses the undo function through ctrl+Z during the free-mouse bevel process, the software has a high chance to simply close through a CTD error.

CTD bugs are considered particularly problematic for users. Since they frequently display no error message, it can be very difficult to track down the source of the problem, especially if the times they occur and the actions taking place right before the crash do not appear to have any pattern or common ground. One way to track down the source of the problem for games is to run them in windowed mode. Certain operating system versions may feature one or more tools to help track down causes of CTD problems.

Some computer programs such as StepMania and BBC's Bamzooki also crash to desktop if in full-screen, but display the error in a separate window when the user has returned to the desktop.

4 more chapters are free with a Lably account.

Web server crashes

The software running the web server behind a website may crash, rendering it inaccessible entirely or providing only an error message instead of normal content.

For example, while the web server itself might remain active, a crash in the backend database (like MySQL) creates a dependency failure, forcing the site to display a 500 Internal Server Error instead of the requested page.

Operating system crashes

An operating system crash commonly occurs when a hardware exception occurs that cannot be handled. Operating system crashes can also occur when internal sanity-checking logic within the operating system detects that the operating system has lost its internal self-consistency.

Modern multitasking operating systems, such as Linux, and macOS, usually remain unharmed when an application program crashes.

Some operating systems, e.g., z/OS, have facilities for Reliability, availability and serviceability (RAS) and the OS can recover from the crash of a critical component, whether due to hardware failure, e.g., uncorrectable ECC error, or to software failure, e.g., a reference to an unassigned page.

Abnormal end

An abnormal end or ABEND is an abnormal termination of software, or a program crash. Errors or crashes on the Novell NetWare network operating system are usually called ABENDs. Communities of NetWare administrators sprang up around the Internet, such as abend.org.

This usage derives from the ABEND macro on IBM OS/360, ..., z/OS operating systems. Usually capitalized, but may appear as "abend". Some common ABEND codes are System ABEND 0C7 (data exception) and System ABEND 0CB (division by zero). Abends can be "soft" (allowing automatic recovery) or "hard" (terminating the activity). The term is jocularly claimed to be derived from the German word "Abend" meaning "evening".

Security and privacy implications of crashes

Depending on the application, the crash may contain the user's sensitive and private information. Moreover, many software bugs which cause crashes are also exploitable for arbitrary code execution and other types of privilege escalation. For example, a stack buffer overflow can overwrite the return address of a subroutine with an invalid value, which will cause, e.g., a segmentation fault, when the subroutine returns. However, if an exploit overwrites the return address with a valid value, the code in that address will be executed.

Crash reproduction

Effective crash reproduction is critical for debugging because it transforms an intermittent or complex failure into a predictable, repeatable scenario, enabling targeted investigation and resolution of the root cause rather than addressing symptoms.

When crashes are collected in the field using, e.g., a storage dump, a trace, a crash reporter, the next step for developers is to be able to reproduce them locally. Automated crash reproduction techniques generally fall into two categories: record-replay approaches, which capture an execution so that a recorded crash can often be replayed but add substantial runtime performance overhead, and post-failure-process approaches, which analyse a crash only after it has occurred and therefore avoid that overhead. For this, several techniques exist: STAR uses symbolic execution, EvoCrash performs evolutionary search.