When a Windows 11 machine blue-screens, the question on everyone’s mind is the same: what caused it? The stop code on the blue screen is rarely enough to tell you. SYSTEM_SERVICE_EXCEPTION, IRQL_NOT_LESS_OR_EQUAL, DRIVER_POWER_STATE_FAILURE — those are symptoms, not causes. The actual answer is sitting on the disk in a file called a minidump, and Windows writes a fresh one every time it crashes. You just have to know how to read it.
The good news: you don’t need a debugger background to find the culprit. Microsoft’s free WinDbg tool, fed a couple of well-chosen commands, will name the offending module in a few minutes.
Where Windows 11 stores the dump
By default, every blue screen on a modern Windows install produces a small kernel memory dump (around 1 MB) in:
C:\Windows\Minidump\The filenames are timestamped (for example 052026-12345-01.dmp) and you should see one new file per crash event. If the folder is empty after a crash, dump generation was likely disabled. Open System Properties → Advanced → Startup and Recovery → Settings and confirm that “Write debugging information” is set to at least Small memory dump (256 KB), with the dump directory pointing at %SystemRoot%\Minidump.
You don’t have to do the analysis on the same machine that crashed — in fact, it is usually better not to. Copy the .dmp off to a stable workstation and open it there.
Step 1: install WinDbg
WinDbg is Microsoft’s official kernel debugger. The current release is a Microsoft Store app simply called WinDbg (formerly “WinDbg Preview”). Install it from the Store on the analysis machine. The legacy version that ships inside the Debugging Tools for Windows SDK works too, but the Store app is faster to install and gets updates automatically.
Step 2: point WinDbg at Microsoft’s symbol server
Symbols are the dictionary that translates raw memory addresses inside the dump back into function and module names. Without them, !analyze -v can’t tell you anything useful. You only have to set this up once.
In WinDbg: File → Settings → Debugging settings → Symbol path. Paste:
srv*C:\Symbols*https://msdl.microsoft.com/download/symbolsThat tells WinDbg to use C:\Symbols as a local cache and to download any missing symbol files from Microsoft on demand. The first dump you analyze will be slow as it pulls down a few hundred MB of OS symbols; every dump after that reuses the cache.
Step 3: open the minidump
From WinDbg: File → Start debugging → Open dump file, then point at the .dmp from C:\Windows\Minidump\. You will see a wall of output as WinDbg loads symbols. Wait for the prompt at the bottom to settle on kd>.
Step 4: run !analyze -v
This single command does most of the heavy lifting. In the command bar at the bottom of the WinDbg window, type:
!analyze -vand press Enter. WinDbg will spend 10–60 seconds inspecting the dump and then print a verdict block that looks something like this:
*******************************************************************************
* Bugcheck Analysis *
*******************************************************************************
SYSTEM_SERVICE_EXCEPTION (3b)
...
BUGCHECK_CODE: 3b
BUGCHECK_P1: c0000005
PROCESS_NAME: TheCulpritApp.exe
MODULE_NAME: somefilter
IMAGE_NAME: somefilter.sys
FAILURE_BUCKET_ID: 0x3B_c0000005_somefilter!UnknownThe fields that matter most:
- BUGCHECK_CODE — the same stop code that was on the blue screen (e.g.
3b=SYSTEM_SERVICE_EXCEPTION). - MODULE_NAME / IMAGE_NAME — the binary that was running on the CPU when the crash happened. This is your prime suspect.
- PROCESS_NAME — the user-mode process that was active at the time. Especially useful when the failing module turns out to be a third-party filter hooked into a specific application.
Step 5: identify the vendor behind the module
A name like somefilter.sys is rarely enough on its own — you need to know whose product owns it. Ask WinDbg for the loaded module’s verbose details:
lm kv m somefilterWinDbg prints the company name, product name, and file version pulled straight from the binary’s resource header:
Image path: \??\C:\Program Files\SomeVendor\SomeProduct\somefilter.sys
Image name: somefilter.sys
Timestamp: ...
CompanyName: Some Vendor, Inc.
ProductName: Some Product
FileVersion: 4.2.1.0That is the answer you came for: a real product name and version number. Now you know which installed application owns the failing component.
When the dump points at a Windows module, not a third-party one
Sometimes !analyze -v blames a generic Windows binary like ntoskrnl.exe, ntfs.sys, or win32kfull.sys. That usually means Windows itself was on the CPU when things went sideways, but it was probably called by someone else. Look at the call stack:
kband read it from the bottom up. The first non-Microsoft module that appears in the stack — typically a name you don’t recognize that belongs to an installed product — is your real culprit. The same lm kv m <name> trick will identify the vendor.
Also pay attention to PROCESS_NAME. If five separate dumps all list the same user-mode .exe in PROCESS_NAME, that application is at minimum present at every crash, even if its name doesn’t appear directly in the faulting module list. That is a strong signal worth investigating.
Confirming across multiple dumps
One dump is suggestive; several are conclusive. If a workstation has been crashing repeatedly, gather every .dmp from C:\Windows\Minidump\ and run !analyze -v on each. A consistent suspect across multiple dumps is dramatically more reliable than reading a single dump in isolation, and it protects you against chasing a coincidental fault.
It also helps to keep the FAILURE_BUCKET_ID from each dump. Microsoft uses these buckets to group similar crashes, and if every dump lands in the same bucket, you are almost certainly looking at one repeatable bug rather than a flaky hardware ghost.
What to do once you have a name
Knowing the culprit narrows the fix to a handful of next steps, in order of escalation:
- Update the vendor’s software. Driver-level bugs are routinely patched. Pull the latest installer from the vendor and reinstall.
- Check Windows Update. If the failing module is a Microsoft component, an outstanding cumulative update may already contain the fix.
- Uninstall or disable as a test. If updating doesn’t help, remove the offending application for a few days. A stable uptime after removal confirms the diagnosis.
- Open a support case with the vendor, and bring the minidump. The
!analyze -voutput is exactly what their tier-two engineers will ask for.
A quick note on hardware vs. software
If !analyze -v consistently names different modules across multiple dumps, or if the bugchecks are all over the map (one WHEA_UNCORRECTABLE_ERROR, one MEMORY_MANAGEMENT, one KERNEL_DATA_INPAGE_ERROR), software is rarely the cause. That pattern usually points at failing RAM, a dying disk, or a marginal power supply. Run mdsched.exe for memory, check SMART on the system drive, and reseat or swap components before you go any further down the software path.
Bottom line
Every Windows 11 blue screen leaves a forensic trail in C:\Windows\Minidump. With WinDbg and Microsoft’s public symbol server, a proper root-cause analysis is a five-minute exercise: open the .dmp, run !analyze -v, and read off the offender. There is no need to guess, reinstall Windows, or live with a flaky machine.
If you are dealing with a recurring blue screen and would rather not wade through a kernel debugger yourself, drop us a line or call 970-282-8838 and we will pull the dump apart for you.