Recording debugging information for Windows 10, what to install. How to use a memory dump to determine the driver causing the BSOD. Setting up a debugging symbol server in WinDBG

Hello friends, today we will discuss an interesting topic that will help you in the future when blue screen death (BSoD).

Like me, many other users had to observe the appearance of a screen with a blue background on which something was written (white on blue). This phenomenon indicates a critical problem, as in software, for example, a driver conflict, or a physical malfunction of some computer component.

I recently got a blue screen issue in Windows 10 again, but I quickly got rid of it and will tell you about it soon.

So, most of the users are not aware that BSoD can be analyzed to later understand the critical error issues. For such Windows cases creates special files on the disk - we will analyze them.

There are three types of memory dump:

Full memory dump– this function allows you to completely save the contents random access memory. It is rarely used, because imagine that you have 32 GB of RAM, with a full dump, all this volume will be stored on disk.

Core dump– saves kernel mode information.

Small memory dump– saves a small amount of error information and loaded components that were present at the time the system malfunction occurred. We will use this type of dump because it will give us enough information about the BSoD.

The location of both the small and full dump is different, for example, the small dump is located in the following path: %systemroot%\minidump.

The full dump is here: %systemroot%.

To analyze memory dumps, there are various programs, but we'll use two. The first is Microsoft Kernel Debuggers, as the name suggests, a utility from Microsoft. You can download it from the official website. The second program is BlueScreenView, a free program, download from here.

Analyzing a Memory Dump Using Microsoft Kernel Debuggers

For different versions of systems you need to download a different type of utility. For example, for 64-bit operating system, you need a 64-bit program, for a 32-bit program - a 32-bit version.

That's not all, you need to download and install the package of debugging symbols needed for the program. It's called Debugging Symbols. Each version of this package is also downloaded under a specific OS, first find out what system you have, and then download. So that you don’t have to look for these symbols anywhere, here is the download link. The installation should preferably be done in this path: %systemroot%\symbols.

Now you can launch our debugger, the window of which will look like this:

Before analyzing the dumps, we will configure something in the utility. First, we need to tell the program where we installed the debugging symbols. To do this, click on the “File” button and select the “Symbol File Path” item, then specify the path to the symbols.

The program allows you to extract symbols directly from the web, so you don't even have to download them (sorry to those who have already downloaded them). They will be taken from a Microsoft server, so everything is secure. So, you need to open “File” again, then “Symbol File Path” and enter the following command:

SRV*%systemroot%\symbols*http://msdl.microsoft.com/download/symbols

Thus, we indicated to the program that the symbols should be taken from the network. Once we have done this, click “File” and select “Save Workspace”, then click OK.

That's all. We have configured the program in the right way, now we begin to analyze memory dumps. In the program, press the button "File", Then "Open Crash Dump" and select the desired file.

Kernel Debuggers will begin analyzing the file and then output a result about the cause of the error.

In the window that appears, you can enter commands. If we enter !analyze –v, then we will get more information.

That's all with this program. To stop the debugger, select "Debug" and the "Stop Debugging" item.

Analyzing a memory dump using BlueScreenView

The BlueScreenView program is also suitable for analyzing various errors and BSoDs; it has a simple interface, so there should be no problems with mastering it.

Download the program from the link above and install. After launching the utility, you need to configure it. Go to the parameters: “Settings” – “ Extra options" A small window will open with a couple of items. In the first paragraph, you need to indicate the location of the memory dumps. They are usually located in the path C:\WINDOWS\Minidump. Then just click the "Default" button.

What can you see in the program? We have menu items, a part of the window with the names of the dump files, and the second part of the window - the contents of the memory dumps.

As I said at the beginning of the article, dumps can store drivers, the screenshot of the “screen of death” itself, and other useful information that may be useful to us.

So, in the first part of the window, where the dump files are, select the memory dump we need. In the next part of the window we look at the contents. Drivers located in the memory stack are marked in reddish color. They are precisely the cause of the blue screen of death.

On the Internet you can find everything about the error code and driver that may be to blame for BSoD. To do this, click “File”, and then “Find error code + Driver in Google”.

