Hubbry Logo
Core dumpCore dumpMain
Open search
Core dump
Community hub
Core dump
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Core dump
Core dump
Core dump
View on Wikipedia
from Wikipedia

In computing, a core dump,[a] memory dump, crash dump, storage dump, system dump, or ABEND dump[1] consists of the recorded state of the working memory of a computer program at a specific time, generally when the program has crashed or otherwise terminated abnormally.[2] In practice, other key pieces of program state are usually dumped at the same time, including the processor registers, which may include the program counter and stack pointer, memory management information, and other processor and operating system flags and information. A snapshot dump (or snap dump) is a memory dump requested by the computer operator or by the running program, after which the program is able to continue. Core dumps are often used to assist in diagnosing and debugging errors in computer programs.

On many operating systems, a fatal exception in a program automatically triggers a core dump. By extension, the phrase "to dump core" has come to mean in many cases, any fatal error, regardless of whether a record of the program memory exists. The term "core dump", "memory dump", or just "dump" has also become jargon to indicate any output of a large amount of raw data for further examination or other purposes.[3][4]

Background

[edit]

The name comes from magnetic-core memory,[5][6] the principal form of random-access memory from the 1950s to the 1970s. The name has remained long after magnetic-core technology became obsolete.

Earliest core dumps were paper printouts[7] of the contents of memory, typically arranged in columns of octal or hexadecimal numbers (a "hex dump"), sometimes accompanied by their interpretations as machine language instructions, text strings, or decimal or floating-point numbers (cf. disassembler).

As memory sizes increased and post-mortem analysis utilities were developed, dumps were written to magnetic media like tape or disk.

Instead of only displaying the contents of the applicable memory, modern operating systems typically generate a file containing an image of the memory belonging to the crashed process, or the memory images of parts of the address space related to that process, along with other information such as the values of processor registers, program counter, system flags, and other information useful in determining the root cause of the crash. These files can be viewed as text, printed, or analysed with specialised tools such as elfdump on Unix and Unix-like systems, objdump and kdump on Linux, IPCS (Interactive Problem Control System) on IBM z/OS,[8] DVF (Dump Viewing Facility) on IBM z/VM,[9] WinDbg on Microsoft Windows, Valgrind, or other debuggers.

In some operating systems[b] an application or operator may request a snapshot of selected storage blocks, rather than all of the storage used by the application or operating system.

Uses

[edit]

Core dumps can serve as useful debugging aids in several situations. On early standalone or batch-processing systems, core dumps allowed a user to debug a program without monopolizing the (very expensive) computing facility for debugging; a printout could also be more convenient than debugging using front panel switches and lights.

On shared computers, whether time-sharing, batch processing, or server systems, core dumps allow off-line debugging of the operating system, so that the system can go back into operation immediately.

Core dumps allow a user to save a crash for later or off-site analysis, or comparison with other crashes. For embedded computers, it may be impractical to support debugging on the computer itself, so analysis of a dump may take place on a different computer. Some operating systems such as early versions of Unix did not support attaching debuggers to running processes, so core dumps were necessary to run a debugger on a process's memory contents.

Core dumps can be used to capture data freed during dynamic memory allocation and may thus be used to retrieve information from a program that is no longer running. In the absence of an interactive debugger, the core dump may be used by an assiduous programmer to determine the error from direct examination.

Snap dumps are sometimes a convenient way for applications to record quick and dirty debugging output.

Analysis

[edit]

A core dump generally represents the complete contents of the dumped regions of the address space of the dumped process. Depending on the operating system, the dump may contain few or no data structures to aid interpretation of the memory regions. In these systems, successful interpretation requires that the program or user trying to interpret the dump understands the structure of the program's memory use.

A debugger can use a symbol table, if one exists, to help the programmer interpret dumps, identifying variables symbolically and displaying source code; if the symbol table is not available, less interpretation of the dump is possible, but there might still be enough possible to determine the cause of the problem. There are also special-purpose tools called dump analyzers to analyze dumps. One popular tool, available on many operating systems, is the GNU binutils' objdump.

On modern Unix-like operating systems, administrators and programmers can read core dump files using the GNU Binutils Binary File Descriptor library (BFD), and the GNU Debugger (gdb) and objdump that use this library. This library will supply the raw data for a given address in a memory region from a core dump; it does not know anything about variables or data structures in that memory region, so the application using the library to read the core dump will have to determine the addresses of variables and determine the layout of data structures itself, for example by using the symbol table for the program undergoing debugging.

Analysts of crash dumps from Linux systems can use kdump or the Linux Kernel Crash Dump (LKCD).[10]

Core dumps can save the context (state) of a process at a given state for returning to it later. Systems can be made highly available by transferring core between processors, sometimes via core dump files themselves.

Core can also be dumped onto a remote host over a network (which is a security risk).[11]

OS/360 introduced the service aid IMDPRDMP to print stand-alone and SVC dumps. This program formats several system control blocks in addition to printing storage areas in hexadecimal and EBCDIC. The OS/VS1 and OS/VS2 versions are called HMDPRDMP and AMDPRDMP.

Interactive Problem Control System (IPCS) is a full screen dump reader that IBM introduced for OS/VS2 (MVS), DOS/VSE and VM/370. The MVS version performs functions similar to AMDPRDMP, and uses compatible control block descriptions for formatting. IBM eventually dropped AMDPRDMP in favor of IPCS.

Users of IBM mainframes running z/OS can browse both SVC and transaction dumps using IPCS, which supports user written scripts in REXX and supports point-and-shoot browsing[c] of dumps.

Core-dump files

[edit]

Format

[edit]

In older and simpler operating systems, each process had a contiguous address-space, so a dump file was sometimes simply a file with the sequence of bytes, digits,[d] characters[d] or words. On other systems a dump file contained discrete records, each containing a storage address and the associated contents. On the earliest of these machines, the dump was often written by a stand-alone dump program rather than by the application or the operating system.

The IBSYS monitor for the IBM 7090 included a System Core-Storage Dump Program[12] that supported post-mortem and snap dumps.

On the IBM System/360, the standard operating systems wrote formatted ABEND and SNAP dumps, with the addresses, registers, storage contents, etc., all converted into printable forms. Later releases added the ability to write unformatted[e] dumps, called at that time core image dumps (also known as SVC dumps.)

In modern operating systems, a process address space may contain gaps, and it may share pages with other processes or files, so more elaborate representations are used; they may also include other information about the state of the program at the time of the dump.

In Unix-like systems, core dumps generally use the standard executable image-format:

Naming

[edit]

OS/360 and successors

[edit]

In OS/360 and successors, a job may assign arbitrary data set names (dsnames) to the ddnames SYSABEND and SYSUDUMP for a formatted ABEND dump and to arbitrary ddnames for SNAP dumps, or define those ddnames as SYSOUT.[f] The Damage Assessment and Repair (DAR) facility added an automatic unformatted[h] storage dump to the dataset SYS1.DUMP[i] at the time of failure as well as a console dump requested by the operator. A job may assign an arbitrary dsname to the ddname SYSMDUMP for an unformatted ABEND dump, or define that ddname as SYSOUT.[j] The newer transaction dump is very similar to the older SVC dump. The Interactive Problem Control System (IPCS), added to OS/VS2 by Selectable Unit (SU) 57[14][15] and part of every subsequent MVS release, can be used to interactively analyze storage dumps on DASD. IPCS understands the format and relationships of system control blocks, and can produce a formatted display for analysis. The current versions of IPCS allow inspection of active address spaces[16][k] without first taking a storage dump and of unformaated dumps on SPOOL.

