How to use a memory dump to determine the driver causing the BSOD. Windows crash memory dump Memory dump to cpp file windows 10

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 to obtain 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 did not allow me to save 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 with the version of Windows 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 paging 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. They are usually created automatically 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 with an administrative account to perform the actions 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. Run on 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 possible memory dump. 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.
• The 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

Parameters:

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 crash of the operating system, there are situations when it is necessary to obtain a system memory dump at a specific point in time. What to do 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.

When a critical failure occurs, the Windows operating system crashes and displays a Blue Screen of Death (BSOD). The contents of RAM and all information about the error that occurs is written to the paging file. The next time you boot 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 a critical error occurs during the initial stage of Windows boot.

Types of Windows Crash Dumps

Using the current operating system Windows 10 (Windows Server 2016) as an example, let's look at 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. The largest in size and requires memory equal to your system's RAM plus the 1MB required by 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 are using a 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 the 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.

1. Open a command prompt as an 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
2. 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 the compilation of a program together with the 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 use Microsoft 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 to pay attention to is the error code, which is always indicated in hexadecimal and has the form 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 a preliminary analysis of the memory dump and provides detailed information to begin the 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 take 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
FFFD000`3A20D3F0 FFFFF804`0117C150: 0000000000 000000 000000 00000000 000000 00000000 000000`00000000: nt! Kifastfaildispatch+0xd0
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+0x 13
000000ee`f25ed2b8 00000000`00000000: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: 0x00007ffb`4753 07da

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), that file is most likely not the cause of the problem. Very often it turns out that the problem lies in the device driver, BIOS settings or hardware failure.

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.

If the so-called blue screen of death in Windows 10 appears in front of you and you are ready to fall into a nervous coma, pull yourself together and try to solve the problem. To begin with, it’s worth saying that this ominous message signals you about a critical system error. Moreover, it is not always possible to catch the moment and have time to read the error code when Windows falls into the blue screen of death and the device reboots. Let us immediately note that there are a huge number of solutions to this problem, as well as the reasons for the appearance of a blue screen. In this article we will try to consider the probable causes of the blue screen of happiness, as well as possible solutions to the problem.

In the vast majority of cases, the blue screen of death signals the error BAD_POOL_CALLER - stop 0x000000c2. To put it bluntly, it is difficult to diagnose this error, but perhaps we will try to use this error as an example to describe the algorithm for your next actions.

To properly diagnose the problem, you should first analyze a special system file called minidump. The creation of such files is caused by a system failure; moreover, they can inform us what exactly led to the failure.

1. To enable this automatic recording of a small memory dump (disabled by default), go to the computer properties and go to the "Advanced system settings" section (this enablement is provided for all systems, not just Windows 10):

As a rule, all minidump files are saved when a blue screen of death (BSOD) appears, and you can find them in the C:\Windows\Minidump folder. It is noteworthy that the file name contains the current date - when it was created, which makes it much easier to identify the date the error occurred, especially considering that there may be more than one such file.

Two ways to decrypt a small memory minidump

First way, consists of using the fairly popular BlueScreenView utility. This utility can also be a good option for analyzing a memory dump. The use of this utility will come in very handy as a way to identify the problematic driver.

Moreover, it is especially notable for the fact that with its help it is possible to view the BSOD (blue screen of death) as if in a freeze frame, as it was when the system crashed. It displays the time and date of the failure, information about the driver or module with the version and a brief description. In addition, the utility is available in many languages, including Russian. So the BlueScreenView utility is just the thing if you need to quickly analyze memory dumps during BSOD.

For second method you need to install Debugging Tools for Windows and also download the bsdos_utility utility. Next, after unpacking the bsdos_utility.cmd script, you should move it to the C:\ drive (you can create a separate folder, but it is worth remembering that the script launch address line will be different from our example). Then on the command line you should write:

C:\bsdos_utility.cmd

After displaying a list of all dumps from the list C:\Windows\Minidump\, after which the script will ask which dump should be analyzed. You can also select the required minidump yourself when running the script:

In a similar way, it is possible to detect a lot of Windows 10 errors that caused a BSOD, as well as problematic .exe programs that caused a blue screen.

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. Above, I described to you a very common reason why 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 that is responsible for the Windows 10 crash memory dump. Right-click on the Windows 10 start button and select System from the context menu.

In the System window that opens, in the upper left corner you 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 the system log > here information about the blue screen will be added to the operating system logs.
• 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 the existing dump file, 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 drive. Due to 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 the amount of physical memory of the PC in this case, the paging file requires from 50 to 800 MB or one third of the computer's physical memory on the 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.

All Windows systems, when a fatal error is detected, make a crash dump (snapshot) of the contents of RAM and save it to the 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: 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:

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 non-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).