Windows Server 2008: Windows Error Reporting

Starting with Windows Server 2008 and Windows Vista SP1, Windows Error Reporting (WER) can be configured to collect full user-mode dump files and store them locally after a user-mode application crashes.  By default, this feature is not enabled - an administrator needs to turn it on by modifying the registry values in HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps: […]

Starting with Windows Server 2008 and Windows Vista SP1, Windows Error Reporting (WER) can be configured to collect full user-mode dump files and store them locally after a user-mode application crashes.  By default, this feature is not enabled - an administrator needs to turn it on by modifying the registry values in HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps:

ValueDescriptionTypeDefault Value
DumpFolderPath to store the dump fileREG_EXPAND_SZ%LOCALAPPDATA%\CrashDumps
DumpCountMaximum number of dump files to store in the folderREG_DWORD10
DumpTypeType of dump to create (see the table below for the different dump types)REG_DWORD1
CustomDumpFlagsCustom dump options to be used.  This value is used when DumpType=0REG_DWORDMiniDumpWithDataSegs
MiniDumpWithUnloadedModules
MiniDumpWithProcessThreadData

As indicated above, you can get very granular with the type of dump file to create.  The table below shows the different dump types that you can specify for the DumpType DWORD value.  Each dump type represents 1 bit of the 32-bit DWORD value.  If you want to specify multiple dump types, you would need to set the corresponding bit in the DWORD value:

Value NameValueDescription
MiniDumpNormal0x00000000Include only the information necessary to capture stack traces for all existing threads in a process
MiniDumpWithDataSegs0x00000001Include the data sections from all loaded modules.  This results in the inclusion of global variables which can make the minidump significantly larger
MiniDumpWithFullMemory0x00000002Include all accessible memory in the process.  This can result in a very large file
MiniDumpWithHandleData0x00000004Include high-level information about the OS handles that are active when the minidump is created
MiniDumpFilterMemory0x00000008Stack and backing store memory written to the  minidump file should be filtered to remove all but the pointer values necessary to reconstruct a stack trace.  Typically this removes any private information
MiniDumpScanMemory0x00000010Stack and backing store memory is scanned for pointer references to modules in the module list
MiniDumpWithUnloadedModules0x00000020Include information from the list of modules that were recently unloaded
MiniDumpWithIndirectlyReferencedMemory0x00000040Include pages with data referenced by locals or other stack memory.  This option can increase the size of the minidump significantly
MiniDumpFilterModulePaths0x00000080Filter module paths for information such as user names or important directories.  This option may prevent the system from locating the image file and should be used only in specific situations
MiniDumpWithProcessThreadData0x00000100Include complete per-process and per-thread information from the operating system
MiniDumpWithPrivateReadWriteMemory0x00000200Scan the virtual address space for other types of memory to be included
MiniDumpWithoutOptionalData0x00000400Reduce the data that is dumped by eliminating the memory regions that are not essential to meet criteria specified for the dump.  This can avoid dumping memory that may contain private data that is private to the user.  However, it is not a guarantee that no private information will be present
MiniDumpWithFullMemoryInfo0x00000800Include memory region information
MiniDumpWithThreadInfo0x00001000Include thread state information
MiniDumpWithCodeSegs0x00002000Include all code and code-related sections from loaded modules to capture executable content

The values discussed above are global dump settings.  However, you can also configure these options on a per-process basis.  The per-process settings will override the global settings.  To create a specific dump configuration on a per-process basis, create a new subkey under the LocalDumps key using the application name as the key value.  So if you wanted to set up a dump configuration for Notepad, the key name would be Notepad.exe.  Add the desired values from the table(s) above to this key.  After an application crashes, the crash reporting is handled as it was in previous releases.  Prior to application termination, the system checks the registry settings to determine whether a local dump is to be collected.  After the dump collection has completed, the application terminates normally.  If the application supports recovery via the Restart Manager mechanism, then the dump is collected before the recovery callback is called.

One last point to note.  These dumps are configured and controlled independently of the rest of the WER infrastructure.  You can make use of the local dump collection process even if WER is disabled.  The local dumps are collected even if WER reporting is canceled at any point - and, the local dumps may be different than the dump that WER uploads to Microsoft.

Additional Resources:

Source:→ Microsoft

Microsoft, WS2008, Windows Server 2008,  Debugging, Architecture, Troubleshooting, Knowledgebase, WER, Windows Error Reporting