By now you ought to know
what a BSOD is, maybe you also have read some other things as well before reading this and are familiar with some commands or understand concepts such as threads and stacks.
Knowing how a BSOD crash dump file is being generated is equally important to know, if not more important because it will allow you, or at least assist you with troubleshooting why a computer is not creating a dump file.
Without a dump file, it is often not doable to start troubleshooting and it would be a bit awkward to say you're able to analyze and debug dump files but don't know how they're created.
There are a couple of phases involved with dump file generation.
Phases
-
Setup
-
During the boot, the one preceding the crash
-
User adjustments
-
The crash itself
-
The reboot
-
Additional
Setup
The first phase is happening during the installation of Windows, this is the part where Windows configures everything in case it is forced to shut down. To be more precise, this is the part where Windows sets all subkeys, value and related data in the registry for the scenario of a BSOD.
The setup does not include any volatile settings that are created during the process of the BSOD.
During the boot, the one preceding the crash
Each time Windows boots, it checks the crash dump options configured by reading the registry key HKLM\SYSTEM\CurrentControlSet\Control\CrashControl.
If a dump is configured, the value CrashDumpEnabled's data is not 0x0 or '(none)' (from the GUI), a copy of the disk Miniport driver is created which is used to write to the volume in memory and given the same name as the Miniport with the prefix "dump_" added.
The DumpFilters value will also be queried for any filter drivers that are required for writing to the volume, an example is Dumpfve.sys, the BitLocker Drive Encryption Crashdump Filter driver.
Windows will also collect information related to the components involved with writing a crash dump, including the name of the disk Miniport driver, the I/O manager structures that are necessary to write the dump and the location where the paging file is on the disk, Windows will save 2 copies of the data in dump-context structures.
User adjustments
The second phase is the phase that provides the user with an opportunity to adjust settings (un)related to dump file generation.
This phase is not only the Startup and Recovery settings which allows you to adjust what kind of a dump you want to create, this phase also includes settings that indirectly may affect the generation of a dump file, one example is the settings for the pagefile.
The crash itself
In this phase, crashdump.sys (located in %SystemRoot%\System32\Drivers, %systemroot% usually refers to C:\Windows, depending on the environment variables this may be different) verifies the integrity of the 2 dump-context structures obtained at boot by performing a memory comparison. If there isn't a match, no crash dump will be created as creating a memory dump would likely fail or corrupt the disk.
Upon a successful match, crashdmp.sys, with support from the disk Miniport driver and other drivers with the dump_ prefix, writes the dump information directly to the disk sectors occupied by the pagefile (i.e. saves it in the pagefile). It does this without the file system driver or storage driver stack as they might have been corrupted or even have caused the crash.
The reboot
During the boot process, the Session Manager (smss.exe) will check HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ExistingPageFiles for a list of existing pagefiles and loops through the list calling SmpCheckForCrashDump on each file present, looking to see whether the pagefile contains crash dump data. It does this by searching the header of the pagefile for the signature PAGEDUMP for 32-bit systems and PAGEDU64 for 64-bit systems.
If crash dump data is present then the Session Manager reads a set of crash parameters from the HKLM\SYSTEM\CurrentControlSet\Control\CrashControl key, such as the name of the dump file which is typically %SystemRoot%\MEMORY.dmp unless configured differently.
The Session Manager will also check whether the location is on a different partition than the paging file. If this is the case, another check is performed to ensure there is enough free disk space. The space that is required for the crash dump is stored in the dump header of the page file.
After those checks, the paging file is truncated to the size of the crash data, renamed to the format DUMPxxxx.tmp, where 'xxxx' is the current low-word value of the system's tick count, the hidden and system attributes removed and an appropriate security descriptor is set to secure the crash dump.
After setting an appropriate security descriptor the Session Manager creates a volatile registry key under CrashControl called MachineCrash where the temporary filename is stored as DumpFile.
A DWORD value as TempDestination is also created in this key, this value indicates if the dump file location is only a temporary location. If the pagefile is on the same partition as the destination, a temporary dump will not be used in which case the DumpFile value data will be the target dump file and TempDestination will be '0'.
Later in the boot process, when Wininit.exe is doing its part, Wininit.exe will check for the presence of the MachineCrash key and if it is present then WerFault will be executed with the -k -c flags (k flag indicates kernel error reporting, c flag indicates that the complete memory dump or kernel memory dump should be converted to a minidump) and read the TempDestination and DumpFile values. To get a picture when this happens I recommend to read
¹Boot Troubleshoot.
If TempDestination is 1, indicating a temporary file is used, then the temporary file is moved to the destination location and WerFault will secure the file by only allowing the System account and the local Administrators group access.
WerFault will then write the final name of the dump file to the value FinalDumpFileLocation in the MachineCrash key.
From Windows Internals 6th Edition
WerFault will also perform a few other actions to prepare to send a crash dump report to the Microsoft Online Crash Analysis (OCA) site, or, if configured, an internal error server
- If the generated dump was not a minidump, it will extract a minidump from the dump file and store it in the default location configured by the value MinidumpDir in the CrashControl key, which is by default '%SystemRoot%\Minidump'.
- It writes the name of the minidump file to 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\KernelFaults\Queue'.
- It adds a command to execute WerFault.exe with the -k -qr flags (qr flag specifies to use the queued reporting mode and that WerFault should be restarted), to 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce' so that WerFault is executed during the first user's logon to the system for purposes of actually sending the error report.
If you need more control over where the crash dump data is written to, in case of insufficient free space for example, Windows provides an option to use a
dedicated dump file that is configured in the DedicatedDumpFile and DumpFileSize values in the CrashControl key. If this is specified, Windows will write the dump file to the specified location instead. If DumpFileSize is not given, Windows creates a dump file using the largest file size required for a complete dump. The required size is calculated by the size of the total number of physical pages of memory present in the system plus the size required for the dump header (one page on x86 system and two pages on x64 system), plus the maximum value for secondary crash dump data, 256MB.
In case the destination location doesn't have enough space for a kernel memory dump or a complete memory dump then the system will fall back to writing a minidump instead.
Additional
Crash during boot process
It can happen that BSOD crashes occur during the boot process.
Because paging is enabled early in the boot process, even before ntoskrnl is loaded, it still is possible for dumps to be generated when a crash happens during the boot process.
No dump file
If no dump file is being generated, for any reason, you can still identify a bugcheck happens by a few event ids.
- Event id 1001, this is the event that contains the bugcheck, commonly the most interesting one
- Event id 161, this id is related to the dump file generation error. When you see this one Windows couldn't generate a dump for the last crash
- Event id 6008, this event indicates that the last shutdown was unexpected, this may not always be related to a BSOD
- Event id 41, the infamous 41 indicates an unexpected reboot without cleanly shutting the system down first
All of these event IDs are recorded under System.
It is also possible that no dump file is generated due to hard drive issues or corrupt storage drivers. Hard drive issues can commonly be identified in the System events as well.
References:
Windows Internals 6th edition part 2
GetTickCount function (sysinfoapi.h)
¹BSOD Crash Dump Generation
¹BSOD-related Registry Entries
¹ Courtesy of John Carrona (usasma)