Unix-like

[edit]

Since Solaris 8, system utility coreadm allows the name and location of core files to be configured. Dumps of user processes are traditionally created as core. On Linux (since versions 2.4.21 and 2.6 of the Linux kernel mainline), a different name can be specified via procfs using the /proc/sys/kernel/core_pattern configuration file; the specified name can also be a template that contains tags substituted by, for example, the executable filename, the process ID, or the reason for the dump.[17] System-wide dumps on modern Unix-like systems often appear as vmcore or vmcore.incomplete.

Others

[edit]

Systems such as Microsoft Windows, which use filename extensions, may use extension .dmp; for example, core dumps may be named memory.dmp or \Minidump\Mini051509-01.dmp.

Windows memory dumps

[edit]

Microsoft Windows supports two memory dump formats, described below.

Kernel-mode dumps

[edit]
Main article: Blue Screen of Death

There are five types of kernel-mode dumps:[18]

  • Complete memory dump – contains full physical memory for the target system.
  • Kernel memory dump – contains all the memory in use by the kernel at the time of the crash.
  • Small memory dump – contains various info such as the stop code, parameters, list of loaded device drivers, etc.
  • Automatic memory dump (Windows 8 and later) – same as Kernel memory dump, but if the paging file is both System Managed and too small to capture the Kernel memory dump, it will automatically increase the paging file to at least the size of RAM for four weeks, then reduce it to the smaller size.[19]
  • Active memory dump (Windows 10 and later) – contains most of the memory in use by the kernel and user mode applications.

To analyze the Windows kernel-mode dumps Debugging Tools for Windows are used, a set that includes tools like WinDbg & DumpChk.[20][21][22]

User-mode memory dumps

[edit]

User-mode memory dump, also known as minidump,[23] is a memory dump of a single process. It contains selected data records: full or partial (filtered) process memory; list of the threads with their call stacks and state (such as registers or TEB); information about handles to the kernel objects; list of loaded and unloaded libraries. Full list of options available in MINIDUMP_TYPE enum.[24]

Space missions

[edit]

The NASA Voyager program was probably the first craft to routinely utilize the core dump feature in the Deep Space segment. The core dump feature is a mandatory telemetry feature for the Deep Space segment as it has been proven to minimize system diagnostic costs.[citation needed] The Voyager craft uses routine core dumps to spot memory damage from cosmic ray events.

Space Mission core dump systems are mostly based on existing toolkits for the target CPU or subsystem. However, over the duration of a mission the core dump subsystem may be substantially modified or enhanced for the specific needs of the mission.

See also

[edit]

References

[edit]

Notes

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Core dump

View on Grokipedia
from Grokipedia
A core dump is a file containing a snapshot of a process's image, including its , registers, and other state information, captured at the moment of abnormal termination, such as from a or other unhandled signal, to facilitate postmortem and of software crashes. The term originates from the era of in early computers, where "core" referred to the ferrite rings used for main storage, and "dumping" meant or the contents for examination during failures. In operating systems, core dumps are automatically generated by the kernel in response to specific signals (e.g., SIGSEGV for invalid access or SIGABRT for assertion failures), provided the process's limit for core files (RLIMIT_CORE) permits it and the system configuration enables dumping. These files, typically named "core" or "core.

" where

is the process ID, can be inspected using tools like the GNU Debugger (GDB) to reconstruct the program's state, identify faulty code, and trace execution paths leading to the crash. Configuration options, such as the kernel parameter /proc/sys/kernel/core_pattern, allow customization of dump filenames, compression, or piping to external programs for processing. While core dumps are a staple of Unix and environments, analogous mechanisms exist in other operating systems; for instance, Windows generates dump files (e.g., complete, kernel, or minidump) upon system crashes or application faults, capturing varying levels of physical for use with tools like . These dumps serve critical roles in , system administration, and incident response, enabling developers to diagnose corruption, buffer overflows, or leaks without reproducing the failure in real-time. Modern systems often include safeguards like excluding sensitive data or limiting dump sizes to balance debugging utility with security and storage concerns.

Introduction

Definition

A core dump is a file containing an image of a process's memory at the moment of its termination. This snapshot captures the complete state of the process, including key components such as the heap for dynamically allocated data, the stack for local variables and function frames, CPU registers, and code segments. The term "core dump" originates from the magnetic core memory technology prevalent in early computers, where such dumps preserved the contents of ferrite core-based storage. Understanding a core dump requires familiarity with the typical memory layout in systems, which divides into distinct segments. The text segment holds the program's executable instructions. The stores initialized global and static variables, while the segment allocates space for uninitialized ones. Above these lie the heap, managed for runtime allocations, and the stack, which grows downward to handle function calls and variables. Registers, though not part of the segments, are also preserved to reflect the processor's state at termination. In contrast to other diagnostic outputs like logs or execution traces—which provide textual records of events or high-level behaviors—a core dump delivers a raw, binary representation of and state for precise reconstruction of failures. Its fundamental purpose is to facilitate post-mortem examination in a , enabling developers to investigate runtime errors such as segmentation faults, often triggered by signals like SIGSEGV. This allows pinpointing issues like invalid accesses or assertion violations that caused the process to abort.

Historical Background

The concept of a core dump originated in the with the widespread use of systems, where "core" specifically referred to the tiny ferrite rings that stored individual bits of data in early computers like those from and MIT's project. These systems required mechanisms to capture and preserve contents during failures for post-mortem , as physical core memory was expensive. Early implementations emerged in mainframe operating systems, including IBM's OS/360, announced in 1964, which provided debugging tools for dumping memory states to aid in error diagnosis. Similarly, the operating system, developed from 1965 to 1969 on the GE-645 computer, incorporated core dump capabilities to examine memory after crashes, supporting its architecture. In the 1970s, , created by and at , adopted and refined these features for software debugging, transitioning from hardware-centric dumps to more accessible file-based outputs on minicomputers like the PDP-11. The evolution continued into the personal computing era, where core dumps shifted from hardware-initiated captures in mainframes to software-generated files, enabling easier portability and analysis on smaller systems. A key milestone occurred in with the POSIX.1 standard (IEEE Std 1003.1-1988), which described core dump practices as common in systems to promote portability. In the and , with the introduction of architectures, core dumps were adapted to include process address spaces beyond physical RAM limits. Although was largely replaced by semiconductor RAM after the 1970s, the nomenclature "core dump" endured in software practices, reflecting its historical roots while applying to modern .

Generation

Automatic Triggers

In operating systems, core dumps are automatically triggered by unhandled signals that have a default action of terminating the process and generating a core file. Primary examples include SIGSEGV, which is raised upon segmentation violations such as invalid memory access; SIGABRT, often invoked by the abort() function during assertion failures; and SIGQUIT, typically sent by the quit command or certain keyboard interrupts. Other signals like SIGFPE (floating-point exceptions, e.g., on some architectures), SIGILL (illegal instructions), SIGBUS (bus errors), and SIGTRAP (trace traps on certain systems) also initiate dumps under similar conditions. The operating system kernel plays a central role in detecting these fatal errors and initiating the core dump . Upon receiving such a signal, the kernel terminates the offending and, if enabled, creates a core dump file capturing the 's state at the moment of . This detection occurs for hardware-generated faults, such as invalid references or arithmetic errors, ensuring the dump is produced before cleanup. Core dump generation is subject to resource limits configured via system calls like setrlimit() or the ulimit command, particularly the RLIMIT_CORE limit which controls the maximum size of the core file. If RLIMIT_CORE is set to zero, no dump is produced, preventing potential disk exhaustion; similarly, exceeding RLIMIT_FSIZE may block the dump unless configured otherwise. Additional conditional factors can trigger dumps indirectly, such as pipe write failures in some configurations (though SIGPIPE typically terminates without dumping) or watchdog timeouts in supervised environments that escalate to abort signals. Assertion failures explicitly call abort(), routing through SIGABRT to force a dump. At the time of triggering, the core dump preserves the process's full state, including contents, CPU registers, a list of open file descriptors, environment variables, and—for multi-threaded processes—the stack and registers of all threads, enabling later reconstruction of the execution .

Manual Invocation

Manual invocation enables the deliberate generation of core dumps from running processes, providing a controlled alternative to automatic triggers that respond only to unhandled signals like segmentation faults. This approach is essential for proactive diagnostics in production environments where faults are not yet manifesting. Command-line utilities offer straightforward ways to initiate core dumps externally. The gcore tool, included in the GNU Debugger (GDB) distribution, attaches to one or more running processes by their process IDs (PIDs) and produces core files equivalent to those created by the kernel during a crash, while allowing the processes to continue execution afterward. For example, executing gcore <pid> pauses the target process temporarily, dumps its memory state, and resumes operation, with the output file named core.<pid> by default. Similarly, the kill command can send SIGQUIT (signal 3) or SIGABRT (signal 6) to a PID, both of which have a default action of terminating the process and generating a core dump. Within application code, programmatic triggers facilitate core dumps at specific points, such as during error conditions or checkpoints. and C++, the abort() function from <stdlib.h> raises SIGABRT, leading to abnormal program termination and a core dump unless the signal is caught and handled to prevent it. Developers can also explicitly call raise(SIGABRT) to achieve the same effect, ensuring the process state is captured precisely where the invocation occurs. Equivalent functionality in other languages, such as Python's os.abort(), leverages underlying signal APIs to simulate abort conditions and produce dumps. Debugger attachments provide interactive control over core dump creation. In GDB, after attaching to a with gdb -p <pid>, the generate-core-file command (or its alias gcore) saves the inferior process's image and register state to a file, defaulting to core.<pid> if unspecified. This method supports customization, such as excluding certain mappings via the use-coredump-filter setting, and generates sparse files on compatible filesystems to optimize storage. System configuration influences manual dump behavior in environments. The /proc/sys/kernel/core_pattern parameter defines the template for core file names and can route dumps to a pipe for processing by a user-space program, applying uniformly to manually invoked dumps from tools like gcore or signal sends. For instance, setting core_pattern to /tmp/core.%p directs all dumps, including manual ones, to a specific directory with PID inclusion. These techniques are valuable for diagnosing hangs or intermittent issues, where capturing a snapshot allows offline examination without forcing an immediate crash that could exacerbate problems. The resulting files adhere to standard storage conventions, typically placed in the current or as configured. A key limitation is the potential for incomplete dumps if the process is in an inconsistent state, such as midway through operations or with locked regions, leading to partial or unreliable snapshots. Additionally, memory marked non-dumpable via /proc/

/coredump_filter is omitted by default in tools like gcore, unless explicitly overridden.

Uses and Applications

Debugging Software Failures

Core dumps play a crucial role in software failures by preserving the exact state of a program at the moment of a crash, enabling developers to reconstruct the execution context without needing to reproduce the issue in a live environment. This includes capturing the call stack, which reveals the sequence of function calls leading to the failure, as well as the values of variables and registers at that instant. By loading the core dump into a such as GDB, analysts can examine these elements to identify root causes like memory corruption. Such reconstruction is particularly valuable for pinpointing issues like buffer overflows, where data exceeds allocated memory boundaries and overwrites adjacent areas, or dereferences, which occur when code attempts to access memory through an uninitialized pointer. In these cases, the core dump allows inspection of corrupted memory regions and the offending code paths, facilitating targeted fixes that might otherwise require extensive logging or trial-and-error reproduction. For instance, tools within GDB can dump memory contents around the fault address to visualize overflow patterns or invalid accesses. Integration with integrated development environments (IDEs) further enhances this process by allowing core dumps to be loaded directly into debuggers for interactive analysis, simulating a step-through execution as if the program were still running. IDEs like CLion or support postmortem debugging of core files, where developers can set breakpoints retrospectively, inspect variables frame by frame, and navigate the call stack visually. This approach bridges the gap between crash artifacts and familiar development workflows, making it easier to correlate dump data with . In multi-threaded applications, core dumps provide a snapshot of all threads' states, enabling the identification of concurrency issues such as race conditions—where threads access shared data unpredictably—or deadlocks, where threads mutually block resource acquisition. Debuggers like GDB offer commands such as info threads to list active threads and thread apply all bt to generate backtraces for every thread simultaneously, revealing contention points or locked resources at crash time. This thread-level visibility is essential for diagnosing non-deterministic bugs that evade live debugging sessions. Effective analysis requires matching the core dump against the precise version of the source code and binary that produced it, typically using debug symbols to map addresses to function names, line numbers, and variable details. If symbols are stripped from the production binary, a separate debug information file or the original build artifact must be used; mismatches can lead to incomplete or misleading traces, as the dump's layout depends on the exact compilation. GDB verifies compatibility by loading the executable alongside the core file, ensuring symbols align correctly for accurate reconstruction. Best practices for enabling useful core dumps include compiling with debug symbols via flags like -g in GCC or , which embed symbol tables without significantly impacting performance, and retaining these in separate files (e.g., using -gsplit-dwarf) for production deployments. Additionally, avoiding aggressive optimization flags like -O3 during builds—or using -Og for a balance—prevents code transformations that reorder instructions or inline functions, which can obscure variable states and stack frames in the dump. These steps ensure dumps remain interpretable while maintaining realistic crash conditions. By facilitating rapid offline diagnosis of production incidents, core dumps contribute to reducing mean time to resolution (MTTR). This impact is amplified in high-availability systems, where quick postmortem minimizes without requiring on-site reproduction.

Forensic and Diagnostic Purposes

Core dumps are instrumental in incident response efforts, capturing the full state of a process's at the moment of failure to facilitate root cause analysis of system outages. Investigators use them to pinpoint the sequence of leading to . For instance, in network device incidents, core dumps from systems preserve volatile data like main and I/O buffers, allowing reconstruction of without rebooting the device. In security forensics, core dumps enable detection of exploits by revealing anomalous memory patterns indicative of attacks, such as stack smashing through buffer overflows or to facilitate . These artifacts can extract traces of malicious payloads, network traffic captured in memory, or unauthorized modifications, supporting attribution in breach investigations. Unlike routine , which focuses on isolated bugs, forensic analysis of core dumps addresses systemic compromises, though they often contain sensitive data that requires secure handling to mitigate risks. For , core dumps support heap profiling to uncover resource exhaustion and inefficient code paths, such as gradual growth from leaks that degrade application responsiveness over time. By examining heap structures within the dump, engineers identify allocation hotspots and deallocation failures, informing optimizations without relying solely on live tracing tools. This approach is particularly valuable in diagnosing intermittent issues that evade real-time monitoring. In compliance and auditing contexts, core dumps serve as evidentiary records for regulatory reviews in regulated industries like and healthcare, where they document failure modes to verify adherence to standards such as and error handling protocols. Access to these files must be tightly controlled, with directories restricted to software owners and designated administrators to prevent unauthorized exposure of potentially confidential contents. Handling core dumps in secure environments presents challenges, including the need to manage encrypted or obfuscated files while preserving forensic value for analysis. In virtualized setups like , core dumps are automatically encrypted to protect sensitive information, necessitating decryption keys and policy-compliant storage to balance diagnostics with data protection requirements. Additionally, vulnerabilities in dump handlers can inadvertently expose credentials or keys, complicating retention in high-security deployments.

