Consider the following scenario:
- You configure Windows Server 2003 to dump physical memory to a location other than the boot volume.
- Windows Server 2003 experiences a fatal error.
When Windows restarts after the fatal error, Windows requires a temporary file on the boot volume that is equal to the physical memory that is installed in the computer. If there is not enough hard disk space available to meet this requirement, the memory dump file is still generated. However, the pagefile size on this volume is reduced.
This behavior occurs because Windows Server 2003 introduces the following design changes for dump file generation:
- In the first stage of a memory dump operation, the Session Manager Subsystem process (SMSS.exe) performs part of the Savedump tool's job before Windows creates the pagefile. SMSS examines the pagefile head block to determine whether this file is a valid memory dump file. If the memory dump file is valid, SMSS truncates the original pagefile to the size of the dump file and renames this file to Dumpxxx.tmp.
Note The xxx part of this file name is calculated from the Lower Word of the tickcount function.
SMSS stores the Dumpxxx.tmp file on the boot volume and removes both the hidden attribute and the system attribute from this file. SMSS also sets the TempDestination value and the DumpFile value in a volatile registry subkey. This subkey is later read by the Savedump.exe process when the process copies Dumpxxx.tmp to Memory.dmp.
- In the second stage of the memory dump operation, the Savedump.exe process examines the following registry location to determine whether a volatile subkey exists:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\MachineCrash
The existence of a volatile registry key indicates that a valid memory dump file has been created. In this scenario, the Savedump.exe process reads the data from the TempDestination registry value and copies the dump file to the correct location.
SMSS requires a temporary file on the boot volume for the following reasons:
- In this scenario, SMSS can safely write only to the boot volume. The write operation for crashdump information ignores filter drivers.
Note The SMSS process cannot write a dump file to a redundant array of independent disks (RAID) array because the process skips filter drivers. Therefore, the temporary file should be written to a boot volume. - In this scenario, SMSS uses the NtSetFileInformation function with the renaming operation to truncate the pagefile to the size of the temporary file. This function supports rename operations only on the same volume.
For more information about situations in which a Memory.dmp file is not created after a STOP error message, click the following article number to view the article in the Microsoft Knowledge Base:
130536
Windows does not save memory dump file after a crash