Fix Windows 10/11 Blue Screen (BSOD): Collect Minidumps & Analyze with WinDbg
Difficulty: Intermediate | Time Required: 30 minutesBlue Screens of Death (BSODs) can feel random and impossible to diagnose—until you collect the crash dump files Windows creates and read what they contain. This guide shows you how to (1) make sure Windows 10/11 is saving minidumps, (2) collect them correctly, and (3) analyze them using WinDbg so you can identify the likely faulty driver, hardware, or configuration issue.
The goal isn’t to become a kernel engineer—it’s to produce useful evidence you can act on (or share on WindowsForum.com for help).
Prerequisites
- Windows 10 or Windows 11 (any supported version; steps may vary slightly by UI)
- Administrator access
- A recent BSOD (or willingness to wait for the next one)
- Internet connection (for downloading WinDbg and symbols)
- Optional but helpful:
- A second PC/phone to view this guide if your system is unstable
- 1–2 GB free disk space (symbols can grow over time)
Step-by-Step: Ensure Windows is Creating Minidumps
Minidumps are small crash logs stored inC:\Windows\Minidump. They’re ideal for forum troubleshooting because they’re compact and easy to share.
1) Confirm crash dump settings (Windows 10/11)
- Right-click Start → System.
- Windows 11: you may need Settings → System → About.
- Select Advanced system settings (on the right side in many builds).
- Under Startup and Recovery, click Settings…
- In Write debugging information, select:
- Small memory dump (256 KB) (recommended for most users)
- Confirm the Small dump directory is set to:
%SystemRoot%\Minidump
- Check Automatically restart (optional).
- If you want time to read the BSOD screen, uncheck it.
- Click OK to apply.
2) Verify your page file isn’t disabled
Dump creation often requires a page file on the system drive.- Open System Properties again → Advanced tab.
- Under Performance, click Settings… → Advanced tab.
- Under Virtual memory, click Change…
- Ensure:
- Automatically manage paging file size for all drives is enabled
or - Your C: drive has a page file configured (System managed is fine).
- Automatically manage paging file size for all drives is enabled
- Click OK and reboot if prompted.
Step-by-Step: Find and Collect Minidumps
3) Locate the minidump files
- Open File Explorer
- Go to:
C:\Windows\Minidump
- Look for files like:
120123-12345-01.dmp
- You may not have had a BSOD since enabling minidumps.
- The crash may be too severe to write a dump (power loss/hardware lock).
- Storage cleanup tools may be removing them.
4) Copy dumps to a safe location (don’t work from C:\Windows)
- Create a folder like:
C:\BSOD
- Copy the
.dmpfiles fromC:\Windows\MinidumpintoC:\BSOD
5) Zip the dumps for sharing (recommended for forum posts)
- Select the
.dmpfiles inC:\BSOD - Right-click → Send to → Compressed (zipped) folder
- Name it something like:
Minidumps-Jan2026.zip
Step-by-Step: Install WinDbg (Preview) and Set Up Symbols
6) Install WinDbg from Microsoft Store
- Open Microsoft Store
- Search for WinDbg Preview
- Click Install
7) Configure the symbol path (critical for useful results)
Symbols translate raw memory addresses into readable function and driver names.- Launch WinDbg Preview
- Go to File → Settings (or the gear icon)
- Find Symbols settings and set the symbol path to Microsoft’s symbol server. A common, reliable path is:
srv*C:\Symbols*[Symbol information](https://msdl.microsoft.com/download/symbols)- Create the folder
C:\Symbolsif it doesn’t exist. - Apply/save settings.
Step-by-Step: Analyze a Minidump with WinDbg
8) Open the dump file
- In WinDbg Preview: File → Open dump file
- Select one
.dmpfromC:\BSOD - Wait for WinDbg to load it (status messages appear at the bottom/top)
9) Run the basic analysis command
In the command input at the bottom, type:!analyze -vPress Enter.
WinDbg will produce a verbose analysis including:
- BugCheck code (the BSOD “stop code”)
- Likely cause / “Probably caused by”
- Call stack and involved modules
10) Identify the likely driver/module
Look for these fields in the output:- BUGCHECK_CODE or BugCheck
- MODULE_NAME
- IMAGE_NAME
- Probably caused by
IMAGE_NAME: nvlddmkm.sys(NVIDIA graphics driver)IMAGE_NAME: amdkmdag.sys(AMD graphics driver)IMAGE_NAME: iaStorAC.sys(Intel storage/RST)IMAGE_NAME: Wdf01000.sys(often a framework involved; not always the true culprit)
11) Get more info about a suspicious driver
If the analysis points to a third-party.sys, run:lmvm drivernameExample:
lmvm nvlddmkmThis shows:
- Driver path
- Timestamp (useful for spotting outdated drivers)
- Company name
12) Check for common red flags in the output
As you read the analysis, watch for:- Very old driver timestamps (years old)
- Security/antivirus filter drivers
- Overclocking/monitoring tools (some hook deeply into the kernel)
- Storage and chipset drivers
- Repeated crashes with the same module across multiple dumps
Tips and Troubleshooting Notes
If no minidumps are being created
Try these checks:- Confirm Small memory dump is selected (Step 1).
- Ensure
C:\Windows\Minidumpexists and the system drive has space. - Re-enable the page file on C: (Step 2).
- Temporarily disable “cleanup” utilities that might delete dumps.
- Check Event Viewer:
- Start → search Event Viewer
- Windows Logs → System
- Look for BugCheck or Kernel-Power events around the crash time
If WinDbg output is mostly “Unknown” or missing names
- Your symbol path is wrong or symbols didn’t download.
- Re-check Step 7 and ensure WinDbg can access the internet.
- Try running:
Code:
.reload
!analyze -v
What to post on WindowsForum.com for help
When asking for help, include:- The zipped minidumps (
Minidumps-*.zip) - Your system specs (CPU, GPU, RAM, motherboard, PSU, storage)
- Windows version (Settings → System → About → OS build)
- What changed recently (drivers, updates, new hardware, overclocking)
- Any repeated stop codes or patterns (gaming, idle, sleep/wake, etc.
Safe next steps after identifying a driver
Depending on what you find:- Update the driver from the hardware vendor (GPU/Chipset/Storage)
- If the newest driver started the problem, try a clean rollback
- Remove or update low-level utilities (RGB tools, overclocking, “tuning” apps)
- Run basic integrity checks:
sfc /scannowDISM /Online /Cleanup-Image /RestoreHealth
- If dumps suggest memory corruption, consider memory testing (e.g., Windows Memory Diagnostic or MemTest86)
Conclusion
Collecting and analyzing minidumps turns BSOD troubleshooting from guesswork into evidence-based diagnosis. With WinDbg and proper symbols configured, you can quickly identify recurring drivers/modules, spot outdated kernel components, and provide meaningful data when asking the community for help. Even if you don’t “fix it” from the first dump, you’ll dramatically narrow the suspect list and speed up the solution.Key Takeaways:
- Minidumps (
C:\Windows\Minidump) are the fastest, most shareable BSOD evidence for Windows 10/11 troubleshooting. - WinDbg Preview + correct symbol path (
srv*C:\Symbols*[Symbol information](https://msdl.microsoft.com/download/symbols)) makes crash output readable and actionable. - Use
!analyze -vandlmvm <driver>to identify likely faulty drivers and confirm their details. - Multiple dumps + system details posted on the forum greatly increases the chance of an accurate diagnosis.
This tutorial was generated to help WindowsForum.com users get the most out of their Windows experience.