John Carrona - Microsoft MVP

Windows Expert - Consumer

www.carrona.org

I have the Knack: sound byte here



BSOD Crash Dump Generation RSS Feed Subscribe to the RSS feed Last updated:  02 May 2011



5 PHASES OF DUMP FILE GENERATION (Setup, user adjustment of settings, during the boot, during the crash, after the reboot):

Phase 1 (Setup)
The system obtains much of the initially required settings/entries automatically while Windows is installing - so you won't even know that this is going on.  It's determined by the hardware on your system and how Windows interprets this information during setup.  Unless you're an advanced user, there's very little opportunity for you to influence the factors involved in this phase.

Phase 2 (User adjustments)
Next is the opportunity for the user to modify settings.  This not only includes the BSOD settings in Control Panel and in the registry, but also includes unrelated settings that amy affect the generation/collection of memory dumps.  One such example is the settings used for the pagefile.  There's a list of the registry settings at http://www.carrona.org/bsodreg.html

Phase 3 (During the boot - the one preceding the crash)
Hal.dll and boot start drivers load before the pagefile is initialized - so a BSOD then can't save a memory dump (hence, live debugging is required to capture a memory dump)
Creation of pagefile occurs during the Memory Manager initialization (part of the kernel initialization - I believe it's in Phase 1)
At boot, the system checks the crash dump options in the Registry (HKLM\SYSTEM\CurrentControlSet\Control\CrashControl)
If a dump is configured, it makes a copy of the disk miniport driver and appends "dump_" at the beginning of the filename
System then checksums (and saves) the components involved in generating the memory dump. (dump_ miniport driver, I/O Manager functions that write the dump, and the map of where the boot volume's paging file is on disk).

Phase 4 (The crash itself)
When the KeBugCheck function executes, it checksums the components again.
If they don't match, then no dump is written (to prevent data corruption)
If they do match, then the dump is written directly to the sectors occupied by the pagefile.  It bypasses the file system and storage driver stack (including the disk miniport driver) - using the dump_ copied driver instead.
If a dedicated dump file is specified, then the crash dump driver (crashdump.sys) creates the dump file and it's required size and writes it to the dedicated dump file location (instead of the pagefile).  If not enough space for a complete or kernel dump - the system falls back to writing a minidump.

Phase 5 (After the reboot)
For more detail, see Boot Process Troubleshooting page here:  http://www.carrona.org/boottrbl.html
During the reboot, the Session Manager (SMSS.exe) enables paging (function NtCreatePagingFile)
and the system then checks to see if there's a dump file (by calling function SmpCheckForCrashDump)
If there is a dump file, that portion of the pagefile is protected (may result in low virtual memory error messages)
During this time (Phase 0 of kernel initialization - generally before Windows Splash Screen shows up), Driver Verifier is enabled and then Kernel Debugger is attached (if used).  Initialization is finished later on (see http://www.carrona.org/boottrbl.html )
If the target dump file is located on another drive, then the system (winlogon.exe calling savedump.exe) renames the pagefile to Dumpxxx.tmp (from pg 1130 of Windows Internals 5th Edition) and truncates the size to the size of the dump data (stored in the header of the dump file).  Removes Hidden and System attributes from the file
Creates volatile Registry key:  HKLM\SYSTEM\CurrentControlSet\Control\CrashControl\MachineCrash
Stores temporary dump file name in the value "DumpFile".  Writes REG_DWORD to "TempDestination" value indicating if it's a temporary destination or not (0x0 = not temp; 0x1 = temp)
NOTE:  If the pagefile is on the same volume as the final memory dump location - then no temporary file is used and TempDestination value is set to 0x0
Later on wininit.exe checks for the MachineCrash key.  If found, Wininit.exe launches WerFault.exe -k -c (k=kernel report; c=convert to minidump) which either renames or copies the temporary file to the final location
WerFault then writes the final dump name to the MachineCrash\FinalDumpFileLocation value



Ya gotta wonder when and how the MachineCrash key is deleted







© 2016 - John D. Carrona, Microsoft MVP
Windows Expert - Consumer
Forum screen name: usasma

Microsoft MVP Profile - http://mvp.microsoft.com/en-us/mvp/John%20D.%20Carrona-33494