Kernel dump storage and clean up behavior in Windows 7
Lately we have been getting several questions about the kernel memory dump storage and clean up behavior in Windows 7, so I figured it will be a good idea to evangelize the design.
A kernel dump gets created every time a machine has a kernel fault. This dump gets stored in the %systemroot% folder as a memory.dmp file. Several options relating to collection of kernel dumps are configurable by going into
Control Panel > System and Security > System > Advanced system settings > Advanced tab > Startup and Recovery Settings.
The file size of a kernel dump is typically several hundred mega bytes. This brings us to the feedback we received regarding the Vista dump storage and clean up behavior. Customer feedback provided by home PC users indicates kernel dumps, although valuable in debugging crashes, takes up too much disk space (eating up to 200MB), which is not always appreciated by users. Thus, we have to make a judicious tradeoff between keeping a kernel dump on the machine so that the user could provide it to her support professional for debugging vs. freeing up valuable memory space on her disk. We realize that the scenarios are very different for corporate vs. home users.
IT departments usually manage corporate machines. IT departments know best about what they want to keep on their users’ machines. They typically store the memory.dmp files to debug problems and provide fixes or workarounds. Thus for the corporate scenario (or machines that are joined to a domain), Windows 7 will continue to store the memory.dmp file on disk, unless the IT department feels otherwise and overrides the default settings via group policy.
Home users are much less likely to contact product support for a system crash that occurs once in a blue moon. Thus, the value of the dump files is relatively low for them. If given a choice between having their disk space back vs. keeping the dump file on disk, they would rather have their disk space back. For these users, we do not want to keep the dump file if they are running low on disk. Needless to say they should be allowed to override this behavior and always keep the dump if they choose to.
Given the above thought process, we have come up with the following logic to save/delete the memory.dmp file on a machine:
Algorithm to decide whether to store/delete memory.dmp file generated after a system crash:
- First report the kernel fault to the Online Crash Analysis Service.
- Then, if machine has a registry setting AlwaysKeepMemoryDump set to 1, store the dump file on disk.
- Else, if machine is a Windows Server SKU, store the dump file on disk.
- Else, if the machine is joined to a domain (i.e. this is a corporate machine), store the dump file on disk.
- Else, if machine is not on a domain (i.e. this is a home user’s machine),
- If free disk space is >= 25GB, store the dump file on disk.
- Else (free disk space is < 25 GB), delete the dump file.
The exact location of the AlwaysKeepMemoryDump setting in the registry is:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl ! AlwaysKeepMemoryDump Type: REG_DWORD.
Note that any time the memory.dmp file is deleted, a system event is also logged to make sure the deletion is tracked. This can be useful for product support professional who want to confirm that the memory.dmp was deleted as per design, or is just mysteriously missing. Here is a screenshot of how this event (Event ID: 1018, Source: BugCheck) looks in the event viewer:
While we are clearing up the algorithm for kernel dumps, let us also provide you the new logic used to store kernel minidumps on disk:
Algorithm to store kernel minidumps in the %windir%\Minidump location:
WER will keep the last ‘x’ minidumps in the %windir%\Minidump location. ‘x’ can be configured by the following registry setting:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl ! MinidumpsCount Type: REG_DWORD, default value is 50
Hope this clears up any questions or concerns about dump storage and cleanup behavior in Windows 7. Note that the behavior in the Beta build does not match this. The RC and RTM builds will have this behavior though.