It finally happened. Out of the blue, you’re enjoying a game, watching a movie, or just reading on the internet, when your operating system decides it doesn’t want to cooperate and suddenly you’re facing down a BSOD or Blue Screen of Death. A BSOD is something that no Windows user wants to see, because it means that your system has crashed, costing you time and perhaps even resulting in data loss.

 Perhaps the worst thing about getting a Blue Screen of Death is that it could be the result of any number of issues, from a faulty piece of hardware to a driver error to having a page fault in a non-paged area (a result of a file not being found in memory). However, all isn’t lost and we’re going to show you how to enable and use a minidump log file to diagnose the problem.

Why You Need a Minidump File to Diagnose Your BSOD

In earlier versions of Windows, the BSOD showed you some error codes that were at least a little bit helpful. However, in Windows 10, the screen gives you a stop code you can write down and research and a QR code you can use with your phone. However, this only sends you to the Microsoft website and provides a description of certain error codes.

What we find useful is configuring Windows to save a file that contains lots of information regarding the BSOD and how we can go about fixing the error. This is called a minidump file.

How to Configure Windows to Save a Minidump File.

By default, the option to create a minidump file is not enabled so you’ll need to turn it on. Do this now, even if you don’t have a BSOD problem, because otherwise you won’t have a log when the crash happens.

1. Navigate to the System Properties Control Panel menu. You can get there by typing “sysdm.cpl” into the Windows search box. Or by going to Settings->System->About and clicking Advanced system settings.

2. Select the Advanced tab.

3. Enable the following options:

●     Write an event to the system log

●     Automatically restart

●     Writing debugging information -> Small memory dump (256kb).

With this enabled, whenever Windows crashes, the minidump file will be created under “%SystemRoot%Minidump”. You can also change this location if you choose to. However, if you do, keep in mind that most programs to troubleshoot the minidump logs are set to look for this location by default. So it’s best to leave it as it is. This also translates to C:WindowsMinidump.

How to Read the Minidump, See What Caused Your BSOD

Now that the minidump is configured, you’ll need to download an application that can read the file and provide useful information. A tool called BlueScreenView comes recommended for doing just this.

You can download BlueScreenView by going to the official website and selecting either the 32-bit or 64-bit version of the application.

After downloading the tool, you’ll need to extract it to a location, so it can be run.

Once the tool is extracted to a directory, double click the “BlueScreenView” icon to get started. BlueScreenView will then look at the default minidump location and will look through the current logs that have been created. If you’ve experienced a number of issues or haven’t removed older minidump files, you’ll need to be mindful of the dates associated with the logs.

Using BlueScreenView to Understand Minidump Files

When you first use BlueScreenView, it will provide you with several pieces of information and at first, it may seem confusing. However, the format is straightforward and it does highlight the important information to get you started.

The files or applications that caused the crash will be highlighted in red, giving you a good idea of where to start correcting the issue.

In this screenshot, we can see that on this specific minidump, there was an issue detected that affected three files; dxgmms2.sys, ntoskrnl.exe and watchdog.sys.

Further on the upper panel, we can see in the right column that there’s a section that tells us what caused the crash. In this image, we can see that the watchdog.sys caused the problem. This is a good starting point as you can now check Google or Bing, to see how this could become a problem and possible solutions.

We know that watchdog.sys is the potential cause, but what about dxgmms2.sys and ntoskrnel.exe? As those were the affected files, we need to find out what those are as well. So those will also need to be looked into. Doing a quick check on Google, we can see that dxgmms2.sys is related to the Windows DirectX drivers, while ntoskrnl.exe is the operating system kernel executable – responsible for keeping the operating system running.

Using this view of the Windows minidump file, we can deduce that the BSOD was likely caused by a graphics driver issue, which can typically be corrected by installing a newer version of the driver or reinstalling the current driver.

What If The Minidump File Shows A Hardware Error?

While driver issues are usually easily fixed, a BSOD that is a result of failed hardware is a different story. Such an example is the FAULTY_HARDWARE_CORRUPTED_PAGE error. Here, you would still use an application such as BlueSceenWindow to find the cause of the error. However, when a hardware error occurs, there’s not a magical fix that will correct this. For this specific error, we’re going to say that the result of this error was due to an installed memory module.

To figure out if this is the actual cause, we’d have to test the memory. There are several ways to do this; using a hardware memory checker or an application. Seeing how most people don’t have access to a physical memory checker, we’ll opt for the application route. Thankfully, Microsoft has included a memory diagnostics tool that has been included dating back to Windows 7. To use this, open up a run prompt and type “mdsched”.

You’ll have two options to choose from; Restart Now or Check for problems the next time you start my computer. If you choose the first option, be sure to save your work as Windows will close out.

Once your computer restarts, the memory checker will load and start checking your memory. Depending on how much memory you have installed, the process can take a while. While the test is running, you’ll see a progress bar and an overall status. Any errors that may be encountered will be displayed under the status section.

Once the test is completed, the memory test will boot into Windows. If there are no errors, you can conclude that your memory is not at fault.