Every blue screen leaves behind a witness: a dump file containing the exact state of Windows at the moment of the crash. Most people never look at theirs, which is a shame — because with WinDbg and one command, that dump will usually name the driver that killed your system. No more guessing, no more updating drivers at random.

This guide walks you through the whole process on Windows 11 24H2: installing WinDbg, opening a dump, running the analysis, and reading the results like someone who does this for a living.

Why this happens

  • You need this skill because blue screens name drivers inconsistently. The on-screen message sometimes shows the culprit .sys file, but often it just shows ntoskrnl.exe — the Windows kernel, which is never actually at fault. The dump tells the real story.
  • Minidumps are small and automatic. Windows writes one to C:\Windows\Minidump after every crash by default. They’re tiny, and each one is a separate data point.
  • Patterns across multiple dumps beat single crashes. One dump might implicate a driver unfairly; three dumps all pointing at the same driver is a conviction.
  • WinDbg is the official tool. Third-party “BSOD viewers” exist, but WinDbg reads Microsoft’s symbol server, giving you accurate function names instead of raw addresses.
  • Windows 11 24H2 changed nothing fundamental here. The process is the same as 23H2 — install, set symbols, open dump, analyze. If anything, the Store version of WinDbg is more polished than ever.
  • Knowing the culprit focuses your fix. Updating the one guilty driver beats reinstalling every driver on the system and hoping.

How to fix it

Work through these in order — each step builds on the last.

Fix 1: Install WinDbg from the Microsoft Store

Get the modern version, not the ancient SDK one.

  1. Open the Microsoft Store and search for WinDbg.
  2. Install the app published by Microsoft (the modern WinDbg with the dark interface).
  3. Launch it once so it creates its settings and cache folders.
  4. No additional SDK or driver kit is needed for basic dump analysis.
  5. If the Store is blocked on your machine, the same app is available as a direct download from Microsoft’s developer pages.

Fix 2: Make sure dumps are actually being written

No dumps, nothing to analyze.

  1. Press Windows + R, type sysdm.cpl, and press Enter.
  2. Go to the Advanced tab and click Settings under Startup and Recovery.
  3. Under Write debugging information, select Small memory dump (256 KB) — this gives you minidumps without eating disk space.
  4. Confirm the Small dump directory is %SystemRoot%\Minidump.
  5. Make sure Automatically restart is ticked if you want dumps written reliably, and click OK.

Also verify your page file exists on the system drive (Performance Settings > Advanced > Virtual memory) — Windows needs it to stage the dump during a crash. If your laptop crashes but no dump appears, our automatic restart guide covers related settings.

Fix 3: Configure the symbol path

Symbols translate raw memory addresses into human-readable function names. Without them, analysis is gibberish.

  1. In WinDbg, go to File > Settings > Debugging settings.
  2. Find the Symbol path field and enter SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols.
  3. This tells WinDbg to download symbols from Microsoft’s server and cache them in C:\Symbols.
  4. The first analysis downloads several hundred megabytes — be patient and stay connected.
  5. Subsequent analyses reuse the cache and run much faster.

Fix 4: Open a dump and run the analysis

This is the core skill — one file, one command.

  1. In WinDbg, choose File > Open dump file and navigate to C:\Windows\Minidump.
  2. Pick the most recent .dmp file (sort by date).
  3. When it loads, you’ll see a prompt — type !analyze -v into the command box at the bottom and press Enter.
  4. Wait for the analysis to complete (first run is slow due to symbol downloads).
  5. Read the output: focus on BUGCHECK_STR (the stop code), PROCESS_NAME (what was running), and IMAGE_NAME / MODULE_NAME (the blamed driver).

That IMAGE_NAME line is usually your answer. If it says ntoskrnl.exe, don’t stop there — scroll to the stack trace below for the real driver.

Fix 5: Read the stack trace for the true culprit

When the blamed module is the kernel itself, the stack reveals who called it.

  1. In the !analyze -v output, find the STACK_TEXT section.
  2. Read it bottom-to-top: it’s the chain of function calls leading to the crash.
  3. Look for third-party .sys names in the stack (anything that’s not ntoskrnl, hal, or win32k).
  4. Common tells: nvlddmkm.sys (NVIDIA), Netwtw12.sys (Intel Wi-Fi), rtkvhd64.sys (Realtek audio).
  5. Google the exact driver filename plus “blue screen” to confirm it’s a known problem driver before acting.

For example, a MEMORY_MANAGEMENT crash whose stack shows a storage filter driver points you at a very different fix than one showing the GPU driver. Our MEMORY_MANAGEMENT guide walks through what to do once you’ve identified the suspect.

Fix 6: Compare multiple dumps for a pattern

One dump is a hint; three dumps are evidence.

  1. Open each recent minidump in WinDbg and run !analyze -v on all of them.
  2. Note the IMAGE_NAME and stop code for each.
  3. If the same driver appears in most crashes, that’s your target — update, roll back, or remove it.
  4. If every dump blames something different, suspect RAM (run mdsched.exe) or a failing drive, not drivers.
  5. If dumps blame ntoskrnl.exe with empty stacks, check for overheating — thermal crashes corrupt state randomly.

Fix 7: Use additional commands for stubborn cases

A few extra commands for when !analyze -v isn’t conclusive.

  1. Run lmvm <drivername> (e.g., lmvm nvlddmkm) to see the driver’s version, path, and timestamp — an ancient timestamp means an outdated driver.
  2. Run !thread to see what the crashing thread was doing.
  3. Run .ecxr to switch to the exception context record for more detail on the exact fault.
  4. Check !sysinfo machineid to confirm the OS build — some stop codes are build-specific bugs fixed by updates from the Microsoft Update Catalog .
  5. Save your notes: WinDbg lets you copy the whole analysis to a text file for forum posts or your own records.

Closing

Reading dump files sounds intimidating until you do it once — then it becomes the fastest part of any blue-screen investigation. Install WinDbg, set the symbol path, open the newest minidump, run !analyze -v, and let the evidence point at the driver. You’ll fix crashes in minutes that used to take days of blind driver updates, and you’ll never again have to guess what a blue screen meant.

Frequently asked questions

What is WinDbg and is it free?
WinDbg is Microsoft’s official debugger for analyzing Windows crash dumps, and it’s completely free from the Microsoft Store. The modern WinDbg (sometimes called WinDbg Preview) has a clean interface and works on Windows 11 24H2 without any extra setup beyond installing it.
Where are blue screen dump files stored?
Small minidumps live in C:\Windows\Minidump (one per crash, ~a few hundred KB). Full memory dumps are at C:\Windows\MEMORY.DMP but can be gigabytes. For most troubleshooting, the minidumps are all you need.
Do I need programming knowledge to use WinDbg?
No. The !analyze -v command does the heavy lifting — it reads the dump and tells you the stop code, the likely culprit driver, and the crashing call stack in plain-ish language. You just need to know how to open the file and run that one command.
What if there are no dump files after a blue screen?
Check Settings > System > About > Advanced system settings > Startup and Recovery > Settings, and make sure ‘Write debugging information’ isn’t set to None. Also confirm the paging file is on the system drive and large enough — dumps can’t be written without one.