By default, all Windows systems are configured to attempt to capture information about the state of the operating system in the event of a system crash. Remember that we are talking about a total system failure here, not an individual application failure. The settings for the dump files are configured using the System tool in Control Panel. Within this tool, select System Properties - on the Advanced tab there is a section for Startup and Recovery. Clicking on the Settings button brings up the dump file options as shown below. There are three different types of dump that can be captured when a system crashes:
Complete Memory Dump : This contains the entire contents of the physical memory at the time of the crash. This type of dump will require that there is a page file at least the size of physical memory plus 1MB (for the header). Because of the page file requirement, this is an uncommon setting especially for systems with large amounts of RAM. Windows NT4 only supported a Complete Memory Dump. Also, this is the default setting on Windows Server systems.
Kernel Memory Dump : A kernel dump contains only the kernel-mode read / write pages present in physical memory at the time of the crash. Since this is a kernel-mode only dump, there are no pages belonging to user-mode processes. However, it is unlikely that the user-mode process pages would be required since a system crash (bugcheck) is usually caused by kernel-mode code. The list of running processes, state of the current thread and list of loaded drivers are stored in nonpaged memory that saves in a kernel memory dump. The size of a kernel memory dump will vary based on the amount of kernel-mode memory allocated by the Operating System and the drivers that are present on the system.
Small Memory Dump : A small memory (aka Mini-dump) is a 64KB dump (128KB on 64-bit systems) that contains the stop code, parameters, list of loaded device drivers, information about the current process and thread, and the kernel stack for the thread that caused the crash.
Something to note here - although the need for a complete memory dump is rare when dealing with bugchecks, a complete memory dump is almost always required for manually generated crash dumps used to diagnose soft hangs on a system (for more information regarding the difference between a soft and hard hang, please see our Troubleshooting Server Hangs - Part One ). This is because when looking at soft hangs we will need to look at user-mode processes, deadlocks etc. However, regardless of which type of dump you are capturing, there must be a correctly sized page file on the boot volume. For complete dumps, as stated above, this page file will need to be Physical RAM + 1MB.
So in reviewing the three types of dumps above, the kernel memory dump offers the most practical option when dealing with system crashes and bugchecks. Remember that the size of the kernel memory dumps will vary depending on the amount of kernel-mode memory allocated and the drivers loaded. On systems with more RAM, it is reasonable to expect that the dump file will be larger. There is no way to predict the exact size of a kernel memory dump. When you configure kernel memory dumps the system checks to see if the page file is large enough. There are some guidelines for the minimum page file size needed for kernel memory dumps, however given that the size of kernel mode memory will vary, there is no accurate measure for the maximum. The default minimum page file sizes for kernel dumps are shown below:
| Physical RAM | Minimum Page File Size (Kernel Dump) |
| < 128MB | 50MB |
| < 4GB | 200MB |
| < 8GB | 400MB |
| >= 8GB | 800MB |
If you are concerned about setting the maximum page file size too low to be able to capture a kernel dump, the only way to get a better estimate would be to force a manual crash using the CrashOnCtrlScroll method described in Microsoft KB Article 244139 . Once the system has rebooted, check to see if a kernel dump was generated and check the size. The other alternative (for 32-bit systems) would be to set the page file on the boot volume equal to 2GB + 1MB. This is because the maximum kernel-mode address space available on 32-bit systems is 2GB.
Let's take a quick moment and talk about how the dump files themselves are generated. When a system boots up, it checks the crash dump options in the HKLM\System\CurrentControlSet\Control\CrashControl registry key. All of the settings available in the GUI can be modified via the registry as shown below:
- Write an event to the System Log checkbox = LogEvent
- Automatically Restart checkbox = AutoReboot
- Write Debugging Information drop-down = CrashDumpEnabled
- Dump File text box = DumpFile
- Overwrite any existing file checkbox = Overwrite
Returning to the subject of how the dump file itself is generated, If a dump is configured, the system makes a copy of the disk miniport driver used to write to the boot volume in memory and prepends the driver name with "dump_". The system also checksums all of the components involved with writing a crash dump, (including the copied disk miniport driver), the I/O manager functions that write the dump and the map of where the boot volume's page file is on the disk. This checksum is saved. When the KeBugCheck function executes it checksums these components again and compares this checksum to the one created at boot. If these checksums do not match, no dump file is written (because of the risk of corrupting the disk). If the checksum matches, the dump information is written directly to the sectors on disk occupied by the page file. The file system driver is completely bypassed - because it may be corrupted or be the cause of the crash. When SMSS.EXE enables paging during the boot process, the system examines the boot volume's page file to see if there is a crash dump present. If one exists, then this part of the page file is protected. This makes all (or part) of the boot volume's page file unusable during the early part of the boot process. This may result in notifications that the system is low on virtual memory - a temporary condition. Later in the boot process, WINLOGON.EXE calls the SAVEDUMP.EXE process to extract the dump from the page file and copy it to the final location that is specified in the Dump File field.
On Windows Server 2003, there is some slightly different behavior that is outlined in KB Article 886429 . Following the server reboot after the bugcheck, Windows requires a temporary file on the boot volume equal to the size of physical RAM. If there is insufficient disk space to meet this requirement, the dump file is still generated, however the page file size on this volume is reduced. In the first stage of the dump operation, the Session Manager Subsystem (SMSS.EXE) examines the page file head block to determine whether the file is a valid memory dump. If the file is valid, then SMSS.EXE truncates the page file to the size of the dump file and renames the file to Dump xxx .tmp (the xxx value is calculated from the Lower Word of the tickcount function). SMSS stores the Dump xxx .tmp file on the boot volume and sets a TempDestination value and a DumpFile value in a volatile registry subkey ( HKLM\System\CurrentControlSet\Control\CrashControl\MachineCrash ). SAVEDUMP.EXE reads this registry location to determine if a valid memory dump exists and copies the Dump xxx .tmp file to Memory.dmp.
And that brings us to the end of this post. Until next time ...
Additional Resources:
- KB 274598: Complete Memory Dumps are not saved on computers with 2 or more GB of RAM
- KB 254649: Overview of memory dump file options for Windows Server 2003, XP and Windows 2000 ...
- KB 244139: Generating a manual crash dump using the keyboard
- KB 108393: Overview of the /maxmem switch in the boot.ini
- KB 886429: What to consider when you configure a new location for Memory Dump Files in Windows...
| Share this post : |
|
|
|
|
|