Analysis Techniques

Manual Inspection Methods

Manual inspection of core dumps involves low-level examination of the raw file contents to uncover states, execution paths, and artifacts from a crashed process. This approach relies on basic utilities for viewing and requires familiarity with the underlying and . Analysts typically begin by loading the core dump into a hexadecimal viewer to scan for recognizable patterns, such as ASCII strings that may indicate messages or variable contents. Hexadecimal viewing uses command-line tools like hexdump or xxd to display the core dump's in a readable format, showing both bytes and their ASCII equivalents where applicable. This allows identification of textual artifacts, such as log strings or buffer overflows, embedded in memory regions. For instance, scanning sections around the stack or heap might reveal null-terminated strings or binary signatures of allocated data. Such inspection helps pinpoint anomalies like corrupted pointers or unexpected data overwrites without higher-level interpretation. Symbol table parsing entails manually correlating memory addresses in the core dump with function names and offsets from the executable's . This process involves extracting addresses from key locations, such as the or registers preserved in the dump, and cross-checking them against a disassembly listing of the binary. By aligning these addresses, analysts can trace function calls leading to the crash, identifying entry points or return paths. This method demands access to the unstripped and knowledge of the ELF format's symbol sections. Stack unwinding reconstructs the call stack by calculating frame pointers and return addresses stored in the core dump's stack segment. Starting from the saved base pointer (e.g., RBP on x86_64), each frame's is followed to the previous frame, revealing the sequence of function invocations at the time of failure. This manual traversal accounts for and code in functions, which adjust the stack pointer, and can expose issues like buffer overflows that corrupt stack frames. Frame pointers, when enabled during compilation, simplify this process by providing direct links between frames. Memory mapping correlates sections of the core dump to the process's , identifying regions like the text segment for , data for globals, or heap for dynamic allocations. By examining the ELF program headers in the dump, which outline mapped intervals, analysts can locate malloc'ed regions or shared libraries. This step reveals how memory was laid out, such as distinguishing executable from writable data, to assess access violations or leaks. Cross-referencing enhances accuracy by comparing the core dump's contents with process maps obtained from /proc/<pid>/maps on systems, ideally captured before the crash. This file lists virtual addresses, permissions, and backing files for each mapping, allowing validation of dump sections against the original layout—such as confirming a heap region's boundaries. Discrepancies might indicate partial dumps or post-crash changes, aiding in contextualizing observed . These manual methods are time-intensive, particularly for large core dumps exceeding gigabytes, as they involve byte-by-byte navigation and repeated calculations. They also require deep knowledge of and system internals, limiting their practicality for complex crashes where automated tools offer greater efficiency.

Automated Analysis Tools

Automated analysis tools for core dumps leverage debuggers, sanitizers, and reporting frameworks to parse states, extract stack traces, and identify failure patterns without manual intervention. These utilities enable scalable examination of crashes across development and production environments, often integrating scripting for repeatable workflows. By automating resolution, register inspection, and error annotation, they reduce time and improve accuracy in diagnosing issues like segmentation faults or corruption. The GNU Debugger (GDB) provides interactive yet automated core dump analysis through commands such as bt for generating backtraces, info registers for displaying CPU register values at the time of the crash, and x for examining memory contents at specific addresses. Loading a core file with gdb executable core allows these commands to operate on the dumped process state, facilitating automated scripting via GDB's Python API for batch processing multiple dumps. LLDB, the debugger integrated into Apple's Xcode, supports core file analysis on macOS and iOS platforms, enabling scripting with Python and Lua for automated visualization of stack frames and variables. Commands like bt and register read mirror GDB functionality, while LLDB's expression evaluator allows dynamic code execution against the core dump for deeper inspection. This makes it suitable for ecosystem-specific debugging, such as iOS app crashes, with built-in support for Mach-O binaries and symbolication. For Windows systems, analyzes dump files (.dmp) using extensions like !analyze for automated bug check interpretation and kernel-mode stack unwinding. Loaded via File > Open Crash Dump or command-line options such as windbg -z <file.dmp>, it supports kernel extensions such as !process for thread enumeration and !peb for process environment block details, streamlining triage of blue screen crashes. For user-mode dumps, similar analysis applies using appropriate symbols and commands. AddressSanitizer (ASan), a compiler-integrated runtime tool from / and GCC, detects memory errors like use-after-free or buffer overflows and can be configured to abort on errors, triggering core dump generation for subsequent analysis. Setting ASAN_OPTIONS=abort_on_error=1 ensures the process terminates with a core file containing annotated error locations, including shadow memory maps that highlight corrupted regions. This facilitates automated detection without post-mortem manual parsing. On systems using (common in distributions like and as of 2025), systemd-coredump automatically collects and stores core dumps, with the coredumpctl command providing automated analysis tools. Commands like coredumpctl list enumerate dumps, coredumpctl info <pid> displays details, and coredumpctl gdb <pid> launches GDB directly on the dump for backtrace and inspection, simplifying without manual file handling. Crash reporting systems integrate core dumps for remote upload and triage; for instance, Sentry's coredump-uploader utility monitors directories for new core files and automatically transmits them to its platform for symbol resolution and grouping by error signatures. Similarly, the ELK Stack (, Logstash, ) can process extracted stack traces from core dumps via Logstash pipelines, enabling searchable indexing and visualization for fleet-wide crash pattern analysis. Scripting extensions enhance automation in GDB; pwndbg, a Python-based plugin, automates in core dumps by providing enhanced hexdump views, context-aware disassembly, and custom commands for searching memory artifacts like ROP chains. Installed as a GDB module, it supports core file loading and scripting for repeatable vulnerability hunts, improving efficiency over vanilla GDB interactions.

File Properties

Structure and Format

