How to understand what the problem is when a blue screen (BSOD) appears or how to open a dump file

How often do you have to look at the screen? death of Windows(BSoD)? BSoD can occur in different cases: both while working with the system, and during the loading of the operating system. How to determine what causes BSoD and fix this problem? operating room Windows system is able to save a memory dump when an error occurs, so that the system administrator can analyze the dump data and find the cause of the BSoD.

There are two types of memory dumps - small (minidump) and full. Depending on the operating system settings, the system may save full or small dumps, or take no action when an error occurs.

A small dump is located along the path %systemroot%\minidump and has a name like Minixxxxxx-xx.dmp
The full dump is located along the path %systemroot% and has a name like Memory.dmp

To analyze the contents of memory dumps, you should use special utility- Microsoft Kernel Debugger.
You can get the program and components necessary for its operation directly from the Microsoft website - Debugging Tools

When choosing a debugger, you should take into account the version of the operating system on which you will have to analyze memory dumps. For a 32-bit OS, the 32-bit version of the debugger is required, and for a 64-bit OS, it is preferable to use the 64-bit version of the debugger.

In addition to the package itself Debugging Tools for Windows, you will also need a set of debugging symbols - Debugging Symbols. The set of debugging symbols is specific to each OS on which the BSoD was recorded. Therefore, you will have to download a set of symbols for each OS whose operation you will have to analyze. A 32-bit Windows XP will require the Windows XP 32-bit character set, and a 64-bit OS will require the Windows XP 64-bit character set. For other OS family Windows sets characters are selected according to the same principle. You can download debugging symbols from here. It is recommended to install them at %systemroot%\symbols

After installing the debugger and debug symbols, launch the debugger. The debugger window after launch looks like this.

Before analyzing the contents of the memory dump, you will need to do a little configuration of the debugger. Specifically, tell the program where to look for debugging symbols. To do this, select from the menu File > Symbol File Path... Click the Browse... button and indicate the folder in which we installed the debugging symbols for the memory dump in question.

You can request information about the required debugging symbols directly from the Internet, with public server Microsoft. This way you will have the most new version characters. You can do this as follows - in the File > Symbol File Path… menu, enter: SRV*%systemroot%\symbols*http://msdl.microsoft.com/download/symbols

After specifying the path to the debugging symbols, select File > Save workspace from the menu and confirm the action by clicking OK.

To begin analyzing the memory dump, select File > Open Crash Dump... from the menu and select the file required for examination.

The system will analyze the content, after which it will produce a result about the suspected cause of the error.

The !analyze -v command given to the debugger on the command line will output more detailed information.

You can stop debugging by selecting the menu item Debug > Stop Debugging

Thus, using the Debugging Tools for Windows package, you can always get a fairly complete picture of the causes of system errors.

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, both in the software, for example, a driver conflict, and in physical malfunction some computer component.

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

Do you want to watch movies online in good quality? Then follow the link.

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

There are three types of memory dump:

Full memory dump – this function allows you to completely save the contents of RAM. 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.

Kernel dump – saves information about the kernel mode.

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%.

There are various programs for analyzing memory dumps, but we will 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 a 64-bit operating system, a 64-bit program is needed, for a 32-bit operating system, a 32-bit version is needed.

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 it. We have configured the program in the right way, now we begin to analyze memory dumps. In the program, click the “File” button, 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 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” - “Advanced settings”. 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:WINDOWSMinidump. Then just click the "Default" button.

What can you see in the program? We have menu items, 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 in” Google code errors + Driver".

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.

http://computerinfo.ru/analiz-dampa-pamyati/http://computerinfo.ru/wp-content/uploads/2016/08/analiz-dampa-pamyati.jpghttp://computerinfo.ru/wp-content/ uploads/2016/08/analiz-dampa-pamyati-150×150.jpg2016-08-18T13:45:42+00:00EvilSin225BlueScreenView Problems,Microsoft Kernel Debuggers,dump analysis,memory dump analysis,windows 10 memory dump analysis,memory dump analysis windows 7, crash dump analysis, cause of BSoD Hello friends, today we will look at an interesting topic that will help you in the future when a blue screen of death (BSoD) appears. 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, ... EvilSin225 Andrey Terekhov [email protected] Computer technology