You can display only the drivers that were present at the time the error occurred. To do this, click “Settings” – “Bottom window mode” – “Only drivers found in the crash stack”. Or press the F7 key.

To show the BSoD screenshot, press F8.

To show all drivers and files, press F6.

Well, that's all. Now you know how to find out about the Blue Screen of Death problem, and if something happens, find a solution on the Internet or on this site. You can offer your error codes, and I will try to write for each article to solve the problem.

Also don't forget to ask questions in the comments.

I will continue to talk about the blue screen of death, which I started in.

So, if the computer suddenly reboots or freezes, and the blue screen of death does not appear or appears for a split second, then information about the causes of the failure can still be restored.

The fact is that the operating system at the time of failure saves the contents of RAM in the so-called dump file(has extension .dmp). In the future, the dump file can be analyzed and get the same information as on the blue screen and even a little more.

But the creation of dumps can be disabled in the system, so you should make sure that, firstly, the system creates dumps when it crashes, and, secondly, you should know the location on the disk where they are saved.

To do this you need to go to the section System.

In Windows 10 this can be done through search, and in previous versions operating system through the Control Panel.

Here, recording events in the system log should be enabled, but to prevent the computer from automatically rebooting and showing us the contents of the blue screen of death, you need to cancel the automatic reboot if it was enabled.

The path to the dumps is also displayed here - we see that the dump is saved in the %SystemRoot% folder - this is the designation of the Windows folder.

You can also select “small memory dump” here, which will be quite enough to search for error codes.

So, the system crashed into the blue screen of death, after which a memory dump was created.

For dump analysis there are special programs and one of the most popular is the BlueScreenView utility.

The program is very easy to use and does not require installation - download from the official website and unzip it. At the same time, from the official website you can download a file with which you can Russify the program. For this this file you will need to place it in the folder with the unzipped program.

If, after launching the program, the dumps are not displayed, although the system crashed into the blue screen of death, then you should go to the program settings and make sure that the path to the memory dumps is specified correctly, that is, it should be the same as in the system settings.

After this, you need to update the information in the program window and all dumps created in the system will be displayed. If there are several dumps, then we focus on the date of failure. Select the desired dump, and then it will appear detailed information on it.

Here the name of the error is displayed, its STOP code with parameters, and if the cause was the driver, then in the corresponding field we will find its name.

Also, at the bottom of the program window, files that could also cause the failure will be highlighted in pink. We'll have to deal with each of them in order. The algorithm here is similar to that discussed in the previous post - we look for a solution on the Internet, and use the file name or error code as a search key.

In this case, it is not necessary to manually enter data into the search engine. If you right-click on the dump line, then from context menu You can select an item that will allow you to find a description of this particular problem in Google.

You can choose to search Google by error code, by error code and driver name, or by error code and parameter.

Also, using this utility, you can quickly find the location of the problematic file on the disk.

Sometimes it happens that the file that caused the problem belongs to some program or game. By the location of the file on the disk, you can quickly determine which program or game it belongs to.

Well, it’s worth knowing that cleaners seem to delete memory dumps, so if you use such programs, then you should refrain from using them while identifying the cause of the blue screen of death.

And the last question that I will answer as part of this note is what to do if after the blue screen appears the computer no longer starts? That is, the computer freezes or is constantly overloaded, which means there is no way to analyze the memory dump.

The answer is logical and simple - you need to create bootable USB flash drive, with which you can “extract” the dump file from hard drive and analyze it on another computer. To do this, boot from a flash drive and on the computer’s hard drive in the folder Windows or in a subfolder minidump We find the dump file, which we copy to the flash drive. Then on another computer using the utility BlueScreenView We analyze the dump, as described in this note.

In Windows 8, Microsoft introduced a new memory dump - an automatic memory dump option. This setting is set by default in the operating system. Windows 10 introduced a new type of dump file - active memory dump. For those who don't know, in Windows 7 we have small dump, core dump and full core dump. You might be wondering why Microsoft decided to create this new parameter memory dump? According to Robert Simpkins, senior support engineer, an automatic memory dump can create support for the “system” page in the configuration file.
The paging file configuration management system is responsible for managing the size of the paging file - this avoids unnecessary headroom or paging file size. This option is introduced mainly for PCs that run on SSD drives, which tend to be smaller in size but have a huge amount of RAM.

