How to Read Minidump Files With WinDbg on Windows 11

Quick fix: Install WinDbg from the Microsoft Store (free), open the minidump file at C:\Windows\Minidump\*.dmp, set the symbol path to srv*C:\symbols*https://msdl.microsoft.com/download/symbols, then run !analyze -v to get the bug check code, faulting driver, and call stack.

Your PC just blue-screened. After reboot, Windows asks if you want to report the crash. Behind the scenes, Windows wrote a small memory dump file to C:\Windows\Minidump\. Each file is ~1 MB and contains the kernel stack at the moment of the crash — enough to identify the faulting driver or kernel module. WinDbg reads it and tells you exactly which driver caused the BSOD.

What causes this

When Windows blue-screens, the kernel dumps a small portion of memory (the stack of the crashing thread plus loaded driver list) to C:\Windows\Minidump\. The file is named with a timestamp: 050926-12345-01.dmp. To make the dump useful, you need symbols — debug information files (PDB) that map memory addresses to function names. Microsoft hosts public symbols for Windows components on a public server; WinDbg downloads them on demand.

Two prerequisites for minidump generation: (1) the system must be configured to write minidumps (Settings → System → About → Advanced system settings → Startup and Recovery → Write debugging information = Small memory dump (256 KB)), and (2) the page file must be enabled on C:. Both are default on Windows 11.

Method 1: WinDbg from Microsoft Store (recommended)

The modern path. The Store version is the same as the Windows SDK’s WinDbg Preview, with a cleaner ribbon UI.

1. Open Microsoft Store. Search for WinDbg.
2. Install. Pin to Start.
3. Launch WinDbg. The Home ribbon shows Start debugging.
4. Click Open dump file. Browse to C:\Windows\Minidump\ and pick the most recent .dmp.
5. Once loaded, set the symbol path: click File → Settings → Debugging settings → Symbol path. Paste this exact string:

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

   This caches symbols under C:\symbols on first download.

6. Click Save. In the command bar at the bottom, type:

   !analyze -v

   Press Enter.

7. WinDbg downloads symbols (5–10 MB) and produces a detailed analysis. Look for:
   • BugCheck: the four-digit hex code (e.g., 0x0000007E)
   • BUGCHECK_STR: text name (e.g., SYSTEM_THREAD_EXCEPTION_NOT_HANDLED)
   • MODULE_NAME: faulting driver (often the bad guy)
   • STACK_TEXT: function call chain leading up to the crash

The MODULE_NAME is your starting point — if it’s a third-party driver, that’s your prime suspect. Update or roll back that driver.

Method 2: BlueScreenView for quick triage

For when you want a faster overview without WinDbg’s learning curve.

1. Download BlueScreenView from NirSoft (nirsoft.net/utils/blue_screen_view.html) — free.
2. Extract the ZIP and run BlueScreenView.exe (no install needed).
3. The tool auto-scans C:\Windows\Minidump\ and lists every BSOD found.
4. Click a row. The lower pane shows the loaded drivers at crash time. Drivers highlighted in red are likely the cause.
5. Right-click a driver entry → Properties. Shows the file path, version, and product name — useful for confirming which third-party software installed it.
6. Cross-reference with WinDbg’s !analyze -v output for confirmation.

BlueScreenView is faster but less detailed than WinDbg. Use it for first-pass triage when you have multiple dumps to scan.

Method 3: WhoCrashed for plain-language analysis

For users who want WinDbg-level depth without the command-line interface.

1. Download WhoCrashed from Resplendence Software (free for home use).
2. Install. On first launch, it asks to download Microsoft’s Debugging Tools — agree.
3. Click Analyze. The tool scans C:\Windows\Minidump\ and produces a report in plain English.
4. Each crash entry includes: date, bug check code, the likely driver, and a confidence rating.
5. Click a crash to expand its full report — same data WinDbg shows from !analyze -v, but pre-formatted.
6. Export the report as a text file via Save → Save as text file. Useful for support tickets.

WhoCrashed is the right choice if you’re writing a support ticket and the technician wants the analysis without you needing to learn WinDbg.

How to verify the fix worked

• WinDbg’s !analyze -v output includes a Probably caused by: line — typically points to a specific driver file (nvlddmkm.sys, iaStorA.sys, etc.).
• The output also lists a FAILURE_BUCKET_ID — useful for searching Microsoft KB or web forums for known fixes.
• Check C:\Windows\Minidump\ after applying the fix (driver update, hardware change). If no new .dmp files appear after a week of normal use, the BSOD is resolved.

If none of these work

If WinDbg shows nt!KeBugCheckEx as the only meaningful stack entry and the MODULE_NAME is just nt (the Windows kernel), the dump didn’t capture enough context. Two ways to get a richer dump: (1) increase dump size to Kernel memory dump via Settings → System → About → Advanced system settings → Startup and Recovery → Write debugging information. This produces ~1–2 GB files in C:\Windows\MEMORY.DMP instead of the small minidumps. (2) Enable Driver Verifier on suspect drivers (verifier from Run dialog) so the next crash captures more detail at the cost of slower runtime. For chronic BSODs where no driver is consistently identified, the cause is usually hardware: faulty RAM (run mdsched.exe), failing SSD (check SMART data via CrystalDiskInfo), or overheating (check temps in BIOS or via HWiNFO).

Bottom line: WinDbg + !analyze -v + Microsoft’s public symbol server reads minidumps and identifies the faulting driver in about a minute once symbols are cached. BlueScreenView is the fast triage alternative.