Crash dump

All Windows systems, when a fatal error is detected, make a crash dump (snapshot) of the contents of RAM and save it on hard drive. 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: error code with parameters, list of drivers loaded in RAM at the time of 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 the blue screen, we will only need 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:

Having completed all the manipulations, after each BSoD a file with the extension .dmp will be saved in the C:WINDOWSMinidump folder. I advise you to read the material “How to create a folder.” You can also check the “Replace existing dump file” checkbox. 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 dump. To analyze the dump, I recommend using the BlueScreenView program. It can be downloaded for free here. 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 “Options” menu item and select “Advanced Options”. Select the radio button “Load from the following Mini Dump folder” and specify the folder in which the dumps are stored. If the files are stored in the C:WINDOWSMinidump folder, you can click the “Default” button. Click OK and get to the program interface.

The program consists of three main blocks:

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). Pink color drivers that were on the memory stack are colored. 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 “Options” menu item, click on the “LowerPaneMode” menu 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).

I would be grateful if you use the buttons:

Windows crash dump analysis

In the event of a critical error, the system stops its operation, displays a blue screen of death (BSOD), error information and memory contents are stored in the paging file. When the system is subsequently loaded, a crash dump with debugging information is created based on the saved data. A critical error entry is created in the system event log.

If a critical error occurs early in the system boot process or a disk subsystem failure occurs as a result of the error, the crash dump will not be saved.

The crash dump can be analyzed using the BlueScreenView utility or system WinDbg debugger(Debugging Tools for windows).

Crash dump analysis using BlueScreenView utility

The simplest tool for analyzing crash dumps is the BlueScreenView utility from NirSoft.

Download the program from the developer's website.

BlueScreenView scans the minidump folder and displays information about the faults found.

For each failure, the date, error details, and the driver that is believed to have caused the failure are displayed.

A list of drivers loaded on the system is displayed at the bottom of the window. The modules that were being accessed at the time of the failure are highlighted in color; special attention should be paid to them; they may be the cause of the failure.

By double click additional information is displayed.

Analysis of a crash dump using the WinDbg debugger

Using WinDbg, you can extract more detailed information from a crash dump, including a transcript of the call stack.

Installing Debugging Tools for windows (WinDbg)

Microsoft only distributes WinDbg as part of the SDK; you can download the web installer from the Dev Center download page.

No SDK installation is required to analyze crash dumps. You can download Debugging Tools for windows (WinDbg) as a separate package here or here.

Download and install WinDbg for your version of windows. The version for Windows 7 also works in Windows XP and Windows Vista.

Windows 10 requires WinDbg version 10.0.10586.567. Download the Windows 10 Standalone SDK. The web installer will download. During installation, disable all components except the debugger.

After installation, we adjust the shortcut to launch WinDbg. In the shortcut properties, check the box to run as administrator. Also, as working folder, set: %SystemRoot%Minidump.

Setting up debugging symbols

Debug symbols contain symbolic names of functions from the source code. They are necessary to decipher and interpret the crash dump.

When you first start WinDbg, you need to specify the path to the debugging symbols; to do this, open the File menu, Symbol File Path, or use the Ctrl+S combination.

The next line enables loading of debugging symbols from the network, setting the local path for saving files and the address for downloading from the Internet:

srv*C:windowssymbols*http://msdl.microsoft.com/download/symbols

If the system is not connected to the Internet, the symbol installation package can be pre-downloaded from the package download page windows characters, Microsoft Development Center.

Crash dump analysis

Launch WinDbg.

In the menu, select File, Open Crash Dump, or press Ctrl+D.

Specify the path to the dump %SystemRoot%MEMORY.DMP or %SystemRoot%Minidumpfile.dmp.

To receive detailed information run the command:

The debugger will prompt you to perform it; just hover your mouse over the link and click.

As a result, we get the following output:

**************************************** ***************************** * * * Bugcheck Analysis * * * ************* **************************************** **************** Error type: KMODE_EXCEPTION_NOT_HANDLED (1e) Bug comment: This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address. Arguments: Error arguments: Arg1: 0000000000000000, The exception code that was not handled Arg2: 0000000000000000, The address that the exception occurred at Arg3: 0000000000000000, Parameter 0 of the exception Arg4: 0000000000000000, Parameter 1 of the exception Debugging Details: —— ———— EXCEPTION_CODE: (Win32) 0 (0) — . FAULTING_IP: +3332313336383065 00000000`00000000 ?? ??? EXCEPTION_PARAMETER1: 0000000000000000 EXCEPTION_PARAMETER2: 0000000000000000 ERROR_CODE: (NTSTATUS) 0 - STATUS_WAIT_0 BUGCHECK_STR: 0x1E_0 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: IVER_FAULT Process that caused the error: PROCESS_NAME: VirtualBox.exe CURRENT_IRQL: 2 EXCEPTION_RECORD: fffff80000ba24d8 - (.exr 0xfffff80000ba24d8) ExceptionAddress: fffff800034d8a70 (nt !DbgBreakPoint) ExceptionCode: 80000003 (Break instruction exception) ExceptionFlags: 00000000 NumberParameters: 1 Parameter: 0000000000000000 TRAP_FRAME: fffff80000ba2580 — (.trap 0xfffff80000ba2580) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0000000000142940 rbx=0000000000000000 rcx=fffffa80055be690 rdx=0000000000009018 rsi=000000000000000 rdi=0000000000000000 34d8a71 rsp=ffffff80000ba2718 rbp=fffff88006fa0000 r8=0000000000002274 r9=11d0851b22c6ac61 r10=ffffff80003464000 r11=ffffff80000ba27e0 r12=00000000 00000000 r13=0000000000000000 r14=0000000000000000 r15= 0000000000000000 iopl=0 nv up ei pl nz ac po nc nt!DbgBreakPoint+0x1: fffff800`034d8a71 c3 ret Resetting default scope LAST_CONTROL_TRANSFER: from fffff800034d85fe to fffff800034e0c10 STACK_TEXT: Stack call ov: fffff800`00ba15b8 fffff800`034d85fe: fffffa80`03c05530 00000000`ffffffff fffff800`00ba1d30 fffff800`0350c830: nt!KeBugCheck fffff800`00ba15c0 fffff800`0350c4fd: fffff800`036ea71c fffff800`03627c30 fffff800`03464000 fffff800`00ba 24d8: nt!KiKernelCalloutExceptionHandler+0xe fffff800`00ba15f0 fffff800`0350b2d5: fffff800`0362b028 fffff800`00ba1668 fffff800` 00ba24d8 fffff800`03464000: nt!RtlpExecuteHandlerForException+0xd fffff800`00ba1620 fffff800`0351c361: fffff800`00ba24d8 fffff800`00ba1d30 fffff800`00000000 00000 000`00142940: nt! RtlDispatchException+0x415 fffff800`00ba1d00 fffff800`034e02c2: fffff800`00ba24d8 fffffa80`07149010 fffff800`00ba2580 00000000`00000000: nt!KiDispatchException+0x135 f ffff800`00ba23a0 fffff800`034de0f4: 00000000`00000016 00000000`00000001 00000000`00000001 00000000`00000000: nt! KiExceptionDispatch+0xc2 fffff800`00ba2580 fffff800`034d8a71: fffff880`05861446 00000000`df029940 fffff880`02f45bec 00000000`deee7000: nt!KiBreakpointTrap+0xf4 fff ff800`00ba2718 fffff880`05861446: 00000000`df029940 fffff880`02f45bec 00000000`deee7000 fffff880`01229f06: nt! DbgBreakPoint+0x1 fffff800`00ba2720 00000000`df029940: fffff880`02f45bec 00000000`deee7000 fffff880`01229f06 fffffa80`05635af8: cmudaxp+0x25446 fffff800` 00ba2728 fffff880`02f45bec: 00000000`deee7000 fffff880`01229f06 fffffa80`05635af8 00000000`00000000: 0xdf029940 fffff800`00ba2730 00000000`deee7000: fffff880`01229f06 fffffa80`05635af8 00000000`00000000 00000000`00000003: VBoxDrv+0x6bec fffff800`00ba2738 fffff880`01229f0 6: fffffa80`05635af8 00000000`00000000 00000000`00000003 fffff880`05865913: 0xdeee7000 fffff800`00ba2740 00000000`00000000: 00000000` 00000001 00000000`00000006 00000000`00000001 fffff800`00ba2800: CLASSPNP!ClasspServiceIdleRequest+0x26 STACK_COMMAND: kb FOLLOWUP_IP: cmudaxp+25446 fffff880`05861446 ? ? ??? SYMBOL_STACK_INDEX: 8 SYMBOL_NAME: cmudaxp+25446 FOLLOWUP_NAME: MachineOwner Driver in which the error occurred: MODULE_NAME: cmudaxp IMAGE_NAME: cmudaxp.sys DEBUG_FLR_IMAGE_TIMESTAMP: 47906a45 FAILURE_BUCKET_ID: X64_0x1E_0 _cmudaxp+25446 BUCKET_ID: X64_0x1E_0_cmudaxp+25446 Followup: MachineOwner ———

Getting information about the problematic driver

If the driver with the error is found, the driver name will be displayed in the MODULE_NAME and IMAGE_NAME fields.

To get the file path and other information, click on the link to the module:

start end module name fffff880`0583c000 fffff880`059ef000 cmudaxp T (no symbols) Loaded symbol image file: cmudaxp.sys Image path: SystemRootsystem32driverscmudaxp.sys Image name: cmudaxp.sys Timestamp: Fri Jan 18 13:58:45 2008 (47906A45) CheckSum: 0013077F ImageSize: 001B3000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

If the full path to the driver is not specified, the default folder is %SystemRoot%system32drivers.

We find specified file, and study its properties.

We update the problematic driver.

Hardware causes of critical errors

The source of critical errors is often a malfunction in the disk subsystem or memory subsystem.

Diagnosing disk failures

In case of disk subsystem errors, the crash dump may not be saved.

To rule out problems with the disk, check the system event log for errors reading and writing to the disk.

We check the S.M.A.R.T parameters of the hard drive; you can get them, for example, using the SpeedFan program.

We pay special attention to the following parameters: “Current Pending Sector Count” and “Uncorrectable Sector Count”; non-zero values of these parameters indicate a disk failure.

A non-zero parameter value: “UltraDMA CRC Error Count” indicates a problem with the SATA cable.

Learn more about S.M.A.R.T. options. read in the Wikipedia article.

Diagnosis of memory faults

Memory problems can often cause a wide variety of glitches, including various blue screens, freezes, program crashes, registry corruption, corruption file system and data.

You can identify memory problems using the Memtest86+ utility.

Starting with Windows Vista, the system has its own memory test. To launch it, click “Start”, type “memory” in the search bar, select “Windows Memory Diagnostic Tool”.

Memory problems can in some cases be resolved by updating the BIOS.

Configuring crash dump saving options

To change the settings for saving a crash dump, click the “Start” button, right-click on “Computer”, context menu select “Properties”. In the “System” window on the left, select “Advanced system settings”, in the “Boot and Recovery” group, click the “Options” button.

Blue screen of death - what to do and how to identify the error

When a catastrophic error occurs, the Windows OS notifies its user about the incident with various sound and text signals. Thanks to them, you can find out more specifically about the error and fix it. However, in most cases, PC owners do not remember them or simply do not know what they mean. The system, on the contrary, takes an emergency snapshot of the error, better known as a dump, and stores it on the hard drive. It contains all the information about the breakdown.

Dump types

There are three types of dump:

In order for the system to save a small dump, it is necessary to set certain parameters.

For Windows 7 and Windows XP OS

Click “Start”, right-click “Computer” and select “Properties”.

Go to the “Advanced system settings” section.

The System Properties window appears. In the “Advanced” tab, in the “Boot and Recovery” section, click “Options”.

Select “Small memory dump” and click “Ok” to save the changes.

Analyzing a Small Dump Using Blue Screen View

The Blue Screen View program is downloaded as an archive here and does not require installation. In order to use it to determine the cause of the system failure, we perform the following steps.

We launch an application in the archive that is identical to the name of the program.

A software window will open. The interface is simple, however, in English. First of all, we indicate the location for saving the small dump. Click “Options” and select “Advanced Options”.

Place a checkmark next to the first section “Load from the following Mini Dump folder” and indicate the folder where the error snapshot is located. If a small dump was initially set in the system settings, the program itself will indicate the path to the snapshot C:WINDOWSMinidump. Click “Ok” to get to the program interface.

The block numbered 1 is a list of crash dumps that were made by the system. Under number 2 there are pictures and a list of drivers.

Drivers that cause system failure are indicated in pink in the list.

If you do not have a list of drivers, click “Options”. Go to “LowerPaneMode” and select “OnlyDriversFoundInStack”.

Having determined which driver failed, we fix the problem.

How to use a memory dump to determine the driver causing the BSOD

Cause of critical windows errors, accompanied by blue screens (BSOD), is often a driver - newly installed or damaged. Having determined which driver is causing the error, you can begin to fix the problem: update the driver, roll back to a more recent one. early version, reinstall or remove the application that installed the driver, etc. The driver name is not always displayed on the blue screen. However, there is a very simple way that allows you to identify the problematic driver in a couple of minutes using a memory dump.

Step 1 - Enabling Memory Dump Recording

First you need to make sure that dump recording is enabled. To do this, open the system properties by pressing the Win+Pause key combination, [in Vista, click the Advanced system settings link], go to the Advanced tab, and finally click the Startup and Recovery button.

Small memory dumps should be sufficient for our purposes.

Pay attention to the path to the folder where they will be saved if a critical error occurs.

Now you can zip the file into an archive, attach it to a post in the Troubleshooting critical windows errors forum and wait until someone tells you the name of the problematic driver :) But you can do it yourself without much effort.

Step 2 - Download and Install Diagnostic Tools

It's not as scary as you might think :)

Step 3 - Analyzing the Memory Dump

Now it all comes down to executing one command. Open command line and go to the folder where you extracted kdfe.cmd. Run the file, specifying the path to the memory dump file as a parameter (in the example below the file is called Mini1110307-01.dmp)

kdfe.cmd "%systemroot%MinidumpMini1110307-01.dmp"

In a minute you will see the result.

The driver causing the error has been identified!

Additional Resources

In Windows 8, Microsoft introduced a new memory dump - an automatic memory dump option. This setting is set by default in the operating system. In Windows 10 introduced new type 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 memory dump option? 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 installs a page of files into 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 choose the right option. 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.

Windows 10 has introduced a new dump file called 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 pagefile size. I know that sooner or later I will get a critical error. Then I'll check it.

You can analyze the dump Windows memory.dmp files via 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.

One of the most common failures Windows operation- system exceptions that the user sees as a “blue screen of death” (BSOD). As a rule, this fatal error occurs either due to a malfunction of drivers, hardware (usually when loading the OS) or due to the action of viruses and antiviruses.

The blue screen of death contains information about the reasons that caused the exception (in the form of a STOP error code of the form 0x0000007b), memory addresses that were accessed when an exception occurred, and other useful information. Such information is called a STOP error, the variable parameters of which are precisely memory addresses. Sometimes it also contains the name of the file that caused the exception.

All this information is not displayed on the screen for long (up to 100 seconds), after which the computer reboots. During this short time, as a rule, a memory dump is generated and written to a file. One of the important professional ways fault diagnosis - memory dump analysis, which will be discussed in detail in this article.

What is a dump

dump (English) – garbage heap; dump; hole; slum.
dump (memory dump) – 1) dump, outputting the contents of RAM to print or screen; 2) a “snapshot” of RAM; data obtained as a result of dumping; 3) emergency removal, shutdown, reset.
dumping – dumping, dump removal.

Settings for saving a memory dump are stored in system registry Windows.

Information about the memory dump in the system Registry:

In the section Windows Registry A crash dump is defined by the following parameters:

– REG_DWORD parameter AutoReboot with value 0×1 (Run option automatic reboot sub-window Boot and Restore of the System Properties dialog box);

– REG_DWORD parameter CrashDumpEnabled with a value of 0×0, if a memory dump is not created; 0×1 – Complete memory dump; 0×2 – Kernel memory dump; 0x3 – Small memory dump (64KB);

– REG_EXPAND_SZ DumpFile parameter with the default value %SystemRoot%\MEMORY.DMP (dump file storage location);

– REG_DWORD parameter LogEvent with a default value of 0×1 (option Log event to the system log of the Boot and Recovery window);

– REG_EXPAND_SZ MinidumpDir parameter with the default value %SystemRoot%\Minidump (Small dump folder option of the Boot and Recovery window);

– REG_DWORD parameter Overwrite with a default value of 0×1 (option Overwrite existing dump file of the Boot and Restore window);

– REG_DWORD parameter SendAlert with a default value of 0x1 (option Send administrative alert of the Boot and Recovery window).

How the system creates a crash dump file

During boot, the operating system checks the crash dump settings in the registry key. If at least one parameter is specified, the system generates a map of disk blocks occupied by the paging file on the boot volume and stores it in memory. The system also determines which driver disk device manages the boot volume, calculates checksums for the driver image in memory and for data structures that must be integer for the driver to perform I/O operations.

After a failure, the system kernel checks the integrity of the page file map, disk driver, and disk driver control structures. If the integrity of these structures is not violated, then the system kernel calls special I/O functions of the disk driver designed to save the memory image after a system failure. These I/O functions are self-contained and do not rely on kernel services because the programs responsible for writing the crash dump cannot make any assumptions about which parts of the system kernel or device drivers were damaged when a crash occurred. The system kernel writes data from memory to the paging file sector map (it does not have to use file system drivers).

First, the system kernel checks the status of each component involved in the dump process. This is done so that when writing directly to disk sectors, it does not damage data located outside the page file. The page file size must be 1MB larger size physical memory, because when information is written to a dump, a header is created that contains the crash dump signature and the values of several important system kernel variables. The header is less than 1MB, but the operating system can increase (or decrease) the size of the page file by at least 1MB.

After the system boots, Session Manager (Windows NT Session Manager; disk address - \WINDOWS\system32\smss.exe) initializes the system page files, using its own NtCreatePagingFile function to create each file. NtCreatePagingFile determines whether the page file being initialized exists and, if so, whether it has a dump header. If there is a header, then NtCreatePagingFile sends a special code to the Session Manager. Session Manager then starts the Winlogon process (Windows NT Logon Program; disk address is \WINDOWS\system32\winlogon.exe), which is notified of the existence of a crash dump. Winlogon runs the SaveDump program (Windows NT Memory Copy Program; disk address - \WINDOWS\system32\savedump.exe), which parses the dump header and determines further actions in an emergency.

If the header indicates the existence of a dump, then SaveDump copies the data from the page file to the crash dump file, the name of which is specified by the REG_EXPAND_SZ parameter of the DumpFile section of the Registry. While SaveDump rewrites the dump file, the operating system does not use the part of the page file that contains the crash dump. At this time the volume virtual memory, available to the system and applications, is reduced by the size of the dump (at the same time, messages may appear on the screen indicating a lack of virtual memory). SaveDump then informs the memory manager that the dump has completed saving, and it releases the part of the page file in which the dump is stored for general use.

After saving the dump file, the SaveDump program records the creation of a crash dump in the System event log, for example: “The computer was rebooted after a critical error: 0x100000d1 (0xc84d90a6, 0x00000010, 0x00000000, 0xc84d90a6). Memory copy saved: C:\WINDOWS\Minidump\Mini060309-01.dmp".

If the Send administrative alert option is enabled, SaveDump sends an alert to the administrator.

Types of dumps

Full memory dump records all contents system memory when a fatal error occurs. For this option, you must have a paging file on the boot volume, the size of which is equal to the amount of all physical RAM plus 1MB. By default, a complete memory dump is written to the %SystemRoot%\Memory.dmp file. When a new error occurs and a new full memory dump (or kernel memory dump) file is created, the previous file is replaced (overwritten). The Full memory dump option is not available on PCs that have a 32-bit operating system and 2 gigabytes or more of RAM.

When a new error occurs and a new full memory dump file is created, the previous file is replaced.

Kernel memory dump writes only kernel memory, making the process of writing data to the log when the system suddenly stops proceeds faster. Depending on the amount of physical memory of the PC, in this case the paging file requires from 50 to 800MB or one third of the physical memory of the computer on the boot volume. By default, the kernel memory dump is written to the %SystemRoot%\Memory.dmp file.

This dump does not include unallocated memory or memory allocated to user-mode programs. It includes only memory allocated to the kernel and hardware-dependent layer (HAL) in Windows 2000 and later versions of the system, as well as memory allocated to kernel-mode drivers and other kernel-mode programs. In most cases, such a dump is the most preferable option. It takes up much less space than a full memory dump, while excluding only those memory sectors that are most likely not related to the error.
When a new error occurs and a new kernel memory dump file is created, the previous file is replaced.

Small memory dump records the smallest amount of useful information necessary to determine the cause of the problem. To create a small memory dump, the page file size must be at least 2MB on the boot volume.

Small memory dump files contain the following information:

fatal error message, its parameters and other data;
list of loaded drivers;
the processor context (PRCB) on which the failure occurred;
process information and kernel context (EPROCESS) for the process that caused the error;
process information and kernel context (ETHREAD) for the thread that caused the error;
The kernel-mode call stack for the thread that caused the error.

The small memory dump file is used when hard disk space is limited. However, due to the limited information it contains, analysis of this file may not always detect errors that were not directly caused by the thread that was running when the error occurred.

When the next error occurs and a second small memory dump file is created, the previous file is saved. To everyone additional file a unique name is given. The date is encoded in the file name. For example, Mini051509-01.dmp is the first memory dump file created on May 15, 2009. A list of all small memory dump files is stored in the folder %SystemRoot%\Minidump.

The Windows XP operating system is undoubtedly much more reliable previous versions, – thanks to the efforts of both Microsoft developers, hardware driver developers, and application developers software. However, emergency situations - all kinds of failures and system crashes - are inevitable, and whether the PC user has the knowledge and skills to eliminate them depends on whether he will have to spend a few minutes troubleshooting and troubleshooting (for example, updating/debugging a driver or reinstalling application program causing a system failure) - or several hours to reinstall/configure the operating system and application software (which does not guarantee the absence of failures and crashes in the future!).

Many system administrators still neglect the analysis of emergency Windows dumps, believing that working with them is too difficult. It’s difficult, but it’s possible: even if, for example, the analysis of one dump out of ten turns out to be successful, the efforts spent on mastering the simplest techniques for analyzing crash dumps will not be in vain!..

I will give examples from my “sysadmin” practice.

IN local network without apparent reason(“hardware” is in order, the absence of viruses is guaranteed, users have “normal hands”) several workstations with Windows XP SP1/SP2 “on board” were killed. It was not possible to boot the computers in normal mode - it got to “Greetings” - and it took forever to reboot. At the same time, the PCs booted into Safe Mode.

The study of memory dumps made it possible to identify the cause of the malfunction: the culprit turned out to be Kaspersky antivirus, or rather, fresh ones antivirus databases(more precisely, two database modules – base372c.avc, base032c.avc).

...There was another such case. On a local PC running Windows XP SP3, a reboot occurred when trying to open video files in .avi and .mpeg formats. Studying the memory dump allowed us to identify the cause of the problem - the nv4_disp.dll driver file NVIDIA video cards GeForce 6600. After updating the driver, the problem was resolved. In general, the nv4_disp.dll driver is one of the most unstable drivers, which often led to BSOD.

In both of these cases, studying the crash memory dump made it possible to reduce the time for diagnosing and eliminating the malfunction to a minimum (several minutes!).

Memory dump analysis

There are many programs for analyzing crash memory dumps, for example, DumpChk, Kanalyze, WinDbg.

Let's look at analyzing crash memory dumps using the WinDbg program (part of Debugging Tools for Windows).

Installing Debugging Tools

visit Microsoft Corporation's Web site http://www.microsoft.com/whdc/devtools/debugging/default.mspx;
download Debugging Tools for Windows, for example, for a 32-bit version of Windows this can be done on the Download the Debugging Tools for Windows page;
after downloading, run the installation file;
in the Debugging Tools for Windows Setup Wizard window, click Next;
in the window with license agreement set the switch I agree –> Next;
in the next window, select the installation type (by default, debugging tools are installed in the \Program Files\Debugging Tools for Windows folder) –> Next –> Install –> Finish;
To interpret memory dump files, you must also download the Symbol Packages for your version of Windows - go to the Download Windows Symbol Packages page;
choose yours Windows version, download and run the Symbol Packages installation file;
in the window with the license agreement, click Yes;
in the next window, select the installation folder (the default is \WINDOWS\Symbols) –> OK –> Yes;
in the window Microsoft Windows Symbols with the message “Installation is complete” click OK.

Using WinDbg to Analyze Crash Dumps

run WinDbg (installed in the \Program Files\Debugging Tools for Windows folder by default);
select menu File –> Symbol File Path…;
in the Symbol Search Path window, click the Browse... button;
in the Browse Folder window, specify the location of the Symbols folder (by default – \WINDOWS\Symbols) –> OK –> OK;
select menu File –> Open Crash Dump... (or press Ctrl + D);
in the Open Crash Dump window, specify the location of the Crash Dump File (*.dmp) –> Open;
in the Workspace window with the question “Save information for workspace?", check the Don"t ask again –> No box;
The Command Dump window will open in the WinDbg window<путь_и_имя_файла_дампа>with dump analysis;
review the memory dump analysis;
in the “Bugcheck Analysis” section will be indicated possible reason crash, for example, “Probably caused by: smwdm.sys (smwdm+454d5)”;
to view detailed information, click the “!analyze -v” link in the “Use !analyze -v to get detailed debugging information” line;
close WinDbg;
Use the information obtained to eliminate the cause of the problem.

For example, in the following screenshot the cause of the malfunction is the nv4_disp.dll file of the video card driver.

Blue screen of death(eng. Blue Screen of Death, Blue Screen of Doom, BSoD) - messages about critical system error in Microsoft Windows operating systems. Many who encounter a blue screen of death on their computer/laptop see the only solution as reinstalling the operating system. But sometimes the OS has nothing to do with it, but the problem is in the hardware. In order not to guess - why did the blue screen of death appear, you need to use the information provided by the operating system itself in the form of logs. In this article, I will describe step by step how to find out the cause of the blue screen of death.

So, the appearance of the blue screen of death is always unexpected and at the wrong time, so many simply do not have time to see what is written, and it must be said there (though not in a very explicit form) the reasons for the failure. First of all, I suggest setting up your computer/laptop so that it does not reboot immediately after a system failure, but gives you the opportunity to see the cause of the failure, if this information is not enough, you need to look dump a file that contains 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.

Settings regarding rebooting after a system failure can be specified by right-clicking on the My Computer/Computer shortcut (suitable for Windows XP, Windows7, Windows8), selecting " Properties", or press the key combination + . All printskirns below will concern Windows7, the same method is configured on Windows XP, Windows8, Windows8.1.

On the "tab" Additionally"select in the Boot and Recovery field" Options".

Uncheck " Perform automatic reboot", in order to have time to see everything that the blue screen of death writes. The line Dump file indicates the path where the file will be saved, which will indicate the reasons for the failure.

Now you can carefully study the information when a blue screen of death appears. If your computer no longer boots, and you cannot change these settings, in this case, when booting, press F8 on the keyboard and select the menu item “If the system fails, do not reboot.”

If the information indicated there is not enough, you can use a dump ( dmp file). To do this, you can use the microsoft-microsoft debugging tool, but it weighs a lot and requires installation and framework 4.5. You can get by with fewer sacrifices if you use the program BlueScreenView . In my opinion very convenient program does not require installation and in Russian (add the file to the program folder). By running the BlueScreenView.exe file, the program interface will open in which the dump of this computer will already be loaded (the default path is C:\Windows\MiniDump, if you go to Settings - Advanced parameters, you can specify a different path if you copied the dump to another location).