How to use the DedicatedDumpFile registry value to overcome space limitations on the system drive when capturing a system memory dump
Prior to Windows Vista and Windows Server 2008 we had to keep a large page file on the system drive (typically drive C:) in order to properly capture system memory dumps for troubleshooting. This presented problems as systems with very large amounts of RAM became more common, resulting in requirements for very large amounts of free space on the C: drive, or requiring that system visible memory be artificially limited for troubleshooting purposes. This is no longer a requirement thanks to the Dedicated Dump File feature, which is available for use in Windows Vista and later operating systems.
What is it?
The dedicated dump file is basically a page file that is reserved for use only by the system crash dump routines. It is not used for paging virtual memory. Like a page file, the system process keeps an open handle to the dedicated dump file, which prevents it from being deleted. When you manually initiate a memory dump, or the system crashes on its own, the data is written into the dedicated dump file instead of the page file on the system drive. This feature is enabled by setting the following registry value:
Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl
Name: DedicatedDumpFile
Type: REG_SZ
Value: A dedicated dump file together with a full path, such as D:\dedicateddumpfile.sys
Where can it be stored?
The dedicated dump file can be stored on any local volume that can support a page file. This volume must be considered a fixed disk device and must not be hosting Windows clustered storage. For example, this means you can store this file on a second partition of your server’s primary hard disk, or on a SAN volume that is mounted early in the boot process.
Fun fact: Unlike a page file, you can actually direct the dedicated dump file to a sub-folder, even one that is actually a volume mount point. However, the sub-folder must pre-exist during boot, and there is generally little reason to actually do this.
How much space will it use?
You can automatically allow the system to determine the size of the dedicated dump file, or you can manually set the size by using the DumpFileSize registry value.
System determined size:
If you choose to let the system determine the size, then regardless of the dump file type set via the CrashDumpEnabled value, the dedicated dump file will be roughly the size of system visible RAM plus 256 MB. The extra 256 MB allows room for secondary dump data that may be written by driver bug check callback routines. In order to write this data, the drivers would have to first call KeRegisterBugCheckReasonCallback() to register the routines that would execute when the system bug checks. This is currently not very common due to the limitations imposed by the high IRQL at which bug check callbacks run. Allowing the system to determine the size is a good idea, especially when disk space is not of huge concern. Also, the dedicated dump file size will be adjusted automatically at boot if additional RAM is installed or removed later. This includes artificial memory reduction implemented via the BCDEdit option, truncatememory. This eliminates the need to manually resize your page file to support proper collection of a memory dump.
Manual size specified via the registry:
The following registry value will allow you to manually set the dedicated dump file size in megabytes:
Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl
Name: DumpFileSize
Type: REG_DWORD
Value: The dump file size in megabytes
One good reason one might have to set this value manually is in the case of a very large memory system from which only a kernel memory dump is desired. In this case, a dedicated dump file the size of RAM+256 MB is not required. Generally, even on 64-bit systems, kernel memory dumps are no larger than a few gigabytes, although they have the potential to be much larger. In nearly all cases reserving one third the size of RAM will be more than sufficient to capture kernel memory. If you have plenty of room on the drive and want to play it safe, you can simply allow the system to determine the size for you by setting the DumpFileSize value to zero, or by not creating the value at all.
Although you may set the DumpFileSize to a value larger than needed, or the system chooses a size larger than the type of dump selected, the resultant file size after a bug check will only be as large as the data that is stored in it. This is most commonly the size of physical RAM + room for the dump header information. If you choose to set the DumpFileSize value manually, then you should also set the IgnorePagefileSizevalue under the CrashControl key to 1. This will help ensure a dump file is created.
What about the final dump file?
After a bug check, the data will be written to the dedicated dump file on disk. However, the final memory dump location will be based on the following registry value:
Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl
Name: DumpFile
Type: REG_EXPAND_SZ
Value: The target dump file name together with the full path, such as D:\memory.dmp
The system will extract the dump data from the dedicated dump file and save the resultant file to the location and file name specified for the DumpFile value. The default for this value is %SYSTEMROOT%\MEMORY.DMP. Since we are using the dedicated dump file to overcome space limitations of the system drive, we will likely want to also set the DumpFile value to point to an alternate location than the default.
If you set this value to point to the same volume as the dedicated dump file, it will save WERFAULT.EXE the step of performing an additional copy of the temporary dump file after reboot. Instead the file will simply be renamed on the target volume. If there is not enough room for both the dedicated dump file and the memory dump after the bug check, then the dedicated dump file will not be recreated, and only the memory dump will remain. If this happens and the system bug checks again, only the original dump will remain because there will be no dedicated dump to write the second bug check to until space is freed up on the drive and the system is rebooted.
DedicatedDumpFile Usage Example:
The following example will set the dedicated dump file and resultant dump to be stored on the root if drive D:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl]
"DumpFile"=hex(2):44,00,3a,00,5c,00,4d,00,45,00,4d,00,4f,00,52,00,59,00,2e,00,\
44,00,4d,00,50,00,00,00
"DedicatedDumpFile"="D:\\DedicatedDump.sys"
(Note: The lines above can be saved as a .REG file and imported into the registry)
The screenshot below demonstrates a system configured to capture a complete 4 GB memory dump to a manually sized dedicated dump file, and will store the final MEMORY.DMP on the D: drive.
Important information:
949052 - Kernel memory dump files may not be generated on Windows Server 2008-based and Windows Vista SP1 or later based computers when physical memory is larger than the size of the page file
957517 - A dedicated complete memory dump file may not be successfully generated if the volume that stores the dedicated dump file has insufficient free space
950858 - Dedicated dump files are unexpectedly truncated to 4 GB on a computer that is running Windows Server 2008 or Windows Vista and that has more than 4 GB of physical memory
Comments
Anonymous
April 07, 2010
Out of curiosity, can you use something other than the ".sys" extension on "DedicatedDump.sys"? (I would guess yes, but just double-checking.) I can see that it is named with an extension similiar to pagefile.sys, but in this case "DedicatedDump.dmp" seems more intuitive to me.Anonymous
April 20, 2010
Yes, you can use something other than ".sys", but since this not actually going to used as a .DMP file directly when the system bugchecks, naming it with a .DMP extension may become confusing for someone trying to copy the dump file after reboot (since this will not be it.) Using ".sys" makes it easy to determine that it's not the final location for the dump, but you can really give it any name you choose. I have mine named "dedicated.Ddmp"Anonymous
May 01, 2012
how do I remove the dedicated dump file if I don't need it after setting it up? [Remove the registry key, reboot, delete the file.]Anonymous
January 16, 2013
- Do I need to set a page file when using the Dedicated Dump File approach ?
- If so, can I set the page file to a non-system drive if I don't have enough free space for the page file ?
- How much disk space is required for the page file size in order to generate a complete memory dump ? [A dedicated dump file is used as an alternative to having a large pagefile on the system partition.]
Anonymous
October 12, 2014
Are the issues in the linked KB articles fixed in Windows versions after Vista/Server 2008? The last updates on those pages were in 2011. [Yes.]Anonymous
April 12, 2015
The Screenshot incorrectly states, "a system configured to capture a complete 4 GB memory dump to a manually sized dedicated dump file..." DumpFileSize is missing within the screenshot. If configured to capture a complete 4 GB memory dump "manually", then a new DWORD Reg key named, "DumpFileSize" would need to be added with the "Value" set to 4000 (decimal) or 00000FA0 (Hex) Manual size specified via the registry: The following registry value will allow you to manually set the dedicated dump file size in megabytes: Location: HKEY_LOCAL_MACHINESystemCurrentControlSetControlCrashControl Name: DumpFileSize Type: REG_DWORD Value: The dump file size in megabytes [Good catch.]Anonymous
October 19, 2015
@RJR Well 4GB would be 4096MB or 0x1000 in hex. And don't forget to add those extra 256MB or 0x100 giving it a total of 0x1100 or 4352MB in size. Likewyse, for other memory sizes.