Windows 2000 Blue Screen Crash Dump Process

When Microsoft Windows 2000 encounters an unrecoverable kernel-level error, it initiates a Stop error—commonly known as a Blue Screen of Death (BSOD)—to protect file systems and hardware from corruption. During this event, the operating system halts normal operations, outputs diagnostic text to the display, and records volatile memory contents to the boot drive's paging file. Upon the subsequent reboot, Windows extracts this data into a dedicated dump file (MEMORY.DMP or a minidump) so system administrators and developers can analyze the root cause using kernel debugging tools.

The BugCheck Routine

The crash sequence begins when the kernel or a kernel-mode driver detects a fatal condition and calls KeBugCheck or KeBugCheckEx. This function:

  1. Disables all system interrupts by raising the Interrupt Request Level (IRQL) to HIGH_LEVEL.
  2. Halts all other processors on multiprocessor systems.
  3. Switches the video subsystem to a standard VGA text-mode display to present the Stop error code, memory parameters, and the faulting driver name.
  4. Checks the system configuration to determine if a memory dump should be written.

Writing to the Paging File

Because the standard file system and storage stacks may be corrupted, Windows 2000 cannot safely use standard I/O routines to create a file during a crash. Instead, it writes raw memory contents directly to contiguous sectors in PAGEFILE.SYS located on the boot partition (%SystemDrive%).

To bypass potentially unstable storage drivers, the kernel uses a lightweight disk driver loaded during boot specifically for crash dumps. The system marks the paging file header with a special signature to identify that it contains crash data rather than standard swap memory.

Dump Types in Windows 2000

Windows 2000 introduced three distinct dump configurations selectable through System Properties:

  • Complete Memory Dump: Writes the entire contents of physical RAM. This requires a paging file on the boot volume at least equal to physical RAM plus 1 megabyte (MB).
  • Kernel Memory Dump: Captures only kernel-mode memory space, excluding user-mode applications and unallocated memory. This significantly reduces dump size while retaining the necessary information for driver and OS debugging.
  • Small Memory Dump (64 KB): Records only the Stop code, parameters, loaded driver lists, and the processor context of the thread that crashed. These files are saved directly into the %SystemRoot%\Minidump directory.

Post-Reboot Extraction

Once the system is restarted after a crash, the operating system executes the following steps during initialization:

  1. The Session Manager (SMSS.EXE) checks the paging file on the boot volume for the crash signature.
  2. If a valid crash signature is found, the SAVEDUMP.EXE process is invoked.
  3. SAVEDUMP.EXE reads the crash data out of the paging file and writes it to %SystemRoot%\MEMORY.DMP (or the Minidump folder).
  4. The signature in the paging file is cleared, returning PAGEFILE.SYS to normal virtual memory operation.

Kernel Debugging and Analysis

The resulting dump file can be analyzed using Microsoft debugging utilities, such as WinDbg, KD, or the legacy I386KD.EXE. Debuggers read the dump along with corresponding debugging symbols (.PDB or .DBG files) to reconstruct the call stack, inspect register states, evaluate I/O Request Packets (IRPs), and identify the specific driver instruction that triggered the crash.