How to use a memory dump to determine the driver causing the BSOD. Windows crash dump

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

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

Having completed all the manipulations, after each BSoD a file with the extension .dmp will be saved in the C:\WINDOWS\Minidump folder. I advise you to read the material “How to create a folder.” 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 THE BLUESCREENVIEW PROGRAM

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

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, as a rule, a memory dump is 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.

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:

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

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

Analyzing a crash dump using BlueScreenView

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

The program consists of three main blocks:

  1. Main menu block and control panel;
  2. Crash dump list block;
  3. Depending on the selected parameters, it may contain:
  • a list of all drivers in RAM before the blue screen appears (by default);
  • a list of drivers located in the RAM stack;
  • BSoD screenshot;
  • and other values ​​that we will not use.

In the memory dump list block (marked with number 2 in the figure), select the dump we are interested in and look at the list of drivers that were loaded into RAM (marked with number 3 in the figure). The drivers that were on the memory stack are colored pink. They are the cause of BSoD. Next, go to the Main Menu of the driver, determine which device or program they belong to. First of all, pay attention to 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).

Or, as it is also called, BSOD, can significantly ruin the life of both the computer and the server, and it also turned out to be a virtual machine. Today I’ll tell you how to analyze the blue screen of dump memory in Windows, since correct diagnosis and getting the reason why your system is not working, 99 percent of its solution, especially a system engineer, is simply obliged to be able to do this, and in the shortest possible time, so How can a business lose a lot of money due to service downtime?

BSOD decryption

Let's first look at what this abbreviation means, BSOD from the English Blue Screen of Death or also STOP error mode.

Blue screen of death errors occur for various reasons, including driver problems, a faulty application, or a faulty RAM module. As soon as you have a blue screen in Windows, your system will automatically create a crash memory dump file, which we will analyze.

How to configure memory dump creation

By default, when there is a blue screen, Windows creates a crash dump file memory.dmp, now I will show how it is configured and where it is stored, I will show using Windows Server 2008 R2 as an example, since I recently had a task to study the issue of a blue screen in a virtual machine. In order to find out where dump memory windows is configured, open Start and right-click on the Computer icon and select properties.

How to analyze blue screen dump memory in Windows - Computer Properties

How to analyze blue screen dump memory in Windows system settings

Go to the Advanced tab - Boot and Recovery. Click the Settings button

How to analyze blue screen dump memory in Windows - Boot and recovery

Where is the memory.dmp file stored?

and we see that first of all there is a checkbox to perform an automatic reboot to record debugging information, Kernel memory dump is selected and below there is where the memory dump is saved %SystemRoot%\MEMORY.DMP

Let's go to the c:\windows\ folder and find the file MEMORY.DMP it contains blue screen of death codes

How to analyze blue screen dump memory in Windows-memory.dmp

How to set up mini dump

Blue screen of death errors are also recorded in the small memory dump; it is configured there, you just need to select it.

It is stored in the c:\windows\minidump folder. The advantage is that it takes up less space and is created as a separate file for each blue screen. You can always view the history of blue screen occurrences.

Now that we have figured out where to look for the memory dump file, we need to learn how to interpret it and understand the reason why the blue screen of death occurs. Microsoft Kernel Debugger will help us solve this problem. You can download Microsoft Kernel Debugger from the official website, the main thing is to select the desired OS version. If someone breaks it, you can download it from the Yandex disk using a direct link. It is also part of ADK.

Download Microsoft Kernel Debugger, as a result you will have a small file that will allow you to download everything you need from the Internet. Let's launch it.

We will not participate in the quality improvement program

Click Accept and agree to the license

How to install Microsoft Kernel Debugger - agree to the license

Microsoft Kernel Debugger installation will begin

How to Install Microsoft Kernel Debugger - MKD Installation

We see that Microsoft Kernel Debugger has been successfully installed

After which we see that the Debugging Tools for Windows folder has appeared in the startup for both 32 and 64 bit systems.

In addition to the Debugging Tools for Windows package itself, 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; a 64-bit OS will require the Windows XP 64-bit character set. For other operating systems of the Windows family, character sets are selected according to the same principle. You can download debugging symbols from here. It is recommended to install them at %systemroot%\symbols although I like to install them in separate folders and avoid cluttering the Windows folder.

Blue Screen Analysis in Debugging Tools

After installing Debugging Symbols for the system that had the blue screen of death, launch Debugging Tools

How to install Microsoft Kernel Debugger - Run

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 File > Symbol File Path… from the menu.

Click the Browse button...

and indicate the folder in which we installed the debugging symbols for the memory dump in question, you can specify several folders separated by commas and you can request information about the required debugging symbols directly via the Internet, from a public Microsoft server. This way you will have the latest version of the symbols. You can do this as follows - in the menu File > Symbol File Path... enter.

How often do you see the Windows Screen of Death (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? The Windows operating system is capable of storing 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 a 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 Debugging Tools for Windows package itself, 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; a 64-bit OS will require the Windows XP 64-bit character set. For other operating systems of the Windows family, character sets 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 over the Internet, from a public Microsoft server. This way you will have the latest version of the symbols. 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 debug 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.