When a server becomes unstable for one reason or another, you may have a situation where a server blue screens or hard freezes and crashes. These types of situations can be harder to troubleshoot especially since you may not have any events recorded in event viewer or other traditional logging since the crash happens suddenly. What resources can we utilize to examine what led to the crash? Is there a type of logging that happens when a server crashes? By default, there is a special dump file that can be used to analyze the faulting application or module that caused a server crash. Let’s see how we can use this file and a tool from Microsoft to pinpoint the cause of a crash.
Memory Dump file
Under the startup and recovery options of Windows and write debugging information, we can configure how we want crash dump files to be created and how verbose we want them to be. There are five options that can be configured for the dump file type and location.
- Small memory dump (256 KB)
- Kernel Memory Dump
- Complete Memory Dump
- Automatic Memory Dump
- Active Memory Dump
Let’s look at each one of these options to see why we may configure them as the preferred write debugging information setting.
Small memory dump – This option is the smallest set of useful information that can be used to identify why the computer stopped unexpectedly. There are a few requirements for this option to be set.
Requirements
- The paging file must be at least 2MB and be located on the boot volume for Legacy OS’es
- With Vista and higher, the paging file can be located on a different volume with a special registry key called DedicatedDumpFile
Highlights
- This type of dump file is great to quickly get a small dump file that can be easily read to attempt to determine the cause of the unexpected stop
- It includes the stop message and parameters and other data, a list of loaded drivers, process information and kernel context, the kernel-mode call stack for the thread that stopped
- By default, the dump file is created in the %SystemRoot%\Minidump folder which is different than the other options
Kernel Memory Dump – This type of dump file only records kernel memory.
Requirements
- You must have a pagefile that is large enough to house your kernel memory which can be between 150MB and 2GB. With legacy OS’es, the pagefile needs to be located on the boot volume.
Highlights
- This may be the most useful of the dump files that can be configured
- It is much smaller than the complete memory dump but it includes the memory that is most likely to be the culprit in the unexpected stop and omits the memory dump that is unlikely to be the cause
- Dump file is created by default in %SystemRoot%\Minidump
Complete Memory Dump – This memory dump is just what it sounds like, a complete dump of system memory.
Requirements
- You must have a paging file configured that is large enough to hold all the physical memory (RAM) plus 1 MB
- This option is not available on 32-bit OS’es and that have 2 GB and higher of system memory configured
Highlights
- The complete memory dump contains all information contained in memory so every possible cause of the unexpected stop will be recorded
- Dump file is created by default in %SystemRoot%\Minidump
Automatic Memory Dump – The automatic memory dump contains the same information as the kernel memory dump (see above). The difference between the two is not the information contained in the dump file but rather the way the system paging file is configured. If the automatic memory dump is configured for the write debugging information setting, and the system paging file is set to system managed, then Windows can set the size of the paging file to less than the size of physical memory. With this setting te paging file is set so that a kernel memory dump can be written most of the time.
If the computer crashes and the paging file is not large enough to capture the kernel memory dump, then it will increase the paging file to at least the size of system memory.
Highlights
- The dump is recorded in %SystemRoot%\Memory.dmp
- The increased paging file stays in place for 4 weeks and is then decreased
- You can delete the following key to return it to normal sooner
- HKLM\SYSTEM\CurrentControlSet\Control\CrashControl\LastCrashTime
Viewing Crash Debug information
Once we have the preferred write debugging information setup according to the needs of our environment, how do we make use of this information? We need to download the Debugging tools for Windows found here: https://developer.microsoft.com/en-us/windows/hardware/download-windbg
The following tools install and demonstration was on Windows 10 Pro 1703. After downloading and running the installer, you are presented with two options, either to Install or Download the development kit. Basically, the install option will simply install the software. The download option will allow you to customize the installer to the components you want to install and have that installer readily available for other installations if needed. I will show the Download option below, which also essentially shows the install option as well.
The Download option will ask where you want to download the installer.
Options for Privacy.
The option we are interested in is the Debugging Tools for Windows. Next, we press the Download button to download our customized installer.
The download progress begins.
Now, we have our customized installer downloaded with the selected debugging tools.
We can now run the winsdksetup.exe file that is contained in the download.
Installation of the Debugging Tools
Installation of the tools now commences. A side note, the following are the screens that you will see if you simply choose to Install instead of download.
Note we see the scoped down features installation as we selected only the Debugging Tools for Windows during the Download operation.
Now that we have the Debugging tools loaded, we can run the WinDbg utility to open a crash dump file. Below I am opening a %SystemRoot%\Minidump file that was created with the Small Memory Dump configuration.
Note the below crash is most likely caused by mfefirek+28f5d which is a McAfee file. You can click the !analyze -v link to show more verbose information if you want as well.
Thoughts
The write debugging information options are valuable tools in being able to debug crash dump information that is contained in the memory dumps. By downloading the Windows Debugging tools for Windows 10, we can use the WinDbg utility to open up a Crash Dump file and diagnose the potential culprit of the unexpected system crash. Use these tools to your advantage in troubleshooting system instability as most likely you can use it to narrow down to the offending process that led to the system crash.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
