For purposes of this website, the term ‘Crash Dump Mechanism’ encompasses all of the components that make up or influence the crash dump path, as well as the procedure itself for generating a crash dump file or writing to the hibernation file.  Please note that the crash dump mechanism implements both hibernation and system crash capabilities.

There are three primary components in the crash dump mechanism:

  1. The kernel
  2. crashdmp.sys (post-vista)
  3. The crash dump driver stack or just “crash dump stack”, which consists of the dump port driver, dump miniport driver, and crash filter drivers

The crash dump stack is initialized in two distinct phases:

  1. Pre-initialization -when the kernel is initialized during system boot-up and when a page file is created (since crash dump files are written to the page file)
  2. Post-initialization – after the system crashes (bugchecks) or is going into hibernation, initialization is completed just before the stack is used

When the crash dump stack is being used, the system switches to a special mode known as “crash mode”, in which nearly all operating system features are disabled, so that the crash or hibernate can be completed in an isolated environment.  The restrictions of crash mode include:

  • The normal I/O path is completely disabled
  • All CPU’s are disabled except the one that the current thread is executing on
  • The single, active CPU becomes single-threaded with HIGH_LEVEL IRQL and is uninterruptible
  • I/O sent through the crash dump stack is synchronous
  • For IDE controllers, only the channel containing the device with the paging file is enabled

With crash mode enabled, the kernel begins the requested operation – to either generate a crash dump file in the page file or to write hibernation data to the hiberfil.sys file.  All I/O is sent through the crash dump stack instead of the driver stack in the normal I/O path.

%d bloggers like this: