Where to find a memory dump. What is a memory dump? Simplifying Commands with a Batch File
A memory dump file is saved when STOP errors (or Blue Screens of Death, BSOD) occur. Let's see how to configure saving a memory dump in Windows 7.
Right-click the icon Computer select in the context menu Properties.
In the left column select Advanced System Settings (Advanced system settings).
In the window System Properties select a tab Additionally (Advanced), in section Startup and Recovery press Options(Settings).
In the window Startup and Recovery) we configure the dump file location and name, as well as other parameters related to booting and system recovery.
Enter the path to the file in the text field Dump file.
%SystemRoot% is an environment variable that is replaced by the system with the full path to Windows folder, which contains system files.
Click OK to save settings (if changes have been made).
Along the way, you can uncheck the checkbox Execute automatic reboot , if you don’t want the computer to automatically restart, but give you the opportunity to record information about the error that led to the blue screen. See the article for more details.
By and large, you, as a user, should not be interested in a memory dump. This is just information about a system failure, which ideally should be sent to Microsoft developers to find and fix critical errors. If you do not plan to engage in such charity, then you can disable the dump.
Disabling memory dump will not affect system performance in any way. When you use your computer, the system does not access the dump, whether it is turned on or not. Recording occurs only when Windows is “brought” to BSOD ( blue screen). It lasts a couple of seconds at most.
Types of dump
For general development, let's get acquainted with the types of dump. There are three of them: small dump, core dump and large. A small dump stores the most important information about the problem. Developers literally have to piece it together bit by bit. For a small dump you need to allocate 2 MB virtual memory(swap file).
Core dump– the most common type of dump. This option is usually the default. It records all the memory that is allocated to the core - the state of working drivers and data on the hardware-dependent level. For it you need to allocate about 30% of the total amount of RAM. For example, if you have 2 GB DDR, then allocate about 700 MB for the swap file.
A full dump records the entire contents of RAM. Accordingly, for it to work, you will have to allocate the same volume to the paging file as RAM. We need a full dump for hibernation mode, when all data from RAM is loaded onto the hard drive.
In Windows 7, the dump parameters are hidden quite deeply. Enter in the search bar in the menu " Start" word " system", For example.
Select result " System" A window will open. There is a list of options at the top right, select the last one - “ Advanced System Settings».
Good afternoon, dear colleagues and readers of the blog site. Today I want to tell you how to analyze a Windows 10 Redstone memory dump. This is done in most cases when you get a blue screen of death with an error, after which your computer reboots. AND this analysis helps to understand the cause of the failure.
Setting up a Windows 10 memory dump
So, what is a memory dump in the Windows 10 Redstone operating system. I described to you above, very common reason in which a system memory dump appears and these are blue screens of death. The reasons for their appearance are very extensive:
- Application incompatibility
- Driver incompatibility
- New Windows updates
- Devices are not compatible
This is just a small generalized list, since there are a whole lot of error codes from blue screens, I will give the most recent ones.
Our task is to be able to find these files for diagnostics and be able to interpret them to obtain information about the problem.
Where is a Windows 10 crash dump configured?
First, let's figure out where the setting is made, which is responsible for the Windows 10 crash memory dump. Right-click on the Windows 10 start button and from context menu select System.
In the System window that opens, you are in the left top corner select Advanced System Settings.
This is where the Windows 10 memory dump is configured. Click on the Settings item in Boot and Recovery.
From the settings of the Windows 10 memory dump, I would like to note the following:
- Recording an event in syslog> here information about the blue screen will be added to the logs operating system.
- Perform an automatic reboot > to continue working after an error
- Recording debugging information > allows you to select the type of dump file, more on that below.
- Replace existing file dump, a useful checkbox, since these dumps can weigh tens of gigabytes, which is very critical for small SSD drives.
Types of memory dumps
Let's look at the differences between the options for recording debugging information
- Small Memory Dump 256 KB: Small memory dump files contain the following information:
– message about a fatal error, its parameters and other data;
– list of loaded drivers;
– processor context ( PRCB) on which the failure occurred;
EPROCESS) for the process that caused the error;
– process information and kernel context ( ETHREAD) for the thread that caused the error;
– Kernel mode call stack for the thread that caused the error.
It is used when you have very little disk space on your local disk. Through this we sacrifice useful information, which may not be enough to diagnose a blue screen.
The mini dump is stored in the path C:\Windows\Minidump
- Kernel memory dump > records only kernel memory. Depending on volume physical memory The PC in this case requires from 50 to 800 for the paging file MB or one third of the computer's physical memory on boot volume.
- Full memory dump > well, everything is clear from the name. It writes absolutely everything, this is the maximum information about the blue screen, it gives a one hundred percent diagnosis of the problem.
Located at C:\Windows\Memory.dmp
- Active memory dump > the active memory of the host machine gets here, this function is more for server platforms, since they can be used for virtualization, and so that information about virtual machines does not get into the dump, this option was invented.
To fix blue screen of death it is necessary to identify the cause of its occurrence. To do this, you need to analyze the crash memory dump file. A crash dump can be analyzed in various ways. This is exactly what we will talk about in this article.
In a previous article on the site, we already wrote about the reasons that most often lead to a blue screen of death. They also showed how to correctly configure the creation of crash memory dumps and told where this one is stored. dump file. We briefly touched upon the fact that using the stop code and information from the dump file, it is possible through analysis to more accurately determine the reason that led to BSOD.
It remains to find out how and with what help you can analyze the information from the dump file. Let's consider several methods, including both an analysis tool from the Windows developers as well as third-party tools.
Analysis of a dump file using Microsoft Kernel Debugger.
Microsoft Kernel Debugger - special utility for analyzing crash dumps. You can download the utility itself, as well as the components necessary for its operation, from the website Microsoft- Debugging tools. Package version Debugging Tools for Windows
must match the bitness of the operating system. I wrote in detail about where and how to download this utility.
Along with the debugger itself, you also need to download a set of debugging symbols - Debugging Symbols. The character set also differs for each version of Windows, including bit depth. Thus, for 32-bit Windows 7 you need to download the symbol pack Windows 7 x32, and for 64-bit Windows 7 the character set Windows 7 x64. In the same way you need to choose a character set for other Windows versions(Windows 10, XP, etc.). The required set of symbols can also be downloaded from the debugger itself, but more on that below.
After installing the utility and a set of debugging symbols, you can launch the debugger itself. After launching, you need to specify the path to the debugging symbols in its settings. For this:
Click on the File ⇒ Symbol File Path... button
Next, click the Browse button and specify the folder where you saved the character set.
Download the most new version characters can be done using the utility itself. To do this, in the File ⇒ Symbol File Path... field, enter:
SRV*C:\symbols*http://msdl.microsoft.com/download/symbols 
Next, click on File ⇒ Save workspace and then click on OK.
Thus, the utility will request information about debugging symbols via the Internet directly from the Microsoft server.
To start the analysis, click on File > Open Crash Dump... and specify the required memory dump file (small memory dump).
The system will analyze the dump and display the results possible reason errors. 
By clicking on the hyperlink !analyse-v More advanced information will open by error.
You can complete debugging using the menu item Debug > Stop Debugging.
Analyzing a dump file with BlueScreenView
BlueScreenView This free utility to analyze a small crash dump file. This utility has Russian language support. The main advantage of this program is that you do not need to download debugging symbols for it to work. This makes this utility completely autonomous and independent. Another advantage of this program is the presence of a portable version, that is, a version that does not need to be installed on the system. The author of the program is Nier Sofer. You can download from author's official website. The portable version of the program can be downloaded from the link at official page, in the title of which it is indicated in brackets in Zip file.
When downloading, it is important to consider the bitness of your OS.
Scrolling just below you can download the Russification file - BlueScreenView_lng.ini, which you just need to drop into the folder with the program itself. I have prepared a program for downloading with the language already configured. Here are the direct links:
And now directly about the analysis procedure.
How to analyze a dump file with BlueScreenView?
After launch, the program immediately scans the standard dump file storage directory - %SystemRoot%\Minidump. The directory can be changed in the additional program parameters. The program window interface can be divided into 3 areas:
- Top menu button area
- Middle area with a list of dump files
- Bottom area with driver list
The analysis data is displayed in tabular form. I will list the most important columns in the middle area of the program’s interface window (the name in parentheses is from the English version):
- Error text (Bug Check String). A description of the error according to MicroSoft classification is displayed here. In our example, this is DRIVER_IRQL_NOT_LESS_OR_EQUAL.
- Bug Check Code. The error STOP code is displayed - 0x000000d1
- Caused By Driver. Displays the name of the driver or module that most likely caused the error. Please note that this is 100% the culprit of the error, but only a probable one. In our example this is E1G6032E.sys
- Caused By Address. Displays the driver and immediately after the address of the instructions that caused the failure. We have it E1G6032E.sys+9ef530/li>
- Crash Address. The address where the error occurred. In our case ntoskrnl.exe+1509a0 .
Now I will list the most important columns from the lower area:
- File name. Specify the name of the driver or module
- Address In Stack. Prints the driver memory address from the memory stack.
- File Description.
- File Version. The driver file version is displayed.
For analysis we highlight required file dump in the middle area of the utility window. When selected, the lower area is immediately filled with data. Let's look in the table at the data from the main columns that I gave above. In the lower area of the window, likely problematic drivers or modules are highlighted in red. Rarely, there are cases when the driver specified by the program in the middle area of the window is not the source of the BSOD error. In such cases, among the problematic drivers highlighted in red below, there is probably a true source of the blue screen of death. In my case, these are: E1G6032E.sys and ntoskrnl.exe. By the way, both are quite common causes of BSOD.
If the error sources found by the program do not tell you anything, then you can simply enter the name of the problematic drivers in a search engine and there you will probably find how to overcome them.
To more accurately identify problematic drivers and modules, you can use several analysis methods. Fortunately, in this article we examined the two most popular ones. Follow the publications and there will be another article about dump analysis in the future.
When a critical failure occurs, the Windows operating system crashes and displays a Blue Screen of Death (BSOD). Content random access memory and all information about the error that occurs is written to the swap file. Next time booting Windows a crash dump is created with debugging information based on the saved data. A critical error entry is created in the system event log.
Attention! A crash dump is not created if the disk subsystem fails or critical error arose during the initial stage of Windows boot.
Types of Windows Crash Dumps
Using the example of a current operating room Windows systems 10 (Windows Server 2016) consider the main types of memory dumps that the system can create:
- Mini memory dump(256 KB). This file type contains a minimal amount of information. It only contains the BSOD error message, information about the drivers, the processes that were active at the time of the crash, and which process or kernel thread caused the crash.
- Kernel memory dump. Typically small in size—one third of the physical memory size. A kernel memory dump is more detailed than a mini dump. It contains information about drivers and kernel-mode programs, includes memory allocated to the Windows kernel and the hardware abstraction layer (HAL), and memory allocated to drivers and other kernel-mode programs.
- Complete memory dump. Largest in size and requires memory equal to your system's RAM plus 1MB, required Windows to create this file.
- Automatic memory dump. Corresponds to a kernel memory dump in terms of information. The only difference is how much space it uses to create the dump file. This file type did not exist in Windows 7. It was added in Windows 8.
- Active memory dump. This type eliminates elements that cannot determine the cause of a system failure. This was added to Windows 10 and is especially useful if you use virtual machine, or if your system is a Hyper-V host.
How to enable memory dumping in Windows?
Using Win+Pause, open the system settings window, select " Advanced System Settings"(Advanced system settings). In the " Additionally" (Advanced), section "" (Startup and Recovery) click the button " Options"(Settings). In the window that opens, configure actions to take when the system fails. Check the " Log events to system log" (Write an event to the system log), select the type of dump that should be created when the system crashes. If in the checkbox " Replace existing dump file"(Overwrite any existing file) check the box, the file will be overwritten every time there is a failure. It’s better to uncheck this box, then you will have more information for analysis. Also disable Automatically restart.
In most cases, a small memory dump will be enough to analyze the cause of the BSOD.
Now, when a BSOD occurs, you can analyze the dump file and find the cause of the failure. The mini dump is saved in the %systemroot%\minidump folder by default. To analyze the dump file, I recommend using the program WinDBG(Microsoft Kernel Debugger).
Installing WinDBG on Windows
Utility WinDBG included in " Windows 10 SDK"(Windows 10 SDK). .
The file is called winsdksetup.exe, size 1.3 MB.
Run the installation and choose what exactly you want to do - install the package on this computer or download it for installation on other computers. Let's install the package on the local computer.
You can install the entire package, but to install only the debugging tool, select Debugging Tools for Windows.
After installation, WinDBG shortcuts can be found in the start menu.
Setting up association of .dmp files with WinDBG
To open dump files with a simple click, map the .dmp extension to the WinDBG utility.
- Open command line as administrator and run the commands for a 64-bit system: cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
windbg.exe –IA
for 32-bit system:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
windbg.exe –IA - As a result, the file types: .DMP, .HDMP, .MDMP, .KDMP, .WEW will be mapped to WinDBG.
Setting up a debugging symbol server in WinDBG
Debugging symbols (debug symbols or symbol files) are blocks of data generated during program compilation together with executable file. Such data blocks contain information about variable names, called functions, libraries, etc. This data is not needed when executing the program, but is useful when debugging it. Microsoft components are compiled with symbols distributed through the Microsoft Symbol Server.
Configure WinDBG to Microsoft use Symbol Server:
- Open WinDBG;
- Go to menu File –> Symbol File Path;
- Write a line containing the URL for downloading debugging symbols from the Microsoft website and the folder for saving the cache: SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols In the example, the cache is downloaded to the E:\Sym_WinDBG folder, you can indicate any.
- Don't forget to save changes to the menu File–>Save WorkSpace;
WinDBG will search for symbols in the local folder and, if it does not find the necessary symbols in it, it will automatically download the symbols from the specified site. If you want to add your own symbols folder, you can do it like this:
SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols;c:\Symbols
If you do not have an Internet connection, first download the symbol package from the Windows Symbol Packages resource.
Analysis of a crash dump in WinDBG
The WinDBG debugger opens the dump file and downloads the necessary symbols for debugging from a local folder or from the Internet. You cannot use WinDBG during this process. At the bottom of the window (in the debugger command line) the message appears Debugee not connected.
Commands are entered into the command line located at the bottom of the window.
The most important thing you need to pay attention to is the error code, which is always indicated in hexadecimal value and looks like 0xXXXXXXXX(indicated in one of the options - STOP: , 07/02/2019 0008F, 0x8F). In our example, the error code is 0x139.
The debugger offers to run the command!analyze -v, just hover your mouse over the link and click. What is this command for?
- It performs preliminary memory dump analysis and provides detailed information to start analysis.
- This command will display the STOP code and symbolic name of the error.
- It shows the stack of command calls that led to the crash.
- In addition, IP address, process and register faults are displayed here.
- The team can provide ready-made recommendations to solve the problem.
The main points that you should pay attention to when analyzing after executing the command!analyze –v (listing incomplete).
1: kd> !analyze -v
* *
* Bugcheck Analysis *
* *
*****************************************************************************
Symbolic name of STOP error (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)
Description of the error (A kernel component has corrupted a critical data structure. This corruption could potentially allow an attacker to gain control of this machine):
A kernel component has corrupted a critical data structure. The corruption could potentially allow a malicious user to gain control of this machine.
Error arguments:
Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: ffffd0003a20d5d0, Address of the trap frame for the exception that caused the bugcheck
Arg3: ffffd0003a20d528, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved
Debugging Details:
------------------
The counter shows how many times the system crashed with a similar error:
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY
STOP error code in shortened format:
BUGCHECK_STR: 0x139
The process during which the failure occurred (not necessarily the cause of the error, just at the time of the failure this process was running in memory):
PROCESS_NAME: sqlservr.exe
Error Code Description: The system has detected a stack buffer overflow in this application, which could allow an attacker to gain control of this application.
ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
Last call on the stack:
LAST_CONTROL_TRANSFER: from fffff8040117d6a9 to fffff8040116b0a0
Call stack at the time of failure:
STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9: 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d528: nt!KeBugCheckEx
ffffd000`3a20d2b0 fffff804`0117da50: ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2: nt!KiBugCheckDispatch+0x69
ffffd000`3a20d3f0 fffff804`0117c150: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt!KiFastFailDispatch+0xd 0
ffffd000`3a20d5d0 fffff804`01199482: ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9: nt!KiRaiseSecurityCheckFailure+0x3d0
ffffd000`3a20d760 fffff804`014a455d: 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951: nt! ?? ::FNODOBFM::`string"+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac: 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c600: nt!IopSynchronousServiceTail+0x379
ffffd000`3a20d990 fffff804`0117d313: ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380: nt!NtWriteFile+0x694
ffffd000`3a20da90 00007ffb`475307da: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt!KiSystemServiceCopyEnd+0 x13
000000ee`f25ed2b8 00000000`00000000: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: 0x00007ffb`475 307da
The code section where the error occurred:
FOLLOWUP_IP:
nt!KiFastFailDispatch+d0
fffff804`0117da50 c644242000 mov byte ptr ,0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiFastFailDispatch+d0
FOLLOWUP_NAME: MachineOwner
The name of the module in the kernel object table. If the analyzer was able to detect a problematic driver, the name is displayed in the MODULE_NAME and IMAGE_NAME fields:
MODULE_NAME:nt
IMAGE_NAME: ntkrnlmp.exe
1: kd> lmvm nt
Browse full module list
Loaded symbol image file: ntkrnlmp.exe
Mapped memory image file: C:\ProgramData\dbg\sym\ntoskrnl.exe\5A9A2147787000\ntoskrnl.exe
Image path: ntkrnlmp.exe
Image name: ntkrnlmp.exe
InternalName: ntkrnlmp.exe
OriginalFilename: ntkrnlmp.exe
ProductVersion: 6.3.9600.18946
FileVersion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)
In the example given, the analysis pointed to the kernel file ntkrnlmp.exe. When memory dump analysis points to a system driver (such as win32k.sys) or a kernel file (as in our example ntkrnlmp.exe), it is most likely this file is not the cause of the problem. Very often it turns out that the problem lies in the device driver, BIOS settings or equipment malfunction.
If you see that the BSOD was caused by a third-party driver, its name will be indicated in the MODULE_NAME and IMAGE_NAME values.
For example:
Image path: \SystemRoot\system32\drivers\cmudaxp.sys
Image name: cmudaxp.sys
Open the properties of the driver file and check its version. In most cases, the problem with drivers is solved by updating them.