Memory dump options

The main advantage of “Automatic memory dump” is that it will allow the subsystem session in the process manager to automatically reduce the page file to a size smaller than the size of RAM. For those who don't know, the subsystem manager session is responsible for system initialization, the startup environment for services and processes that are required for the user to log into the system. It basically sets the files page to virtual memory and starts the winlogon.exe process.

If you want to change your automatic memory dump settings, here's how to do it. Press Windows key + X and select - System. Next, click on the button “Advanced system settings - Advance System Settings”.

Click on the Advanced system settings button.

Here you can see a drop-down menu where it says “Advanced”.

Here you can select the option you want. Suggested options:

No memory dumps.
Small memory dump.
Kernel memory dump.
Complete memory dump.
Automatic memory dump. Added to Windows 8.
Active memory dump. Added to Windows 10.
The location of the memory dump file is in the %SystemRoot%\MEMORY.DMP file.

If you are using SSD drive, then it’s better to leave it on “Automatic memory dump”; but if you need a crash dump file, then it's better to set it to “small memory dump”, with it you can, if you want, send it to someone so they can take a look at it.

In some cases, you may need to increase the size of the page file larger than the RAM so that it can fit a full memory dump. In such cases, you need to create a registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

it's called "LastCrashTime".

This will automatically increase the size of the swap file. To reduce it later, you can simply remove this key.

In Windows 10 introduced new file dump active memory dump. It contains only the essentials and is therefore smaller in size.

I don't have a way to test it, but I created this key and monitored the page file size. I know that sooner or later I will get a critical error. Then I'll check it.

You can analyze the memory dump of Windows.dmp files using WhoCrashed. WhoCrashed Home is a free utility that provides drivers that have been installed into your computer with one click. In most cases, it can identify a faulty driver that is causing problems to your computer. This is a system analysis crash dump, memory dumps, and all the collected information is presented here in an accessible form.

Typically, the debugging toolkit will open an analysis crash dump. With this utility, you don't need any knowledge or debugging skills to find out which drivers are causing problems on your computer.

WhoCrashed relies on a debugging package (the windbg program) from Microsoft. If this package is not installed, WhoCrashed will download and automatically extract this package for you. Just run the program and click on the Analyze button. When you have WhoCrashed installed on your system and if it crashes or closes unexpectedly, the program will let you know if crash dumping is enabled on your computer and it will offer you suggestions on how to enable them.

This short note aims to show how you can configure the system in order to get an emergency Windows memory dump, that is, a dump that can be created if a critical failure occurs, characterized by the appearance of a blue screen of death (BSOD). What is a dump in general, why do we need it and what is it, what problems is it intended to solve and what information does it contain?

Memory dump - the contents of the working memory of a process, kernel or entire operating system, including, in addition to work areas, Additional information about the state of processor registers, the contents of the stack and other service structures.

Why might we need this content, i.e. Windows memory dump? Perhaps the most common use of a memory dump is to study the causes of a system failure (), which caused the operating system to completely stop. In addition to this, memory state can be used for other purposes. It is also important that a memory dump is literally the only way receive information about any failure! And taking (obtaining) a system memory dump is, in fact, the only accurate method of obtaining an instant fingerprint (copy) of the contents of the system’s physical memory.

The more accurately the contents of the dump reflect the state of memory at the time of the failure, the more detailed we will be able to analyze the emergency situation. Therefore, it is extremely important to obtain an up-to-date copy of the system’s physical memory at a strictly defined point in time immediately preceding the failure. And the only way to do this is to create a full crash dump. The reason is quite trivial - when a crash dump of the system memory occurs, either as a result of a failure or as a result of an artificially simulated situation, the system at this moment of receiving control of emergency functions (KeBugCheckEx) is in an absolutely unchanged (static) state, therefore, between the moment the failure occurs and the moment data is written to the media, nothing changes the contents of physical memory, and it is written to disk in its original state. Well, this is in theory, but occasionally in life, but there are situations where, due to faulty hardware components, the memory dump itself may be damaged, or the station may freeze while recording the dump.

