A blue screen names a stop code, not a culprit. The dump file behind it does name the driver, and reading it takes ten minutes with the right tool.
Open the **.dmp** file in **WinDbg** and run **!analyze -v**. The lines `MODULE_NAME` and `IMAGE_NAME` name the faulting driver; the stop code alone is only a category.
A minidump of a few hundred kilobytes is written to the Windows folder by default. Automatic memory dump gives more context but takes longer to write on a slow disk.
%SystemRoot%\inidumpMatch the dump timestamp with what you installed or plugged in that day. A dump written minutes after a driver update is a short investigation.
WinDbg opens a dump directly and sets the symbol path. The first analysis can take a minute while symbols download; a second run is instant.
windbg -z %SystemRoot%\inidump\30124-12345-01.dmpThe analyze command prints the stop code, the faulting module and a suggested cause. Read MODULE_NAME and IMAGE_NAME first; everything above is context.
!analyze -vA module under system32 is usually a Microsoft component reacting to something else, while a vendor name points at a real cause. Look one frame down the stack for the caller.
kbUpdate, roll back or remove that driver, then watch whether a new dump appears. Changing five components at once makes the next dump useless.
Normal. The kernel caught the fault; the caller below it in the stack is the real suspect.
Dump writing is disabled or the page file is too small. Enable it and set the page file to system managed.
No internet or a proxy. The module names still appear, only the line numbers do not.
Disable automatic restart on system failure to see the stop code first.
No. The Store version runs standalone and only needs the dump file.
Yes, but it contains memory content. Share it only with the vendor you trust.
Nothing on the system changes. WinDbg is read-only with dumps; uninstall it when the investigation is finished.
Free · no account needed · tracks your progress