How to Read Crash Dump Files in Windows (Step-by-Step)

When Windows crashes with a blue screen error, it automatically writes a dump file that records exactly what was happening in memory at the moment of the crash. Reading that file tells you the stop code, the faulty driver, and often the exact module that triggered the crash. This guide covers two real tools that actually work: WinDbg (Microsoft’s official debugger) and BlueScreenView (a lightweight Nirsoft utility). Both are free.

What Is a Windows Crash Dump File

Windows writes dump files to C:\Windows\Minidump by default after every BSOD. Each file carries:

• The stop code and its parameters
• A list of loaded drivers at crash time
• The processor context for the CPU that stopped
• Process and kernel context for the thread that triggered the crash
• The kernel-mode call stack

Minidump files (.dmp) are the compact version. They are easier to open and carry everything you need to identify the root cause.

Method 1: Read Crash Dump Files Using WinDbg

WinDbg is Microsoft’s official debugging tool. It reads all dump file formats including minidumps, kernel dumps, and complete memory dumps.

Step 1: Install WinDbg Preview

1. Open the Microsoft Store on your PC.
2. Search for WinDbg Preview or go directly to the Store listing.
3. Click Get and then Install.

WinDbg Preview is the modern version. Do not use the older WinDbg from the Windows SDK unless you specifically need it.

Step 2: Configure the Symbol Path

Without a symbol path, WinDbg cannot resolve function names and the analysis output will be mostly hexadecimal addresses with no context. Set it before opening any dump file.

1. Open WinDbg Preview as administrator (right-click > Run as administrator).
2. Click File > Settings > Debugging Settings.
3. In the Default symbol path field, enter:

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

4. Click OK.

The C:\Symbols part is a local cache folder. WinDbg downloads symbols from Microsoft’s servers the first time and caches them locally for faster future analysis. You can use any folder path you prefer.

Step 3: Open the Dump File

1. Click File > Start Debugging > Open Dump File.
2. Navigate to C:\Windows\Minidump.
3. Select the .dmp file you want to analyze and click Open.

If Windows is installed on a drive other than C:, check %SystemRoot%\Minidump for the correct path. You can also open compressed .cab or .zip archives containing dump files directly without extracting them first.

Step 4: Run the Verbose Analysis Command

Once the dump loads, type the following command in the command bar at the bottom of the window and press Enter:

!analyze -v

The -v flag runs verbose mode. Without it, the output is minimal. Analysis can take anywhere from a few seconds to a couple of minutes depending on file size and symbol download speed.

Step 5: Read the Bugcheck Analysis Output

After the command completes, scroll through the output and look for these specific sections:

• BUGCHECK_STR shows the stop code in a readable format, for example DRIVER_IRQL_NOT_LESS_OR_EQUAL or MEMORY_MANAGEMENT.
• MODULE_NAME identifies the specific driver or module that caused the crash. This is the key field. If it shows something like nvlddmkm, that points to an NVIDIA graphics driver issue.
• IMAGE_NAME gives the filename of the responsible module, for example ntoskrnl.exe, win32k.sys, or a third-party driver like aswSP.sys.
• FAILURE_BUCKET_ID provides a unique crash signature that groups similar crashes together and is useful for searching for known fixes.
• STACK_TEXT shows the call stack. Read it top to bottom. The top frame is where execution stopped. Look for third-party driver names in this stack since those are most likely the culprit.

If you remember the stop code from the blue screen itself, use Ctrl + F inside WinDbg to search the analysis output for that string directly.

Method 2: Read Crash Dump Files Using BlueScreenView

BlueScreenView by Nirsoft is faster to set up and better for quickly identifying the driver that caused a crash. It displays each dump file as a row, and the Caused By Driver column in the upper panel names the most likely culprit driver immediately on load.

Step 1: Download BlueScreenView

Go to https://www.nirsoft.net/utils/blue_screen_view.html and download one of two versions:

• Installer version: Click Download BlueScreenView with full install/uninstall support, run the setup file, and follow the prompts.
• Portable version: Click Download BlueScreenView (in Zip file), extract the archive, and run BlueScreenView.exe directly. No installation needed.

Step 2: Open BlueScreenView

Launch BlueScreenView. If it detects .dmp files at the default C:\Windows\MiniDump path, it loads them automatically. The upper panel lists every crash dump with its filename, crash date, stop code, and the driver involved.

Step 3: Change the Dump Folder If Needed

If BlueScreenView shows no files:

1. Press Ctrl + O to open Advanced Options.
2. Click Browse and navigate to your minidump folder.
3. Click OK.