In the vast majority of cases, from the moment the process of creating a crash memory dump begins until the end of writing the memory contents to disk, the information in memory remains unchanged.

Theoretically, the static (immutability) of the memory “fingerprint” is explained by the fact that when the KeBugCheckEx function is called, which displays information about the failure and starts the process of creating a memory dump, the system is already completely stopped and the contents of physical memory are written to blocks occupied on disk by the paging file, after which, during the subsequent loading of the operating system, it is reset to a file on the system media. Well, almost once I observed a situation where a faulty motherboard prevented me from saving a memory dump: a) freezing while the dump saving logic was running (the process did not reach 100%), b) damaging the memory dump file (the debugger complained about structures), c) writing memory.dmp dump files of zero length. Therefore, despite the fact that the system is already completely stopped at the time the memory dump is created, and only the emergency code is running, faulty hardware can make adjustments to any logic without exception at any stage of operation.
Traditionally, at the initial stage, disk blocks allocated to the pagefile are used to save a Windows memory dump. Then, after a blue screen and reboot, the data is moved to a separate file, and then the file is renamed using a pattern depending on the type of dump. However, starting from Windows versions Vista, this state of affairs can be changed; now the user is given the opportunity to save a selected dump without the participation of a swap file, placing information about the failure in a temporary file. This was done in order to eliminate configuration errors associated with incorrect settings of the size and position of the paging file, which often led to problems during the process of saving a memory dump.
Let's see what types of dumps the Windows operating system allows us to create:

