When Windows crashes with a blue screen of death, it flashes a stop code on screen for about two seconds before rebooting. That stop code is useful, but it tells you less than half the story. The real evidence — the crashed driver, the offending memory address, the exact call stack at the moment Windows gave up — lives inside the minidump file Windows quietly saved to your hard drive.
I’ve been fixing PCs professionally for 16 years, and I still run into clients who’ve Googled their stop code, tried three random driver updates, and ended up no closer to a solution. The missing step is almost always opening the dump file and letting Windows’ own debugging tools point directly at the culprit. Most tutorials make WinDbg look like something only kernel engineers should touch. It isn’t. You need exactly one command to get a useful answer out of it, and this guide walks you through every step.
By the end of this guide you’ll know how to find your minidump files, install and configure WinDbg, open a crash dump, run the analysis command, and understand what the output is telling you — even if you’ve never opened a debugger in your life.
Quick answer
To read a BSOD minidump with WinDbg, install WinDbg Preview from the Microsoft Store, open the latest file in C:\Windows\Minidump, wait for symbols to load, then run:
!analyze -vStart with the bug check code, MODULE_NAME, IMAGE_NAME, and PROCESS_NAME fields. If the result points to a third-party .sys driver, update or roll back that driver. If it points to ntoskrnl.exe, do not assume Windows itself is broken. That usually means a driver or hardware problem caused the Windows kernel to crash.
What does ntoskrnl.exe mean in a blue screen?
ntoskrnl.exe is the Windows kernel. If WinDbg lists ntoskrnl.exe as the crashed image, it usually means Windows was the part that crashed, not necessarily the part that caused the crash. In repair work, I treat ntoskrnl.exe results as a clue to look harder at RAM, storage, overheating, unstable drivers, BIOS issues, or power problems.
- Check whether the same third-party driver appears across multiple dumps.
- Test RAM with MemTest86.
- Check SSD/HDD health.
- Check CPU/GPU temperatures.
- Review recent driver, BIOS, or hardware changes.
- Consider PSU instability if crashes happen under load and point in different directions.
What Is a Minidump File?
Every time Windows encounters a fatal error — a kernel-mode crash that it can’t recover from — it stops everything, collects a snapshot of what was happening at that exact moment, and writes that snapshot to disk before rebooting. That snapshot is the minidump file.
Where Windows Stores Minidump Files
By default, Windows saves minidump files to C:\Windows\Minidump. Each file is named after the date and a sequence number, following the pattern MiniMMDDYY-NN.dmp. For example, Mini012506-01.dmp is the first dump generated on January 25, 2026. Windows preserves all previous dump files in that folder rather than overwriting them, so you can look back at a crash that happened weeks ago.
If the folder is empty or doesn’t exist, your system may not be configured to create small memory dumps. To enable it, open Run (Win+R), type SystemPropertiesAdvanced, and press Enter. Under Startup and Recovery, click Settings. In the Write debugging information dropdown, select Small memory dump (256 KB) and click OK. Windows will populate the folder after the next BSOD.
What a Minidump Contains
Despite being small — typically 256 KB to a few MB — a minidump packs in a surprising amount of diagnostic data:
- The bug check code (the stop code you see on the blue screen) and its four parameters
- A list of all kernel modules and drivers loaded at the time of the crash
- The call stack of the thread that was executing when the crash occurred
- Information about the active process at crash time
- A snapshot of processor registers and a portion of kernel memory
That call stack is the most valuable piece. It shows you the exact sequence of function calls — often including the name of the driver that made the fatal call — right up to the point of failure. Think of it as a time-stamped trail of footprints ending at the crime scene.
Why Minidumps Beat Stop Codes Alone
A stop code like DRIVER_IRQL_NOT_LESS_OR_EQUAL tells you the category of error but not which driver caused it. There are hundreds of drivers loaded on a typical Windows PC at any time. The minidump file narrows it down to one. That’s the difference between randomly updating drivers and fixing the right one on the first try.
Installing WinDbg
Microsoft makes WinDbg available in two flavors. The one you want in 2026 is WinDbg Preview — it has a modern interface, dark mode, and the same underlying engine as the classic version without the 1990s UI. Here’s how to get it installed and configured correctly.
Option 1: Microsoft Store (Recommended)
- Open the Microsoft Store on your Windows PC.
- Search for WinDbg Preview.
- Click Get or Install. The app is free.
- Once installed, launch it from the Start menu.
The Microsoft Store version updates automatically, which means you’ll always have the latest symbol handling improvements and support for current Windows 11 crash formats.
Option 2: Windows SDK
If your machine doesn’t have Store access (common in enterprise environments), you can install WinDbg through the Windows Software Development Kit. Download the SDK installer from Microsoft’s developer documentation site, run it, and on the feature selection screen check only Debugging Tools for Windows — you don’t need the rest of the SDK for dump analysis. This installs both the classic WinDbg and the newer 64-bit version to C:\Program Files (x86)\Windows Kits\10\Debuggers\.
Configuring the Symbol Path (Critical Step)
WinDbg needs symbol files to translate raw memory addresses into readable function and driver names. Without symbols, the output is mostly hex addresses, which are useless for diagnosis. Symbols are downloaded on demand from Microsoft’s public symbol server, so you need a working internet connection the first time you analyze a dump.
To set the symbol path in WinDbg Preview:
- Open WinDbg Preview.
- Go to File > Settings.
- In the Debugging settings panel, find the Symbol path field.
-
Enter the following path (replacing
C:\Symbolswith any folder you want to use as a local cache):SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols - Click OK.
The SRV* prefix tells WinDbg to use the symbol server protocol. The path before the second asterisk (C:\Symbols) is your local cache — once a symbol file is downloaded, WinDbg uses the cached copy instead of re-downloading it. The URL after the second asterisk is Microsoft’s public symbol server, which hosts symbols for all Microsoft components including the Windows kernel and built-in drivers.
You can also set this path from within the debugger command window at any time by typing:
.sympath SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols
Then reload symbols with .reload.
Opening Your First Dump File
With WinDbg installed and your symbol path configured, you’re ready to open a crash dump. This part is straightforward.
Step-by-Step: Loading the Dump
- Launch WinDbg Preview.
- Go to File > Open crash dump.
-
Navigate to
C:\Windows\Minidump. You may need to run WinDbg as Administrator if you get a permissions error accessing this folder. Right-click the WinDbg Preview icon and choose Run as administrator. - Select the
.dmpfile you want to analyze. For a recurring crash, start with the most recent file. - Click Open.
Waiting for Symbols to Load
After opening the dump, WinDbg will begin downloading symbol files from Microsoft’s server. The status bar at the bottom of the window shows progress. Depending on your internet speed and how many unique drivers were loaded at crash time, this can take anywhere from 30 seconds to a few minutes. Don’t rush it — running analysis before symbols finish loading gives you incomplete results.
You’ll see lines like SYMSRV: ntoskrnl.pdb - OK as individual symbol files complete. When the cursor returns to a blinking prompt in the command window at the bottom of the screen, symbols are ready.
Understanding the Initial Output
When the dump first opens, WinDbg prints a brief summary in the command window. It looks something like this:
Microsoft (R) Windows Debugger Version 10.0.27553.1000 AMD64
...
Loading Dump File [C:\Windows\Minidump\Mini012506-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols
...
Windows 11 Kernel Version 26100 MP (16 procs) Free x64
Built by: 26100.xxxxxx.amd64fre.ge_release
Machine Name:
Kernel base = 0xfffff803`12000000 PdbSig70: ...
...
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.That last line is your invitation. WinDbg already knows there’s a bug check to analyze — it’s just waiting for you to ask.
The Key Commands
You only need to know a handful of commands to get a complete picture of what caused a crash. The most important one does most of the work automatically.
!analyze -v: The Magic Command
In the command window at the bottom of WinDbg, type the following and press Enter:
!analyze -v
The ! prefix means this is a debugger extension command. analyze is WinDbg’s automated crash analysis engine. The -v flag stands for “verbose” — it outputs every field instead of just the summary. Always use -v. The extended output is what gives you actionable information.
The command runs for a few seconds, then produces several dozen lines of output. Here’s how to read the most important fields:
BugCheck Code
BUGCHECK_CODE: d1
This is the stop code in hexadecimal. d1 = DRIVER_IRQL_NOT_LESS_OR_EQUAL. WinDbg also prints the full name:
BUGCHECK_STR: DRIVER_IRQL_NOT_LESS_OR_EQUAL
The four parameters below it (Arg1 through Arg4) provide additional context. For a d1 crash, Arg1 is the memory address that was illegally referenced, Arg2 is the IRQL level at the time, and Arg4 is the address of the instruction that made the bad reference.
PROCESS_NAME
PROCESS_NAME: chrome.exe
This is the user-mode process that was running on the CPU at the time of the crash. It’s a useful clue, but be careful not to over-interpret it. A user-mode application like Chrome can’t directly cause a kernel crash — it can only trigger a crash by calling into a driver that has a bug. So chrome.exe here means Chrome was active, not necessarily that Chrome is the problem.
MODULE_NAME and IMAGE_NAME
MODULE_NAME: nvlddmkm
IMAGE_NAME: nvlddmkm.sys
These are the fields you care about most. IMAGE_NAME is the actual file name of the driver or module WinDbg has identified as the likely cause of the crash. In this example, nvlddmkm.sys is NVIDIA’s kernel-mode graphics driver. When you see a .sys file here, that driver is your target for the fix.
STACK_TEXT
The call stack shows the sequence of function calls leading up to the crash, listed from most recent to oldest:
STACK_TEXT:
fffff880`0a1e3b48 fffff880`0d4c1a3e : nvlddmkm+0x5a1a3e
fffff880`0a1e3b50 fffff800`0320e1c2 : nt!KeBugCheckEx
...
Read the stack from top to bottom. The top frame is where execution was when the crash fired. Each line to the right of the colon shows the module name and a hex offset within that module. When you see nvlddmkm+0x5a1a3e, that means execution was inside the NVIDIA driver at offset 5a1a3e bytes from the start of the module.
FAULTING_SOURCE_LINE and FAILURE_BUCKET_ID
If symbol files for third-party drivers are available (they usually aren’t for commercial drivers), WinDbg may also show you the exact source file and line number where the fault originated. More commonly, you’ll see a FAILURE_BUCKET_ID — a compact string like AV_nvlddmkm!unknown_function that Microsoft uses to group similar crashes together. This string is useful for searching online to see if others have reported the same crash pattern.
Other Useful Commands
| Command | What It Does |
|---|---|
lmvm modulename |
Shows version information for a specific module (e.g., lmvm nvlddmkm) |
.reload /f |
Forces a full symbol reload if something looks wrong |
k |
Prints the call stack again without re-running full analysis |
!lmi modulename |
Detailed module information including file path and timestamp |
Interpreting Common Results
The output of !analyze -v means different things depending on what crashed. Here’s how to read the most common scenarios you’ll encounter.
Driver Crash: MODULE_NAME Points to a .sys File
This is the most common finding in real-world crash analysis. When IMAGE_NAME shows a file ending in .sys, you’re looking at a kernel driver. Common examples:
- nvlddmkm.sys — NVIDIA display driver
- igdkmd64.sys — Intel integrated graphics driver
- amdkmdag.sys — AMD display driver
- ntfs.sys — Windows NTFS file system driver (may indicate disk corruption)
- tcpip.sys — Windows networking stack (often triggered by a network adapter driver)
If the .sys file belongs to a hardware vendor (graphics, audio, network), the fix is usually a driver update or rollback. If it belongs to Windows itself (ntoskrnl.exe, hal.dll), the crash is less commonly the OS itself and more often hardware — RAM, storage, or overheating — pushing a bad value into the kernel.
MEMORY_MANAGEMENT (0x0000001A)
When you see BUGCHECK_STR: MEMORY_MANAGEMENT, Windows has detected a serious inconsistency in its own memory management system. The most common cause is faulty RAM. Other contributors include a failing SSD/HDD, overclocking instability, or a severely corrupted Windows installation. Run a RAM test before doing anything else (covered in the next section).
DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1)
A driver tried to access memory at a CPU interrupt request level (IRQL) higher than it was allowed. This almost always points to a specific driver bug. The IMAGE_NAME field in the dump will name the offending driver. This is one of the most actionable stop codes — find the driver, update or remove it, and the crashes stop.
DRIVER_POWER_STATE_FAILURE (0x0000009F)
A driver failed to complete a power state transition within the required time — most often seen during sleep, hibernate, or wake cycles. The !analyze -v output for this stop code includes the blocked IRP (I/O Request Packet) and the physical device object of the offending stack, which narrows down exactly which device’s driver is hanging. USB devices, network adapters, and display drivers are the most frequent culprits.
PAGE_FAULT_IN_NONPAGED_AREA (0x00000050)
Windows tried to access a memory page that was supposed to be in physical RAM but wasn’t there. This points to either bad RAM, a driver that freed memory and then tried to use it, or storage issues causing data to get corrupted before it reaches the kernel. Check IMAGE_NAME first — if it’s a third-party driver, that’s your fix. If it’s a Windows system file, run memory and disk diagnostics.
SYSTEM_SERVICE_EXCEPTION (0x0000003B)
An exception occurred during a system service call. This stop code frequently appears in the output with a third-party driver name in the stack. It can also be triggered by a corrupt system file — running sfc /scannow from an elevated command prompt is worth doing alongside any driver fix.
ntoskrnl.exe as IMAGE_NAME
When the analysis points to ntoskrnl.exe (the Windows kernel itself), it usually means the kernel was executing when bad data arrived from a piece of hardware or a driver that’s no longer in the stack trace. This is the hardest result to act on directly. Focus on hardware — run MemTest86, check your storage, and look at temperatures. If you recently added hardware, start by removing it.
What to Do After You Find the Cause
The dump analysis gave you a name. Here’s what to do with it.
Driver Update or Rollback
If IMAGE_NAME identified a third-party driver, visit the hardware manufacturer’s website directly — not Windows Update — and download the latest driver for that device. Manufacturer downloads are often more current than what Windows Update distributes.
If the crashes started immediately after a Windows Update or a driver update you installed yourself, a rollback may be faster than waiting for a fixed version. In Device Manager, right-click the device, choose Properties, go to the Driver tab, and click Roll Back Driver. If the button is grayed out, Windows didn’t save the previous driver version.
For graphics drivers specifically, I recommend using DDU (Display Driver Uninstaller) in Safe Mode to do a clean removal before installing the fresh driver. Partial driver installations are a common source of recurring BSOD crashes even after an “update.”
If you need help identifying which physical device a .sys file belongs to, see our guide on identifying unknown drivers in Windows.
Test RAM with MemTest86
If the crash pointed to MEMORY_MANAGEMENT, PAGE_FAULT_IN_NONPAGED_AREA, or ntoskrnl.exe, run MemTest86 before anything else. Download the free ISO from the MemTest86 website, burn it to a USB drive, boot from it, and let it run at least two full passes — ideally overnight. A single bit error is enough to cause random BSODs. If MemTest finds errors, the RAM needs to be replaced or the failing DIMM removed.
If you have multiple RAM sticks, test them one at a time to isolate which module is failing.
Disk Health Check
Crashes involving ntfs.sys, Ntfs.sys, or file system errors may indicate storage problems. Run a SMART check using CrystalDiskInfo (free) to see the health status of your drives. Also run a Windows disk check from an elevated command prompt:
chkdsk C: /f /r
Schedule it for the next restart when prompted. The /r flag scans for bad sectors, which can take an hour or more on a large drive. For SSDs, also check the manufacturer’s diagnostic tool — Samsung Magician, Crucial Storage Executive, and WD Dashboard all have built-in health tests.
Check System Temperatures
Thermal throttling and heat-induced hardware failure are underappreciated causes of BSOD crashes. Download HWiNFO64 and run it while under load (gaming, video rendering, or a stress test). If CPU temperatures are consistently above 95°C or GPU temperatures above 90°C, your cooling system needs attention before any software fix will stick.
When It Points to Hardware Failure
If you’ve updated drivers, passed RAM tests, and confirmed your storage is healthy, but crashes continue with the same stop code, you’re likely looking at a hardware problem. Persistent WHEA_UNCORRECTABLE_ERROR (0x00000124) crashes, for example, often indicate a failing CPU, a dying motherboard, or power delivery issues. At that point, the diagnostic work shifts from software tools to hardware swapping — and a bench test with known-good components.
For guidance on diagnosing hardware-level failures, see our article on common PC hardware failure symptoms.
Quick Alternative: BlueScreenView
If the idea of typing commands into a debugger window makes you uncomfortable, NirSoft’s BlueScreenView is a legitimate alternative for basic crash analysis. It’s free, requires no installation, and doesn’t need a symbol server connection.
What BlueScreenView Does
BlueScreenView automatically scans your C:\Windows\Minidump folder and displays all your crashes in a clean table. For each crash you’ll see the dump filename, date and time, bug check code, bug check string, and — critically — the name of the driver that most likely caused the crash in a “Caused By Driver” column. Drivers highlighted in pink in the lower pane are the ones whose code addresses appeared in the crash stack.
When BlueScreenView Is Enough
For the majority of driver-caused crashes, BlueScreenView is sufficient. If you open it and immediately see nvlddmkm.sys or rtl8188ce.sys highlighted across multiple crashes, you have your answer without running a single debugger command. Download it from the NirSoft website, run the executable, and read the results directly.
When WinDbg Is Still the Better Choice
BlueScreenView has real limitations. Its driver detection algorithm is heuristic — it’s making an educated guess about which driver caused the crash based on what was in the stack, but it can be wrong. For complex crashes where multiple drivers appear in the stack, or for crashes where IMAGE_NAME points to a Windows system file, WinDbg’s !analyze -v output gives you far more context. WinDbg also handles newer dump formats more reliably and gives you access to every detail in the dump — not just the summary columns BlueScreenView displays.
My recommendation: start with BlueScreenView for a quick read. If the culprit is obvious, fix it. If you’re still guessing after looking at BlueScreenView’s output, open the same dump in WinDbg and run !analyze -v for the full picture.
Conclusion
Reading a BSOD minidump file isn’t as intimidating as it looks. The process comes down to four steps: find the dump in C:\Windows\Minidump, open it in WinDbg with the symbol server configured, run !analyze -v, and read IMAGE_NAME to identify the culprit. The entire workflow takes less than five minutes once you’ve done it once.
The difference between randomly trying fixes and targeted troubleshooting is the information in that dump file. After 16 years of working on other people’s machines, I can tell you that the times I’ve spent an hour chasing the wrong driver have almost always been times when I skipped the dump analysis and went straight to guessing. The dump doesn’t lie. Stop codes are clues; minidumps are evidence.
If you’re dealing with crashes that WinDbg points to hardware rather than software, read our guide on how to diagnose RAM problems for the next steps, or our overview of common Windows blue screen error codes for a reference on every stop code you’re likely to encounter.
BSODs with no clear driver cause? Random BSODs — especially under load — are one of the classic 12 PSU failure symptoms every tech should know. If your minidumps point in different directions each time, suspect the PSU before the RAM or drivers.