When a fatal error occurs on your system, Windows displays the famous blue screen of death (or BSoD for Blue Screen of Death). This fatal error occurs when the operating system reaches a critical state where it can not function properly. You may encounter one when you install an update, a program, a hardware, or suddenly, without any specific action appearing to have triggered it. Windows always acts like this: it stops suddenly to protect itself from possible data loss, displays its blue screen then restarts your computer.
Did you know ?
According to reports of errors that were sent to Microsoft until April 2014, the reasons why Windows crashes are as follows:
Third-party device drivers: 70%
Unknown because of severe memory corruption: 15%
Hardware errors: 10%
Microsoft code: 5%
Source: “Crash Dump Analysis” – MSDN
Sometimes exceptional, the blue screen of death that follows a fatal error can unfortunately be displayed repeatedly on your machine. If this is the case for you now, you will need to find the driver responsible for the fatal error and provide a solution. A device, its driver, or a program related to it can be the cause of a blue screen. An update of the driver or program resolves in most cases the problems encountered.
In this tutorial, I will show you how to analyze a blue screen to find the driver responsible for the fatal error and thus be able to permanently solve the problem! The goal is to allow you to use your PC again and again, without fear that a blue screen will appear again and interrupts you in your work 🙂
Preamble: Memory Dump Files
When the system crashes, Windows displays a blue screen, which is accompanied by a stop code. This stop code gives us first information about the nature of the fatal error. You can find all stop codes and their meanings on the Bug Check Code Reference page of the Microsoft Hardware Dev Center.
However, this stop code can be quite stingy in information. In the above capture, the MEMORY_MANAGEMENT shutdown code indicates that a serious memory management error has occurred … without much knowledge (see Bug Check 0x1A: MEMORY_MANAGEMENT).
Until Windows 7, the blue screen displayed the four parameters associated with the stop code (these four settings can be found in Event Viewer for Windows 8.1 and 10). They allow to know a little more about the fatal error. For example, the first parameter of the UNMOUNTABLE_BOOT_VOLUME shutdown code indicates the device that failed to be mounted by the system (see: Check Check 0xED: UNMOUNTABLE_BOOT_VOLUME).
When available, the name of the driver that crashed is also displayed, such as RTKVHD64.sys in the screenshot below. The latter tells us much more about the cause of the fatal error. Google search tells us it’s the Realtek High Definition Audio driver.
After the system crashes and after the blue screen appears, Windows dumps the computer’s physical memory (RAM) by unloading its contents into a file on the hard disk: the memory dump file (or Memory Dump File). You can also follow the progress of the emptying of the memory on the blue screen via the percentage of completion which is incremented little by little (until “100% completed”). This memory image file thus contains a copy of all the data present in the memory of the computer before the crash. This data will prove invaluable to establish a complete diagnosis of the Windows crash. By consulting them, we will surely find the driver responsible for the crash of Windows!
There are two types of memory dump files: Kernel-Mode Dump Files and User-Mode Dump Files.
How to fix the Blue Screen on Windows 10 System :
To solve our blue screen problem, we will analyze kernel mode memory dump files. These are the files that contain the information to debug the system; User mode files allow them to debug only programs installed by users.
Windows can generate five types of memory dump for kernel mode, the difference being around the size of the generated file:
1. Full memory image: The largest memory dump file. This file includes all the physical memory that was used by Windows at the time of the crash. It requires a swap file  on the boot drive that is at least as large as the main memory of the system; the size of the swap file must be equal to all the RAM + 1 MB. If you have 16 GB of RAM on your computer, the size of the swap file must be 16.001 GB to accommodate the data of the memory physical !
2. Kernel memory map: contains only the memory used by the kernel at the time of the crash. This file is considerably smaller than the complete dump file (1). Its size is about one third of the physical memory installed on the system (if you have 16 GB of RAM, the file size will be about 5.3 GB). This image file does not include unallocated memory, or memory allocated to user-mode applications. It contains only the memory allocated to the Windows kernel, the hardware abstraction layer (HAL), and also the memory allocated to kernel mode drivers and kernel mode programs. This is the most useful memory dump file. Smaller and faster to execute than the full memory dump file (1), it does not contain the physical memory data that is not usually involved in the crash.
3. Partial Memory Image (256 KB): The smallest “kernel mode” memory dump file, useful on systems with very limited disk space. Since it contains limited information (stop message, list of loaded drivers …), the analysis of this file may not be able to discover the source of the errors encountered when the computer crashed.
4. Automatic Memory Dump: Contains the same information as the kernel memory dump file (2). The difference between the two is not in the image file itself, but in the way Windows sets the size of the system swap file. If the system swap file size is set to Automatic Swap File Handling for Drives, and the “Kernel Mode” memory dump setting is set to Automatic Memory Dump, Windows automatically sets a size for the swap file, large enough to capture the kernel memory image.
5. Active memory dump: Similar to the complete memory dump (1), it does not contain the memory assigned to Hyper-V virtual machines, which is not necessary for debugging the host machine.
You can configure the type of memory dump that Windows creates in the event of a crash in Advanced System Settings (%SystemRoot%\System32\SystemPropertiesAdvanced.exe)> Startup and Recovery. It is recommended to leave the default memory dump type: Automatic Memory Dump.
Only one and only one memory dump file can be created during a system crash. If a second fatal error occurs and a kernel memory dump (or a full memory dump) is created, this will overwrite the previous one (if the Replace all existing files parameter option is checked). The memory dump file is written by default in %SystemRoot%\Memory.dmp.
Note that Windows creates a new partial memory dump file each time the system shuts down unexpectedly (when the blue screen is displayed), even if you have selected Kernel Memory or Full Memory settings. If a second fatal error occurs, a second partial memory image is created and the previous one will be retained. Each new partial dump file will have a different name, with the date of the crash encoded in the file name. For example, 050917-10843-01.dmp is the dump file generated on May 9, 2017. All partial dump files are kept in the %SystemRoot%\Minidump folder.
Now that you know how the memory images work, let’s check the debugging information they contain to find the module responsible for these blue screens repeatedly !
Find the driver responsible for the blue screen :
to start, we will analyze partial memory dump files. Even if they contain little information, it is not uncommon to find the driver responsible for the fatal error !
Via the small memory dump files (Small Memory Dump) :
The Memory Image Control Utility (Dumpchk.exe) is a command-line utility provided by Microsoft to check and read memory dump files. Unlike the available tools, Dumpchk.exe does not require access to debugging symbols. Although effective, this tool is not very ergonomic. That’s why we’re going to use the BlueScreenView program: it scans all the memory dump files created on your computer after a Windows crash, and clearly displays the information they contain.
In the top pane, all the dump files found in the %SystemRoot%\Minidump folder and the %SystemRoot%\Memory.dmdp image file are displayed. In the above screenshot, six partial memory images are displayed. This means that this computer has encountered the blue screen of death six times! For each crash, BlueScreenView displays the name of the partial memory dump file, the date and time of the crash, the stop code (displayed on the blue screen), the 4 parameters of the stop code, and the details about the driver that probably caused the crash (file name, product name, file description, and file version).
In the lower panel, by default, BlueScreenView displays all the drivers that were loaded during the crash (which you selected in the top panel). The drivers whose memory address was found in the crash stack are highlighted in pink, which makes it easy to locate the drivers that are likely to be responsible for the crash.
Your mission is simple: locate the driver responsible for the blue screen in the Caused By Driver column!
In the screenshot below, we can see that the 5 August 2013 crash was caused by the nvlddmkm.sys driver, which is probably running an NVIDIA graphics card.
If you want more details about the detected driver (which component, device, or program it belongs to), right-click the dump file and select Google Search – Bug Check + Driver to search the Internet.
Unfortunately, partial image files often do not contain enough information to identify the driver responsible for the blue screen. This is the case if BlueScreenView displays ntoskrnl.exe in the Caused By Driver column. This is wrong: it is simply the last file in the stack that was loaded before the blue screen appeared. This is NOT the file that caused the fatal error.