Core dump files capture the state of a at termination, typically organizing data in a structured binary format to facilitate post-mortem . In systems, the predominant format is the (ELF), which treats the core dump as a specialized ELF file with type ET_CORE (value 4) to distinguish it from executables or object files. The ELF header begins with the e_ident array, featuring magic bytes 0x7F followed by the ASCII characters 'E', 'L', 'F' (0x45, 0x4C, 0x46), which identify the file as ELF-compliant, along with fields specifying class (e.g., 32-bit or 64-bit), data encoding (), and version. Following the header, program headers describe loadable segments and auxiliary information, while sections may include notes for metadata. The program headers in an ELF core dump include entries of type PT_LOAD (value 1), which map virtual memory areas (VMAs) from the process's address space to offsets in the file, capturing segments like the text, data, heap, and stack with details on virtual address, memory size, file size, and permissions (e.g., read, write, execute). A critical PT_NOTE (value 4) entry houses process-specific notes, structured as a sequence of note headers (Elf64_Nhdr or Elf32_Nhdr) containing name size, descriptor size, and type, followed by the note data. Common note types encompass NT_PRSTATUS for register states and signal information, NT_PRPSINFO for process details like command line and execution state, and NT_AUXV for the auxiliary vector, which includes entries such as the command-line arguments, environment variables, and hardware capabilities. These components collectively provide a snapshot of memory mappings and execution context without embedding the full executable. Beyond ELF, portable formats like the minidump used in Breakpad offer cross-platform alternatives, serializing crash data as a sequence of modular s within a header-defined structure. The minidump header (MINIDUMP_HEADER) specifies the file signature ('MDMP'), version, count, and a directory of locations, with each (e.g., thread lists, regions, exception records) containing typed data for registers, stacks, and modules to enable on diverse architectures without OS-specific dependencies. Core dumps routinely incorporate metadata such as the generation timestamp, process ID (PID), terminating signal number (e.g., SIGSEGV for segmentation faults), and CPU register dumps, often stored in dedicated note s or headers to contextualize the failure. To address storage constraints, core dumps may employ compression, such as gzipping the entire file post-generation via kernel or user-space tools, reducing size while preserving the underlying structure for decompression prior to analysis. Standards like the Generic ABI (gABI) for ELF define the header, program, and note formats to ensure interoperability across implementations, while guidelines mandate core generation on unhandled signals (e.g., SIGABRT, SIGFPE) but leave the exact encoding implementation-defined, with ELF as the convention in modern systems.

Naming and Storage Conventions

Core dump files in Unix-like systems follow standardized naming conventions to facilitate identification and organization. By default, the file is named simply "core" and stored in the current working directory of the process that generated it. If the kernel parameter /proc/sys/kernel/core_uses_pid is set to a nonzero value, the filename incorporates the process ID (PID) as "core.

", such as "core.12345", to avoid overwriting existing files from multiple processes. Advanced naming patterns are configurable through the /proc/sys/kernel/core_pattern file, which supports placeholders for dynamic elements like PID (%p), signal number (%s), (%t in seconds since ), (%h), and name (%e). For instance, a pattern like "core.%p.%s.%t" produces files such as "core.12345.11.1636450000", where 11 represents the signal (e.g., SIGSEGV). This file can also specify a full path for storage, redirecting dumps away from the to a central location like /var/crash/core.%p. Additionally, patterns starting with a pipe symbol (|) enable the dump to a user-space program for immediate processing, such as Ubuntu's Apport crash reporter via |/usr/share/apport/apport %p %s %c %d %P %E. Storage management often involves quotas and automated cleanup to prevent excessive disk usage. In systems using , dumps are stored compressed in /var/lib/systemd/coredump, with limits enforced via /etc/systemd/coredump.conf: MaxUse= defaults to 10% of the filesystem size, triggering deletion of oldest dumps when exceeded, while KeepFree= reserves 15% free space with priority. Individual dump sizes are capped by ProcessSizeMax= (defaults to 1 GB on 32-bit systems and 32 GB on 64-bit systems). Retention is further handled by systemd-tmpfiles, which defaults to deleting files in /var/lib/systemd/coredump after 3 days via a configuration in /usr/lib/tmpfiles.d/systemd.conf. Security practices emphasize restricting core dumps in production environments, where they may expose sensitive data from process memory, including credentials or proprietary information. Administrators often disable generation entirely using ulimit -c 0 in shell profiles like /etc/profile or by setting Storage=none in coredump.conf. When enabled, dumps should be directed to restricted directories with appropriate permissions, such as those owned by and inaccessible to non-privileged users, to mitigate unauthorized access risks. For historical retention, core dumps can integrate with log rotation tools like logrotate, configured to compress, rotate, and archive files in designated directories based on size or age thresholds, ensuring organized long-term storage without manual intervention. This approach complements kernel-level policies, allowing customizable retention periods beyond default cleanup mechanisms.

Platform Variations

Unix-like Systems

In operating systems, including , BSD variants, and macOS, core dumps are generated when a terminates abnormally due to signals such as SIGSEGV (), SIGABRT (abort), SIGFPE (floating-point exception), SIGILL (illegal instruction), or SIGQUIT (keyboard quit), which by default trigger a core dump alongside termination. The prctl(PR_SET_DUMPABLE) allows processes to control their dumpability; for instance, setting it to 1 (via prctl(PR_SET_DUMPABLE, 1)) enables core dumps for the calling , which is particularly useful for privileged or processes where dumps are disabled by default to prevent information leakage. This attribute is inherited by child processes but preserved across execve calls, ensuring consistent behavior. Core dumps in these systems typically follow the (ELF), capturing the process's memory image, registers, and auxiliary data at the time of failure. Key note sections include NT_PRSTATUS, which records the process status such as general-purpose registers, signal number, and code, and NT_AUXV, which provides the auxiliary vector containing details like the program's auxiliary information (e.g., AT_PHDR for program header address). In kernels since version 2.6.23, the /proc/[pid]/coredump_filter file offers fine-grained control over dump contents via a bitmask; for example, bit 0 enables anonymous private mappings, bit 1 shared anonymous mappings, and bit 4 ELF headers, with a default value of 0x33 dumping most essential segments while excluding large or sensitive areas to manage . This filtering helps balance diagnostic utility with storage constraints. Naming conventions for core dump files are configurable through /proc/sys/kernel/core_pattern, which supports patterns like %p for process ID and %s for the signal number that caused the dump; for example, setting it to "core-%p-%s" produces files named core-1234-11 for PID 1234 and SIGSEGV (signal 11). The /proc/sys/kernel/core_uses_pid parameter, when set to 1, automatically appends the PID (e.g., core.1234) if no %p is in the pattern, providing and uniqueness to avoid overwrites. Storage is limited by the RLIMIT_CORE resource, adjustable via ulimit -c (e.g., ulimit -c unlimited for no limit or ulimit -c 1000000 for 1 MB cap), which prevents excessive disk usage but can truncate dumps if exceeded. In distributions like , the Apport tool automates collection by intercepting crashes and storing compressed dumps in /var/crash/ with metadata, enabled via systemctl enable apport for non-interactive analysis. Similarly, Fedora's ABRT (Automatic Bug Reporting Tool) captures dumps in /var/spool/abrt/, processing them for backtraces and symbolication before optional reporting. Analysis of Unix-like core dumps often involves GDB, loaded as gdb executable core, where symbol resolution requires debug information packages; in systems like or RHEL, these are installed via debuginfo tools, placing symbols in /usr/lib/debug/ for libraries and executables, enabling commands like bt (backtrace) to map addresses to source lines. (ASLR), enabled by default in modern kernels (via /proc/sys/kernel/randomize_va_space=2), randomizes load addresses for security, but core dumps preserve the runtime layout, allowing GDB to relocate symbols accurately without disabling ASLR during analysis—though reproducing crashes may require temporarily setting randomize_va_space=0 for consistent addressing. In containerized environments like Docker on hosts, core dump support requires explicit configuration due to default limits; running containers with --ulimit core=infinity enables unlimited dumps, often combined with volume mounts (e.g., -v /host/tmp:/tmp) to persist files outside the ephemeral container filesystem, and --privileged if kernel restrictions apply, ensuring dumps capture container-specific without host interference. This setup addresses challenges in isolated environments, where dumps might otherwise be discarded or truncated.

Windows Systems

In Windows systems, the equivalent of a core dump is referred to as a , which captures the state of a or the entire system's at the time of a for purposes. These dumps are primarily managed through (WER), a built-in mechanism that handles both user-mode and kernel-mode . Common types include minidumps, which record essential data such as the call stack and thread contexts for a specific (typically 256 KB or less), full dumps that include the entire , and kernel dumps that focus on system-level components. Minidumps are the default for user-mode application crashes to balance diagnostic utility with storage efficiency, while complete memory dumps encompass all physical RAM but require significant disk space and a sufficiently large page file. Memory dumps can be generated automatically or manually. Automatic generation occurs for user-mode crashes via WER, which is triggered by unhandled exceptions in applications and logs events such as Event ID 1000 in the Windows Event Log, indicating the faulting module and exception code. For kernel-mode failures, such as (BSOD) events, dumps are created using the system's page file (pagefile.sys) to store kernel memory data when configured for kernel, automatic, or complete dump types in System Properties. Legacy tools like , available in older Windows versions such as XP and Server 2003, automated user-mode crash reporting with optional full dumps but have been superseded by WER in modern releases. The Fault Tolerant Heap (FTH) feature, introduced in , monitors recurring application crashes and can indirectly facilitate dump collection by mitigating heap corruption before invoking WER. Manual generation provides flexibility for on-demand . Users can create live kernel or user-mode dumps directly from by right-clicking a process and selecting "Create dump file," which saves a full snapshot without terminating the process. For scripted or automated scenarios, the ADPlus.vbs script from the Windows Tools attaches the (e.g., CDB) to a process and captures dumps on exceptions or hangs. The ProcDump utility from , a command-line tool, enables conditional dumps based on CPU thresholds, usage, or exceptions, often used in production environments with commands like procdump -ma process.exe to generate a full dump and exit. Dump files use the .dmp extension and follow the Debug Dump format, compatible with tools like for analysis; this format includes headers with system information, followed by pages and exception details. Minidumps are partial, excluding most user-mode to reduce size, whereas complete dumps include all addressable . Kernel dumps, generated during system crashes, rely on pagefile.sys for temporary storage before writing to the final location, ensuring capture even if the boot volume is affected. Naming conventions for user-mode dumps default to the format ProcessName_pid_YYYYMMDD_HHMMSS.dmp and are stored in %LOCALAPPDATA%\CrashDumps for per-user crashes or %WINDIR%\Minidump for system-wide ones, with paths configurable via registry keys under HKEY_LOCAL_MACHINE\SOFTWARE\[Microsoft](/page/Microsoft)\Windows\[Windows Error Reporting](/page/Windows_Error_Reporting)\LocalDumps. Many applications, including games, store their .dmp files in %LOCALAPPDATA%\CrashDumps via WER. Additionally, some applications and games generate .dmp files in custom locations, such as subfolders under %LOCALAPPDATA% specific to the application or game (e.g., %LOCALAPPDATA%[GameName]) or within the game's installation directory. WER limits the number of retained dump files in the default folder to prevent indefinite growth (default maximum of 10 files, overwriting the oldest when exceeded). .dmp files from user-mode application and game crashes can consume significant disk space if frequent crashes occur or full dumps are used, particularly for custom locations without such limits. These files are safe to delete if not needed for debugging crash causes, as they contain diagnostic information from past incidents. Users can delete them manually or automate cleanup with scripts. An example Windows batch script to delete .dmp files from common locations is:

batch

@echo off echo Deleting .dmp files from common locations... del /q /f /s "%LOCALAPPDATA%\CrashDumps\*.dmp" >nul 2>&1 del /q /f /s "%USERPROFILE%\AppData\Local\Temp\*.dmp" >nul 2>&1 :: Uncomment and adjust for game-specific path, e.g.: :: del /q /f /s "C:\Path\To\YourGame\*.dmp" >nul 2>&1 echo Done. Check disk space. pause

@echo off echo Deleting .dmp files from common locations... del /q /f /s "%LOCALAPPDATA%\CrashDumps\*.dmp" >nul 2>&1 del /q /f /s "%USERPROFILE%\AppData\Local\Temp\*.dmp" >nul 2>&1 :: Uncomment and adjust for game-specific path, e.g.: :: del /q /f /s "C:\Path\To\YourGame\*.dmp" >nul 2>&1 echo Done. Check disk space. pause

This script can be saved as a .bat file and executed as administrator if required for file access. For automatic execution, add it to Windows Task Scheduler (e.g., run weekly) and adjust paths as needed for specific games or applications. Kernel dumps are typically saved as MEMORY.DMP in the %SystemRoot% directory, with options to specify custom paths in advanced . Event logs, such as those under Application or sources, record triggers with details like fault offsets to correlate with dump files. Kernel-mode dumps differ from user-mode ones in scope and triggers: kernel dumps address system-wide issues like driver faults during BSODs, capturing kernel address space, loaded modules, and processor states via the page file, while user-mode dumps target individual application exceptions without affecting the OS kernel. In virtualized environments like , host-initiated dumps for guest VMs use tools such as VMConnect or cmdlets (e.g., Get-VM | Stop-VM -Force) combined with ProcDump to capture guest memory without direct guest access, supporting diagnostics in cloud-integrated setups like Azure Virtual Machines. Brief comparisons to core dumps highlight Windows' emphasis on configurable partial captures over full ELF-based snapshots.

Mainframe and Other Legacy Systems

In systems, successors to OS/360 such as and z/OS, core dumps are primarily generated as SVC (Supervisor Call) dumps, which capture the virtual storage state of an or the entire system upon error detection. These dumps can be initiated programmatically via the SDUMP macro from recovery routines like functional recovery routines (FRRs) or ESTAE exits, or manually through operator commands such as the DUMP console command. The resulting dump data is written to sequential datasets named SYS1.DUMPxx, where "xx" is a two-digit suffix (up to 100 such datasets possible), allocated on direct-access storage devices (DASD) and managed via the DUMPDS command for allocation, clearing, and resource specification. These datasets support secondary extents to handle large dumps, ensuring comprehensive capture without overflow, and are cleared post-analysis to reuse space. Dump files in these environments follow specific naming and storage conventions, often titled "IEFDUMP" followed by a (e.g., IEFDUMP 20241109 120000) within the dataset, reflecting the legacy dump utility from OS/360 support programs. Storage can be sequential for full system dumps or partitioned for targeted address spaces, with data encoded in for text and packed decimal for numeric fields to align with mainframe hardware architecture. A key structural element is the Prefixed Save Area (PSA), a fixed 8KB block at the start of system dumps that records critical hardware and software state, including processor status, interruption codes, and control registers, aiding in post-mortem reconstruction of the failure context. Triggers for these dumps include abnormal terminations (ABENDs), such as system completion code S0C4 indicating a protection exception from invalid memory access, which automatically invokes dump processing unless suppressed. Analysis of mainframe core dumps relies on tools like the Interactive Problem Control System (IPCS), an interactive utility integrated into z/OS for formatting and navigating dump contents, including parsing ABEND details, storage traces, and control blocks without requiring offline processing. For conditional dumping in MVS environments, SLIP (Serviceability Level Indication Processing) traps allow operators to set event-based triggers—such as specific ABEND codes, storage alterations, or program interruptions—that activate dumps only under defined criteria, reducing overhead in high-volume production systems. In other legacy systems like OpenVMS (formerly VMS), core dumps are captured as .DMP files, typically SYS$SYSTEM:SYSDUMP.DMP for system-wide failures, storing physical memory contents, error log buffers, and processor registers in a selective or full format configurable via system parameters. Over time, the reliance on mainframe core dumps has diminished with migrations to distributed and hybrid cloud architectures, where enhancements—such as improved integration with containerized environments in versions post-2.5—facilitate cross-platform diagnostics, though traditional SVC and SLIP mechanisms persist for enterprise .

