Info on Crashdump Generation

[Vir Gnarus]

A response I made in order to clarify what goes on during crashdump creation:


As for paging file info stored on the crashdumps, information stored that has been paged out and stored only on the paging file cannot be recovered during a crashdump. The only I/O KeBugCheck can do with drive is to produce the crashdump. It requires the paging file to do so, because it's the only sure location on the drive where it has the best chance of writing too. Once it writes, it overwrites anything existing currently on the paging file. Obviously, it cannot access any currently existing data on the paging file to include into the dump while it's overwriting it. It's the reason why the paging file must exist and it must be the right size to generate the type of dump file that was set in Advanced system settings. The paging file essentially turns into a free location on the drive for which KeBugCheck can dump the contents of physical memory onto.

Details are located here. Notably, this paragraph:

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.

Also, consider this comment:

A pagefile is required on the boot volume in order to capture any sort of dump. The reason for this is that when a bugcheck occurs, by definition this means that something has failed at the kernel level. The kernel is of course the level at which drivers load, and this includes the disk drivers like NTFS.SYS. When a system experiences a bugcheck, it cannot guarantee that it will be able to reliably write dump information using the already loaded kernel drivers, since that driver may very well be what caused the crash in the first place. Because of this, the bugcheck process keeps a seperate copy of NTFS.SYS in memory, that is not actively used by the kernel. It loads this copy when a bugcheck occurs and uses that to be able to reliably be able to write to the disk. However, there is no way for this driver to know about all the other drives that may be attached to the system; other than the system drive which has to exist. Because of this, the dump process uses the system drive because it knows it has to be there under any circumstance. Therefore, the system drive much include a pagefile of enough size to capture the dump of the type you have set.

And another interesting tip here:

The paging file on %systemroot% partition is required to create dump file in 2003. In Windows 2008 we can use DedicatedDumpFile on any drive to remove the requirement of paging file on %systemroot% partition, so we can create dump file without having a paging file on C starting from 2008.

What Jeremy mentioned is correct. Unchecking "Overwrite any existing file" cannot give us multiple memory.dmp. Unchecking it will cause the new dump file cannot be created if a memory.dmp already exists there.