How Kdump Works in Linux to Capture Crash Dumps

The Kdump service is the standard kernel crash dumping mechanism in Linux, designed to reliably capture memory images (vmcore) when a system experiences a kernel panic or unexpected crash. It accomplishes this by utilizing the kexec system call to boot directly into a secondary, isolated "capture kernel" without undergoing a hardware reset or BIOS reboot. This isolated environment prevents data corruption and ensures that the volatile memory state of the crashed system is safely extracted and written to persistent storage for post-mortem analysis.

Memory Reservation and Initialization

Kdump relies on physical memory pre-allocation during the initial system boot. Through the crashkernel bootloader parameter, the primary operating system reserves a dedicated block of RAM exclusively for the capture kernel. Because the primary kernel cannot access or write to this reserved space, the capture kernel remains untouched and uncorrupted, even during catastrophic system failures.

The Trigger Mechanism

A crash dump can be triggered by critical kernel events, including:

• Unhandled kernel panics or fatal exceptions.
• Non-Maskable Interrupts (NMI).
• Hardware errors reported via Machine Check Exceptions (MCE).
• Manual invocation via the magic SysRq key (echo c > /proc/sysrq-trigger).

Once a panic routine is executed, execution switches directly from the primary kernel's fault handler to the Kdump workflow.

The Kexec Handover

Traditional system reboots clear volatile RAM and reinitialize hardware devices, destroying critical forensic data. Kdump avoids this by using kexec, a Linux subsystem that allows loading and executing a new kernel directly from the currently running one. When the system panics, control is transferred directly to the capture kernel sitting in the pre-reserved memory space, bypassing the BIOS/UEFI firmware completely.

Capturing and Filtering the Memory Dump

Once booted, the capture kernel mounts a minimal root environment (usually an initramfs) and initiates the dump process:

1. Accessing Memory: The physical memory of the crashed primary kernel is exposed as an ELF-formatted file located at /proc/vmcore.
2. Filtering with makedumpfile: To optimize storage space and transfer speed, the makedumpfile utility compresses the dump and strips unnecessary data, such as zero-filled pages, user-space application memory, free pages, and cache pages.
3. Saving the Image: The processed vmcore is written to a designated target defined in the Kdump configuration file (/etc/kdump.conf). Supported targets include local filesystems, raw disk partitions, network shares (NFS/CIFS), or remote targets via SSH.

Reboot and Analysis

After the memory image has been successfully written to the destination, the capture kernel triggers a normal system reboot to return the machine to its operational state.

System administrators and kernel engineers analyze the captured vmcore file using analysis tools such as the crash utility or gdb. Paired with the matching unstripped kernel image (vmlinux) and debugging symbols (debuginfo), the captured memory dump allows engineers to inspect the call stack, view process tables, analyze memory structures, and determine the exact root cause of the kernel failure.