Common alternate locations:

• C:\MiniDump
• C:\Windows\MEMORY.DMP (full memory dump)
• C:\Users\[Username]\AppData\Local\CrashDumps (for app crashes)

Step 4: Identify the Crashing Driver

Start with the upper panel. Click any dump file in the list and check these two columns without scrolling anywhere:

• Caused By Driver: The driver BlueScreenView has identified as the most likely cause. This is the first column to check.
• Bug Check String: The stop code for that specific crash, for example DRIVER_IRQL_NOT_LESS_OR_EQUAL or NTFS_FILE_SYSTEM.

For deeper confirmation, look at the lower panel. It shows all drivers and modules loaded at crash time. Drivers highlighted in pink are the ones whose memory addresses appear in the crash stack. These are directly involved in the crash.

If a third-party driver name appears in pink (anything that is not a core Windows system file), that driver is the primary suspect. Note the exact filename and search for the latest version from the manufacturer.

Method 3: Check and Fix Your Dump File Settings

If Windows is not generating dump files at all, or if you want a more detailed dump type for analysis, check these settings.

Step 1: Open Startup and Recovery Settings

1. Press Windows + R, type sysdm.cpl, and press Enter.
2. Click the Advanced tab.
3. Under Startup and Recovery, click Settings.

Step 2: Select the Right Dump Type

The Write debugging information dropdown controls what type of dump Windows creates. For most crash troubleshooting, use:

• Small memory dump (256 KB): Creates a minidump in C:\Windows\Minidump. Lightweight and works with both WinDbg and BlueScreenView. Best for routine BSOD analysis.
• Kernel memory dump: Captures kernel memory only. Larger than a minidump but more detailed. Useful when the minidump lacks enough stack context.
• Automatic memory dump: Windows decides the size dynamically. Good default for most systems.
• Complete memory dump: Captures all RAM. Can be several gigabytes. Use only when other dump types fail to reveal the cause.

Step 3: Verify the Dump File Path

The Dump file field shows where Windows saves the crash dump. A value of %SystemRoot%\Minidump means C:\Windows\Minidump on a standard install. If the path points to a drive with low disk space, Windows may silently skip writing the dump file. Change the path to a drive with at least 1 GB free.

Step 4: Disable Automatic Overwrite If Needed

For kernel memory dump, complete memory dump, and automatic memory dump types, Windows overwrites the previous file on each new crash. If you want to keep multiple dumps for comparison, uncheck Overwrite any existing file.

Small memory dump files are never overwritten. Windows appends a new dated file each time.

Step 5: Click OK

Click OK twice to apply. Changes take effect on the next system crash with no reboot required.

Method 4: Use Driver Verifier to Catch the Faulty Driver

Approximately 75% of blue screen errors on Windows trace back to driver issues. Driver Verifier runs in real time and applies stress tests to drivers to force a crash with a more specific stop code if a driver is misbehaving. Use it when dump file analysis points to a driver but you are not sure which one.

Step 1: Open Driver Verifier

1. Open Command Prompt as administrator.
2. Type verifier and press Enter.
3. The Driver Verifier Manager window opens.

Step 2: Configure Verifier Settings

1. Select Create standard settings and click Next.
2. On the next screen, select Select driver names from a list and click Next.
3. Click Load Driver Information.

The list shows all currently loaded drivers. Sort by Provider to separate Microsoft drivers from third-party ones. Check only the third-party drivers you suspect. Verifying fewer drivers at a time makes it easier to isolate the bad one.

If the minidump already named a specific driver via MODULE_NAME or IMAGE_NAME, check only that driver.

4. Click Finish and restart the PC.

Step 3: Trigger and Read the Verifier Crash

If a checked driver violates memory rules or behaves incorrectly, Windows forces an immediate crash with a highly specific stop code. Open WinDbg on the resulting dump file and run !analyze -v. The bugcheck analysis will now name the exact driver function that failed.

Step 4: Disable Driver Verifier After Testing

Driver Verifier causes crashes by design. Disable it after testing.

1. Open Command Prompt as administrator.
2. Type verifier /reset and press Enter.
3. Restart the PC.

If your system crashes at every boot with Verifier enabled, boot into Safe Mode, open Command Prompt, run verifier /reset, and reboot normally.

FAQs

Related Windows Error Fixes

• How to Fix ntkrnlmp.exe Blue Screen Error in Windows 10 and 11
• How to Fix Windows Blue Screen Error 0x000000000000010E After Hibernation
• How to Fix Blue Screen Error 0x0000003B (SYSTEM_SERVICE_EXCEPTION) in Windows