Specialized Contexts

Space Missions

In software, core dumps serve as critical diagnostic tools for identifying faults in mission-critical environments, where remote analysis is essential due to the inability to physically access hardware. NASA's flight software, often built on the (RTOS), incorporates core dump capabilities to capture memory states during anomalies, enabling ground teams to reconstruct error conditions. For instance, supports automated core dump generation upon exceptions like segmentation faults, which has been integral to NASA's deep space missions for post-anomaly debugging. The (ESA) employs , an open-source RTOS, in satellite flight software to handle radiation-induced faults, such as single-event upsets (SEUs) that can lead to software crashes. supports mechanisms tested in ESA robustness evaluations for space hardware, ensuring reliability in radiation-heavy orbits. As of 2023, has been qualified for ECSS Criticality Category C and D in SMP configuration and used in missions like the spacecraft for payload data handling. Space missions face unique challenges with core dumps due to constrained resources. Limited onboard storage—often in the megabyte range for —forces selective dumping of only essential memory regions, while real-time constraints prohibit full dumps that could interrupt critical operations like attitude control. Telemetry downlink bandwidth, typically limited to kilobits per second during ground passes, requires compressing or prioritizing dump data for transmission, as seen in missions relying on intermittent contacts. Notable case studies highlight these applications. More recently, NASA's Perseverance rover, launched in 2021, uses VxWorks-based systems with diagnostic telemetry for fault isolation during surface operations. The Consultative Committee for Space Data Systems (CCSDS) protocols standardize this process, defining packet formats for reliable downlink of diagnostic data, including core dumps, integrated with onboard health monitoring to ensure interoperability across missions. As of 2025, the emphasizes core dumps for enhancing software reliability in the , 's planned orbital outpost. The Gateway's flight software, leveraging 's Core Flight System (cFS) framework, incorporates dump mechanisms to capture radiation and autonomy faults, supporting long-duration lunar operations amid evolving hardware like next-generation processors. This builds on historical practices, such as the 2024 Voyager 1 anomaly resolution, where a commanded core dump via pinpointed a faulty chip in the flight data subsystem after 46 years in space.

Embedded and Real-Time Systems

In embedded and real-time systems, core dumps are adapted to accommodate severe resource constraints, such as limited RAM (often 64 KB or less) and the absence of traditional filesystems, prioritizing minimal overhead to maintain system determinism and performance. Unlike full memory captures in desktop environments, these systems employ mini-dumps or task snapshots that record essential state information like CPU registers, stack traces, and select memory regions, enabling postmortem debugging without exhausting available resources. For instance, in FreeRTOS-based applications on microcontrollers like STM32, crash dumps are limited to task contexts and saved via custom handlers to avoid full RAM snapshots that could exceed heap limits of 8-60 KB. Triggers for core dumps in these environments often rely on hardware mechanisms to ensure reliability in timing-critical scenarios. Hardware watchdogs, which reset the system if not periodically fed, can be configured to invoke a software handler before reset, capturing a snapshot of the current task state for analysis. Non-maskable interrupts (NMIs) on microcontrollers like ARM Cortex-M serve similar purposes, halting execution on faults such as hard faults or bus errors to dump registers and stack without interference from maskable interrupts, preserving real-time behavior. These approaches draw briefly from Unix-like fault handling but are streamlined for embedded constraints, focusing on interrupt-driven capture rather than process signals. The format of core dumps in embedded systems deviates from standard ELF binaries, using custom binary blobs optimized for extraction via debug interfaces. Without filesystems, dumps are typically stored in non-volatile flash memory partitions or output over serial ports (e.g., UART) for retrieval, with sizes constrained to kilobytes to fit flash sectors. JTAG or SWD interfaces allow direct access to these blobs during debugging, enabling tools like GDB to reconstruct state from register dumps and partial memory. In Zephyr RTOS, for example, the core dump module supports configurable backends that serialize CPU registers and thread stacks into compact formats for offline analysis on IoT devices. Practical examples illustrate these adaptations in high-stakes applications. In automotive electronic control units (ECUs) compliant with , diagnostic event managers log fault snapshots—including task states and error codes—to for post-crash reconstruction, aiding in identifying software faults contributing to vehicle incidents without full system halts. For IoT devices running Zephyr OS on platforms like , core dumps capture fatal errors during connectivity tasks, stored to flash and retrieved via over-the-air updates, supporting the 2020s surge in connected devices. Security considerations are paramount, as dumps may expose like proprietary algorithms in resource-limited devices. Encryption of dump data using AES before storage in flash protects sensitive contents, ensuring that even if extracted, the information remains unintelligible without keys managed via secure elements. This practice has gained prominence amid the IoT expansion, where standards emphasize secure diagnostics to prevent . Trade-offs in dump implementation balance utility against real-time constraints, often favoring partial dumps of registers and active task stacks over comprehensive memory images to minimize capture latency (typically under 1 ms) and storage footprint. Full dumps risk performance degradation or system instability in RTOS schedulers, whereas selective snapshots suffice for identifying common faults like stack overflows, as seen in FreeRTOS hard fault handlers.