• Process (application) memory dump;
• Kernel memory dump;
• Complete memory dump (dump of the available portion of the system's physical memory).

All crash dumps can be divided into two main categories:

• Crash dumps with information about the exception that occurred. Usually created in automatic mode, when an unhandled exception occurs in the application/kernel and, accordingly, the system (built-in) debugger can be called. In this case, information about the exception is recorded in a dump, which makes it easier to determine the type of exception and where it occurred during subsequent analysis.
• Crash dumps without exception information. Typically created manually by the user when it is necessary to simply create a snapshot of a process for subsequent analysis. This analysis does not imply determining the type of exception, since no exception occurred, but an analysis of a completely different kind, for example, studying the data structures of a process and so on.

Kernel memory dump configuration

You must be logged in under administrative account to perform the steps described in this section.

Let's jump straight into configuring the Windows crash dump settings. First, we need to go to the system properties window in one of the following ways:

1. Right-click on the "My Computer" icon - "Properties" - "Advanced system settings" - "Advanced".
2. "Start" button - "Control Panel" - "System" - "Advanced system settings" - "Advanced".
3. Keyboard shortcut "Windows" + "Pause" - "Advanced system settings" - "Advanced".
4. 
   control system.cpl,3
5. Execute in command line(cmd):
   SystemPropertiesAdvanced

The result of the described actions is to open the "System Properties" window and select the "Advanced" tab:

After that, in the “Boot and Recovery” section we click, select “Options” and thereby open a new window called “Download and Recovery”:

All crash dump parameters are grouped in a parameter block called "System Failure". In this block we can set the following parameters:

1. Write events to the system log.
2. Perform an automatic reboot.
3. Recording debugging information.
4. Dump file.
5. Replace an existing dump file.

As you can see, many of the parameters from the list are quite trivial and easy to understand. However, I would like to elaborate on the "Dump File" parameter. The parameter is presented as a drop-down list and has four possible values:

Small memory dump

A small memory dump (minidump) is a file that contains the smallest amount of information about the failure. The smallest of all possible memory dumps. Despite the obvious disadvantages, minidumps are often used as information about a failure to be transferred to third-party driver vendors for subsequent study.
Compound:

• Error message.
• Error value.
• Error parameters.
• The processor context (PRCB) on which the failure occurred.
• Process information and kernel context (EPROCESS) for the crashing process and all its threads.
• Process information and kernel context (ETHREAD) for the thread causing the crash.
• The kernel mode stack for the thread that caused the crash.
• List of loaded drivers.

Accommodation: %SystemRoot%\Minidump\MMDDYY-XXXXX-NN.dmp. Where MMDDYY is the month, day and year, respectively, NN is the serial number of the dump.
Volume: The size depends on the bitness of the operating system: only 128 kilobytes are required for a 32-bit and 256 kilobytes for a 64-bit OS in the paging file (or in the file specified in DedicatedDumpFile). Since we cannot set such a small size, we round it up to 1 megabyte.

Kernel memory dump

This type of dump contains a copy of all kernel memory at the time of the crash.
Compound:

• List of running processes.
• State of the current thread.
• Kernel-mode memory pages present in physical memory at the time of the crash: kernel-mode driver memory and kernel-mode program memory.
• Hardware-dependent level (HAL) memory.
• List of loaded drivers.

The kernel memory dump is missing unallocated memory pages and user mode pages. Agree, it is unlikely that user mode process pages will be of interest to us during a system failure (BugCheck), since system failure is usually initiated by kernel mode code.

Size: Varies depending on the size of the kernel address space allocated by the operating system and the number of kernel mode drivers. Typically, about a third of the physical memory is required in the swap file (or in the file specified in DedicatedDumpFile). May vary.

Complete memory dump

A full memory dump contains a copy of all physical memory (RAM) at the time of the crash. Accordingly, the entire contents of the system memory are included in the file. This is both an advantage and a major disadvantage, since its size can be significant on some servers with large amounts of RAM.
Compound:

• All pages of "visible" physical memory. This is almost the entire system memory, with the exception of areas used by the hardware: BIOS, PCI space, etc.
• Data from the processes that were running on the system at the time of the failure.
• Pages of physical memory that are not mapped to the virtual address space, but which can help in investigating the cause of the failure.

By default, a full memory dump does not include areas of physical memory used by the BIOS.
Location: %SystemRoot%\MEMORY.DMP . The previous dump is overwritten.
Volume: The paging file (or the file specified in DedicatedDumpFile) requires a volume equal to the size of physical memory + 257 megabytes (these 257 MB are divided into a certain header + driver data). In fact, in some OSes, the lower threshold of the paging file can be set exactly to the value of the physical memory size.

Automatic memory dump

Starting with Windows 8/Windows Server 2012, a new dump type has been introduced into the system called Automatic Memory Dump, which is set as the default type. In this case, the system itself decides which memory dump to record in the event of a particular failure. Moreover, the logic of choice depends on many criteria, including the frequency of the operating system “crash”.

After you change the Windows memory dump configuration, you may need to restart your computer.

Registry Settings

The registry section that defines the crash dump parameters:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

Options:

Parameter	Type	Description
AutoReboot	REG_DWORD	Enable/disable automatic reboot when BSOD occurs.
CrashDumpEnabled	REG_DWORD	The type of dump being created. 0 - do not create a memory dump; 1 - complete memory dump; 2 - kernel memory dump; 3 - small memory dump;
DumpFile	REG_EXPAND_SZ	Path and name of the kernel memory dump and full memory dump.
DumpFilters	REG_MULTI_SZ	Driver filter in the memory dump driver stack. Allows you to add new functionality at the stage of creating crash dumps. For example, encrypting the contents of the dump. Changing the value is not recommended.
LogEvent	REG_DWORD	Recording an event in the system log.
MinidumpDir	REG_EZPAND_SZ	Path and name of the small memory dump.
MinidumpsCount	REG_DWORD	Maximum number of small memory dumps. When exceeded, older versions begin to be overwritten.
Overwrite	REG_DWORD	Replace an existing dump file. Only for kernel memory dump and full memory dump.
IgnorePagefileSize	REG_DWORD	Ignores the standard page file as a place for temporary (intermediate) memory dump storage. Indicates that the memory dump should be written to a separate file. Used in conjunction with the DedicatedDumpFile option.
DedicatedDumpFile	REG_EZPAND_SZ	Path and name of a temporary alternative file for recording a memory dump. In the second pass the data will still be moved to DumpFile/MinidumpDir.

Manually creating a memory dump

Above we described the settings for automatically creating system crash dumps in the event of a critical error, that is, an unhandled exception in the kernel code. But in real life, in addition to the operating system crash, there are situations when it is necessary to obtain a system memory dump at a specific point in time. How to be in this case? There are methods for obtaining a snapshot of all physical memory, for example using the .dump command in the WinDbg/LiveKD debuggers. LiveKD is a program that allows you to run the Kd kernel debugger on a running system in local mode. The WinDbg debugger also has a similar feature. However, the on-the-fly dump method is not accurate because the dump generated in this case is "inconsistent" since it takes time to generate the dump, and in case of using the kernel mode debugger, the system continues to run and make changes to the memory pages.

All Windows systems, when a fatal error is detected, make a crash dump (snapshot) of the contents of RAM and save it on HDD. There are three types of memory dump:

Full memory dump – saves the entire contents of RAM. The image size is equal to the size of RAM + 1 MB (header). Very rarely used, as on systems with large amounts of memory the dump size will be too large.

Kernel memory dump – saves RAM information related to kernel mode only. User mode information is not saved because it does not contain information about the cause of the system crash. The size of the dump file depends on the size of the RAM and varies from 50 MB (for systems with 128 MB of RAM) to 800 MB (for systems with 8 GB of RAM).

Small memory dump (mini dump) - contains a fairly small amount of information: an error code with parameters, a list of drivers loaded into RAM at the time of the system crash, etc., but this information is enough to identify the faulty driver. Another advantage of this type of dump is the small file size.

System Setup

To identify the driver that caused it, it will be enough for us to use a small memory dump. In order for the system to save a mini dump during a crash, you must perform the following steps:

For Windows Xp	For Windows 7
My computer Properties Go to the tab Additionally; Options; In field Writing Debug Information choose Small memory dump (64 KB).	Right-click on the icon Computer from the context menu select Properties(or the Win+Pause key combination); In the left menu, click on the item Advanced System Settings; Go to the tab Additionally; In the Download and recovery field, you must click the button Options; In field Writing Debug Information choose Small memory dump (128 KB).

Having completed all the manipulations, after each BSoD a file with the extension .dmp will be saved in the C:\WINDOWS\Minidump folder. I advise you to read the material "". You can also check the box “ Replace existing dump file" In this case, each new crash dump will be written over the old one. I do not recommend enabling this option.

Analyzing a crash dump using BlueScreenView

So, after the Blue Screen of Death appeared, the system saved a new crash memory dump. To analyze the dump, I recommend using the BlueScreenView program. It can be downloaded for free. The program is quite convenient and has an intuitive interface. After installing it, the first thing you need to do is specify the location for storing memory dumps on the system. To do this, go to the menu item “ Options” and select “ AdvancedOptions" Select the radio button “ LoadfromthefollowingMini Dumpfolder” and specify the folder in which the dumps are stored. If the files are stored in the C:\WINDOWS\Minidump folder, you can click the “ Default" Click OK and get to the program interface.

The program consists of three main blocks:

1. Main menu block and control panel;
2. Crash dump list block;
3. Depending on the selected parameters, it may contain:

• a list of all drivers in RAM before the blue screen appears (by default);
• a list of drivers located in the RAM stack;
• BSoD screenshot;
• and other values ​​that we will not use.

In the memory dump list block (marked with number 2 in the figure), select the dump we are interested in and look at the list of drivers that were loaded into RAM (marked with number 3 in the figure). The drivers that were on the memory stack are colored pink. They are the cause of BSoD. Next, go to the Main Menu of the driver, determine which device or program they belong to. First of all, pay attention to system files, because system files are loaded in RAM in any case. It's easy to see that the faulty driver in the image is myfault.sys. I will say that this program was specifically launched to cause a Stop error. After identifying the faulty driver, you need to either update it or remove it from the system.

In order for the program to show a list of drivers located on the memory stack when a BSoD occurs, you need to go to the menu item “ Options“click on menu” LowerPaneMode” and select “ OnlyDriversFoundInStack” (or press the F7 key), and to show a screenshot of the error, select “ BlueScreeninXPStyle” (F8). To return to the list of all drivers, you must select “ AllDrivers” (F6).