Crash memory dump. Windows crash memory dump What does dump memory mean?

This short note aims to show how you can configure the system in order to get an emergency dump Windows memory , 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, which includes, 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 physical memory systems.

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

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

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

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

All crash dumps can be divided into two main categories:

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

Kernel memory dump configuration

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

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

1. Click right click mouse on the icon "My Computer" - "Properties" - " Extra options systems" - "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 failure. 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

Since Windows 8/ Windows Server 2012, a new dump type called "Automatic Memory Dump" was introduced into the system, 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 automatic creation system crash dumps in case of a critical error, that is, an unhandled exception in the kernel code. But in real life, in addition to the operating system crash, there are situations when it is necessary to obtain a system memory dump at a specific point in time. How to be in this case? There are methods for obtaining a snapshot of all physical memory, for example using the .dump command in the WinDbg/LiveKD debuggers. LiveKD is a program that allows you to run the Kd kernel debugger on a running system in local mode. The WinDbg debugger also has a similar feature. However, the on-the-fly dump method is not accurate because the dump generated in this case is "inconsistent" since it takes time to generate the dump, and in case of using the kernel mode debugger, the system continues to run and make changes to the memory pages.

By and large, you, as a user, should not be interested in a memory dump. This is just information about a system failure, which ideally should be sent to Microsoft developers to find and fix critical errors. If you do not plan to engage in such charity, then you can disable the dump.

Disabling memory dump will not affect system performance in any way. When you use your computer, the system does not access the dump, whether it is turned on or not. Recording occurs only when Windows is “brought” to BSOD ( blue screen). It lasts a couple of seconds at most.

Types of dump

For general development, let's get acquainted with the types of dump. There are three of them: small dump, core dump and large. A small dump stores the most important information about the problem. Developers literally have to piece it together bit by bit. For a small dump you need to allocate 2 MB of virtual memory (swap file).

Core dump– the most common type of dump. This option is usually the default. It records all the memory that is allocated to the core - the state of working drivers and data on the hardware-dependent level. For it you need to allocate about 30% of the total amount of RAM. For example, if you have 2 GB DDR, then allocate about 700 MB for the swap file.

A full dump records the entire contents of RAM. Accordingly, for it to work, you will have to allocate the same volume to the paging file as RAM. We need a full dump for hibernation mode, when all data from RAM is loaded onto the hard drive.

In Windows 7, the dump parameters are hidden quite deeply. Enter in the search bar in the menu " Start" word " system", For example.

Select result " System" A window will open. There is a list of options at the top right, select the last one - “ Advanced System Settings».

Any modern operating system is a very complex set of different software modules, which work together in different combinations. They may contain errors or may conflict with each other or with running program. As a result, a crash occurs and Windows stops working, showing the well-known “blue screen of death”. A Windows 10 memory dump will help you understand why this happened, and it also works in other versions. By default they are usually not created, so you need to enable them and use them to study special programs, which will extract useful information in an understandable way.

Setting up a memory dump.

Essentially, this is a “snapshot” of RAM, its contents at the moment when the failure occurred. This content is written to a separate file, which is called a dump. By analyzing it, you can understand what went wrong and in which part of the program the problem occurred. When everything is normal and no failures occur, the system does not create any files with the contents of memory. Therefore, this function does not affect performance in any way. But it's worth it to happen fatal error, which causes a “blue screen” to appear as such a file is created. This is a special tool that helps developers fix such problems. Regular users can also use this to find out which programs are causing the system to crash. But keep in mind that for this you need to have some knowledge of how computers work and software, otherwise all this information will be completely useless. An ordinary user of the “I can turn it on, type, turn it off” level will simply not understand anything about it.

Setting up memory dumps for Windows errors

To see and configure, for example, to increase the Windows memory dump, consider version 7 - it continues to be popular. Yes, and in other versions this is done in a similar way. To do this, you can right-click on the “My Computer” icon and select “Properties”. You can go the other way - go to the “Control Panel” and select “System”. In either case, the same window will open. Next, select “Advanced system settings” on the left, and in the small window that appears, go to the “Advanced” tab. Here, in the “Boot and Recovery” section, click on the “Options” button.

1. Small dump - its volume is only 256 kb, only the most general information is recorded there.
2. Kernel memory dump - status is recorded here various programs at the time of failure for one processor core. The file size is about 33% of the total available RAM. There is helpful information, allowing you to identify the cause of the failure, but there is not very much of it.
3. A full dump is a copy of the entire RAM, and the file size will be equal to its capacity. Here you can find anything you want. Such a dump is also created when switching to hibernation mode - the entire contents of the RAM are simply saved to the hard drive, and when the computer is turned on, it continues to work from the same place.

In newer versions of Windows there is an “Automatic memory dump” mode - you can select it, and this will be quite enough. As you can see, setting up a memory dump in Windows 7 is not difficult. It will only be recorded during failures and will not affect the operation of the system in any way.

How and with what to open a memory dump file

When it fails and is created new file with a problem report, you still need to somehow open it and find out what is written in it. The file has a dmp extension, but the built-in tools for opening it are inconvenient and can be accessed from the command line. By the way, the system saves this file in its own folder. How to open a memory dump file with a dmp extension? There are various utilities for this, including those from Microsoft, for example, Microsoft Kernel Debuggers. It can be downloaded completely free of charge from the official website, but you need to consider whether a 32-bit or 64-bit version is needed. This program can open memory dump files that are located in system folder and view their contents in transcript form. Of course, the information is highly specific and intended for specialists.

There is another popular utility - BlueScreenView. It is very simple and easy to use. But the information displayed is not so easy to understand, but with some technical knowledge it is quite possible. In red, the program highlights in the list the problematic parts of the code that caused the blue screen, for example, certain drivers. This greatly simplifies the work of analysis.

How to delete a memory dump file

Is it possible to remove them at all? Yes, they are simply service information for further analysis. If you have already viewed them or they are not needed, then you can delete them yourself. in a simple way- Add to cart. Otherwise, they gradually accumulate and begin to take up a lot of space on the hard drive, especially if a full copy is made random access memory. Of course, searching manually and deleting all these files is not a very pleasant task. Therefore, you can use any disk cleanup utility, even the one built into Windows, by checking “Delete system files" When it works, all dumps will also be deleted. The system itself does not use these files and deleting them is completely safe.

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

Memory dump options

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

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

Click on the Advanced system settings button.

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

Here you can choose the right option. Suggested options:

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

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

it's called "LastCrashTime".

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

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

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

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

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

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

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. Next time booting 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 critical error arose during the initial stage of Windows boot.

Types of Windows Crash Dumps

Using the example of a current operating room Windows systems 10 (Windows Server 2016) 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 Windows kernel and hardware abstraction layer (HAL), as well as memory allocated to drivers and other kernel-mode programs.
• Complete memory dump. Largest in size and requires memory equal to your system's RAM plus 1MB, required 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 use 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 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 command line as 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 loads the necessary symbols for debugging from 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 preliminary memory dump analysis and provides detailed information to start 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 gain 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 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 indicates system driver(for example, win32k.sys) or a kernel file (as in our example ntkrnlmp.exe), most likely this file is not the cause of the problem. Very often it turns out that the problem lies in the device driver, BIOS settings or equipment malfunction.

If you see that the BSOD occurred due to 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.