References

  1. https://www.man7.org/linux/man-pages/man5/core.5.html
  2. https://www.computinghistory.org.uk/sec/3433/Core-Memory/
  3. https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/memory-dump-file-options
  4. https://www.redhat.com/en/blog/a-guide-to-core-dump-handling-in-openshift
  5. https://man7.org/linux/man-pages/man5/core.5.html
  6. https://people.ee.duke.edu/~sorin/ece152/lectures/6.2.1-memory.pdf
  7. https://os.cs.luc.edu/processes.html
  8. https://sourceware.org/glibc/manual/2.39/html_node/Program-Error-Signals.html
  9. https://spectrum.ieee.org/bits-of-history
  10. https://ethw.org/Magnetic-Core_Memory
  11. https://www.ibm.com/history/system-360
  12. https://people.csail.mit.edu/saltzer/Multics/Multics-Documents/MSPM/bw-2.661122.ge-645-xray.pdf
  13. https://dsf.berkeley.edu/cs262/unix.pdf
  14. https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub151-1.pdf
  15. https://www2.cs.uregina.ca/~hamilton/courses/330/notes/history/history.html
  16. https://man7.org/linux/man-pages/man7/signal.7.html
  17. https://man.freebsd.org/cgi/man.cgi?query=signal&sektion=7
  18. https://man.freebsd.org/cgi/man.cgi?query=core&sektion=5
  19. https://man7.org/linux/man-pages/man1/gcore.1.html
  20. https://en.cppreference.com/w/c/program/abort
  21. https://pubs.opengroup.org/onlinepubs/9699919799/functions/abort.html
  22. https://sourceware.org/gdb/current/onlinedocs/gdb.html/Core-File-Generation.html
  23. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/developer_guide/debugging-crashed-application
  24. https://www.cse.unsw.edu.au/~learn/debugging/modules/gdb_coredumps/
  25. https://www.jetbrains.com/help/clion/core-dump-debug.html
  26. https://code.visualstudio.com/docs/cpp/cpp-debug
  27. https://sourceware.org/gdb/current/onlinedocs/gdb.html/Threads.html
  28. https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
  29. https://clang.llvm.org/docs/UsersManual.html
  30. https://www.redbooks.ibm.com/redbooks/pdfs/sg247816.pdf
  31. https://www.magnetforensics.com/blog/full-memory-crash-dumps-vs-raw-dumps-which-is-best-for-memory-analysis-for-incident-response/
  32. https://sec.cloudapps.cisco.com/security/center/resources/forensic_guides/ios_forensic_investigation.html
  33. https://www.sans.org/blog/cisco-router-forensics
  34. https://www.bankinfosecurity.com/linux-crash-dump-flaws-expose-passwords-encryption-keys-a-28560
  35. https://www.brendangregg.com/FlameGraphs/memoryflamegraphs.html
  36. https://docs.oracle.com/en/enterprise-manager/cloud-control/enterprise-manager-cloud-control/13.5/emdbc/oracle-real-application-cluster-database-compliance-standards.html
  37. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere-sdks-tools/8-0/web-services-sdk-programming-guide/virtual-machine-security/how-virtual-machine-encryption-protects-a-datacenter/what-is-encrypted/core-dump-files.html
  38. https://sourceware.org/gdb/onlinedocs/gdb/Backtrace.html
  39. https://blog.sergiodj.net/posts/linux-memory-mapping/
  40. https://sourceware.org/gdb/onlinedocs/gdb/Examining-the-Core.html
  41. https://lldb.llvm.org/
  42. https://lldb.llvm.org/use/map.html
  43. https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/analyzing-a-kernel-mode-dump-file-with-windbg
  44. https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/analyzing-a-user-mode-dump-file
  45. https://clang.llvm.org/docs/AddressSanitizer.html
  46. https://github.com/google/sanitizers/wiki/AddressSanitizer
  47. https://www.freedesktop.org/software/systemd/man/latest/coredumpctl.html
  48. https://github.com/getsentry/coredump-uploader
  49. https://github.com/pwndbg/pwndbg
  50. https://pwndbg.re/stable/features/
  51. https://refspecs.linuxfoundation.org/elf/gabi4+/ch4.sheader.html
  52. https://refspecs.linuxfoundation.org/elf/gabi4+/ch5.pheader.html
  53. https://learn.microsoft.com/en-us/windows/win32/debug/minidump-files
  54. https://learn.microsoft.com/en-us/windows/win32/api/minidumpapiset/ns-minidumpapiset-minidump_header
  55. https://access.redhat.com/solutions/901293
  56. https://manpages.ubuntu.com/manpages/jammy/man5/core.5.html
  57. https://www.freedesktop.org/software/systemd/man/coredump.conf.html
  58. https://www.freedesktop.org/software/systemd/man/systemd-coredump.html
  59. https://access.redhat.com/solutions/4896
  60. https://docs.oracle.com/en/operating-systems/oracle-linux/6/[security](/page/Security)/ol_discdp_sec.html
  61. https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html
  62. https://wiki.ubuntu.com/Apport
  63. https://fedoraproject.org/wiki/Changes/coredumpctl
  64. https://interrupt.memfault.com/blog/linux-coredumps-part-1
  65. https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/user-mode-dump-files
  66. https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps
  67. https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/varieties-of-kernel-mode-dump-files
  68. https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/generate-a-kernel-or-complete-crash-dump
  69. https://learn.microsoft.com/en-us/previous-versions/troubleshoot/windows-server/disable-enable-dr-watson-program
  70. https://learn.microsoft.com/en-us/windows/win32/win7appqual/fault-tolerant-heap
  71. https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/task-manager-live-dump
  72. https://learn.microsoft.com/en-us/sysinternals/downloads/procdump
  73. https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-dump--create-dump-file-
  74. https://nvidia.custhelp.com/app/answers/detail/a_id/3335
  75. https://learn.microsoft.com/en-us/answers/questions/3222831/is-it-safe-to-delete-system-minidump-files-or-syst
  76. https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/read-small-memory-dump-file
  77. https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/overview
  78. https://www.ibm.com/docs/en/zos/2.5.0?topic=aids-svc-dump
  79. https://www.ibm.com/docs/en/zos/2.5.0?topic=dumps-specifying-sys1dumpxx-data-sets
  80. https://www.ibm.com/docs/SSLTBW_3.1.0/com.ibm.zos.v3r1.ieag100/dumpds.htm
  81. http://www.bitsavers.org/pdf/ibm/360/os/R21.0_Mar72/GC28-6670-5_Programmers_Guide_to_Debugging_Rel_21_Mar72.pdf
  82. https://www.ibm.com/docs/en/zos-basic-skills?topic=code-steps-obtaining-abend
  83. https://www.ibm.com/docs/en/SSLTBW_2.4.0/pdf/ieac500_v2r4.pdf
  84. https://www.ibm.com/docs/en/zos/2.5.0?topic=command-setting-slip-trap
  85. https://wiki.vmssoftware.com/Dump_File
  86. https://www.ibm.com/docs/en/zos/3.1.0?topic=overview-whats-new
  87. http://www.staroceans.org/kernel-and-driver/vxworks_device_driver_developers_guide_vol2_6.6.pdf
  88. https://www.researchgate.net/publication/224625009_The_Mars_Rover_Spirit_FLASH_anomaly
  89. https://www.um.edu.mt/library/oar/bitstream/123456789/58998/1/Separation_kernel_robustness_testing.pdf
  90. https://ecss.nl/wp-content/uploads/2023/10/ECSS-E-HB-20-40A%2811October2023%29.pdf
  91. https://www.rtems.org/news/2022-02-03-rtems-qualifies-for-the-space-domain/
  92. https://elib.dlr.de/67884/1/AIAA-2010-2218-802.pdf
  93. https://arc.aiaa.org/doi/pdf/10.2514/6.2016-2525
  94. https://www.nasa.gov/history/lewis-experts-supported-a-critical-repair-on-hubble-in-the-1990s/
  95. https://ntrs.nasa.gov/api/citations/20240005103/downloads/cFS_SMD_2024_FULL.pdf
  96. https://nasaspacenews.com/2024/03/voyager-1-a-glitch-in-the-deep-space-network/
  97. https://forums.freertos.org/t/freertos-memory-requirements/15928
  98. https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/core_dump.html
  99. https://interrupt.memfault.com/blog/firmware-watchdog-best-practices
  100. https://docs.zephyrproject.org/latest/services/debugging/coredump.html
  101. https://developer.espressif.com/blog/2023/07/core-dump-a-powerful-tool-for-debugging-programs-in-zephyr-with-esp32-boards/
  102. https://www.evu-online.org/accident-reconstruction-with-data-recorded-by-electronic-control-units-in-toyota-vehicles-with-a-pre-collision-system
Add your contribution
Related Hubs
User Avatar
No comments yet.