Analyzing a memory dump or how to identify the cause of BSoD? Windows crash dump

If a critical error occurs while working with Windows, the user may wonder: how can I access a Windows crash dump? Such a dump, if the system configuration is correctly configured, will help start the system in the event of a crash or the so-called blue screen of death (BSOD).

If you encounter problems while setting up a memory dump or the operating system does not work correctly after this, you can.

Windows 10 Memory Dump

A memory dump is something that is in the working memory of the entire operating system, the processor and its cores. Including all information about the state of processor registers and other service structures.

Why do you need a Windows 10 memory dump?

A Windows 10 memory dump is a kind of black box. In the event of a system failure, the information stored in it will help to study in detail the causes of the system failure. This failure usually completely stops the operating system. Therefore, a memory dump is the only and most reliable way to obtain information about any failure in the system. And receiving it is an actual snapshot of the information located in the system.

The more accurately the contents of the memory dump reflect what was happening in the system at the time of the failure, the easier it will be when analyzing the emergency situation and further actions to correct it.

It is extremely important to obtain an up-to-date copy at the exact moment immediately before the failure. And the only way to do this is to create a Windows 10 crash dump.

The reasons for errors in Windows 10 are very diverse:

— incompatibility of connected devices;

- new Windows 10 updates;

— incompatibility of installed drivers;

— incompatibility of installed applications;

- and other reasons.

How to set up a memory dump in Windows 10?

In order to set up a Windows 10 crash dump, you must follow these steps:

1. Right-click on Windows 10 Start. In the context menu that appears, select “System”.

2. In the “System” window, in the upper left corner, select “Advanced system settings”.

3. In the “System Properties” window, in the “Boot and Recovery” item, click “Options”.

This is where you set up a Windows 10 crash dump.

When setting up a memory dump, you can not neglect the following recommendations:

— Check the box “replace existing dump file”. Considering the fact that data can weigh tens or even hundreds of gigabytes, this is very useful for small hard drives;

— Recording debugging information. This function will allow you to select the type of dump file;

— Perform an automatic reboot. Continuing work after an error has occurred;

— Recording an event in the system log. Information about the system failure will be added to the operating system logs.

A Windows 10 memory dump is a convenient and really working method of insuring system data.

Knowing the enemy “in person” will make it much easier to find and eliminate him. A Windows 10 memory dump will allow you to identify the cause of a system failure and adjust actions to eliminate the error, significantly reducing the radius of effort and work.

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 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:

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

Windows is a very fragile creation and just about any wrong action on the part of the user will lead to critical errors, and not very good ones. Information written on the screen itself, as well as special files, help you find out information about blue screens of death, which are those very critical problems. memory dumps– storing data about the causes of BsoD. I strongly recommend enabling this feature, since no one is immune from blue screens, even an experienced user. The memory dumps themselves are usually stored along the path C:\Windows\MEMORY.DMP, or C:\Windows\Minidump– where the so-called small memory dumps are stored. By the way, a small memory dump will be the file that will help you find out the cause of BsoD.

How to enable the memory dump function on Windows 10 and configure it

Typically, utilities like BlueScreenView are used to view dumps, but you need to set up automatic creation of memory dumps right now, otherwise this program and similar ones will be useless.

This is useful:

Click on the search icon and enter the phrase "Control Panel" to open the tool window.

Converting the display of icons to the form "Small Icons", and then go to the section "System".

A window will open, where on the left side click on the option "Advanced system settings".

In the “Advanced” tab, click the item

Finally, a window opens where the main parameters for configuring dumps are located. Here you can see that an automatic memory dump is activated in Windows, which is stored in the path indicated just below. The checkboxes for creating logs are also included. In addition, small memory dump files are also created, which will be very useful to us when working with blue screens of death. Information on the system core and memory is also saved. If the mode is automatic, then this will be enough.

Information about other memory dumps

If you open the drop-down menu for recording debugging information, you will see several options that I will describe below.

• Small memory dump– a mini dump, which is saved along a special path and weighs 256 Kilobytes. This file stores basic information on blue screens of death and system processes. If you need to find out the cause of the BSOD, then a small memory dump is enough. BlueScreenView or similar programs are used to retrieve information. Any beginner can use this method.
• Kernel memory dump– the file will contain the same information as the automatic type. The only difference is that the system changes the paging file. Which option should I choose? I think it's an automatic type.
• Full memory dump– the file contains complete data about RAM, which means the file size will be equal to the size of the RAM. You have 8 GB on your PC, which is how much the full memory dump file will occupy on the disk. This option is not particularly suitable for beginners.
• Active memory dump– first appeared in Windows 10. More suitable for servers and stores data about active memory and kernel modes, as well as the current user.

How to delete a memory dump file

It’s very simple, you go to the path where these files are located and manually delete them. For example, the full memory dump file is called MEMORY.DMP, just delete it and that's it. When using the Disk Cleanup tool, there is also an option to delete dump files.

Memory dump may be disabled due to system cleaning utilities. When using SSDs and special utilities for working with these drives, they can also disable some system functions so that the SSD is less subject to read/write procedures.

One of the most common Windows failures is system exceptions, which the user sees in the form of 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, a memory dump is usually generated and written to a file. One of the important professional methods for diagnosing failures is 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 the Windows system registry.

Information about the memory dump in the system Registry:

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

– REG_DWORD parameter AutoReboot with the value 0×1 (option Automatically reboot the auxiliary 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 disk device driver controls the boot volume, calculates checksums for the driver's memory image, 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 size of the page file should be 1 MB larger than the size of physical memory, because when information is written to the dump, a header is created that contains the crash dump signature and the values ​​of several critical 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 analyzes the dump header and determines further actions in an emergency situation.

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. During this time, the amount of virtual memory available to the system and applications is reduced by the dump size (and messages may appear on the screen indicating that virtual memory is low). 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 writes the entire contents of 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. Each additional file is given a unique name. 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 than previous versions, thanks to the efforts of both Microsoft developers, hardware driver developers, and application software developers. 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 (for example, updating/debugging a driver or reinstalling an application). program causing a system crash) - 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 to analyze Windows crash 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.

On the local network, for no apparent reason (“the hardware is in order, the absence of viruses is guaranteed, the users have “normal hands”), several workstations with Windows XP SP1/SP2 “on board” went down. 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.

Studying the memory dumps made it possible to identify the cause of the malfunction: the culprit turned out to be Kaspersky Anti-Virus, more precisely, fresh anti-virus 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 file of the NVIDIA GeForce 6600 video card driver. After updating the driver, the problem was eliminated. 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 the license agreement, select the I agree –> Next switch;
• 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;
• select your version of Windows, 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 Microsoft Windows Symbols window 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 the possible cause of the crash will be indicated, 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.