Blue Screen on Windows? How to Find the Exact Driver That Caused It

Your PC throws a Blue Screen of Death (“Your PC ran into a problem and needs to restart”) and you want it to stop. Before you reinstall Windows or buy RAM:

Why most advice is wrong: the top search results push registry cleaners, antivirus scans, and “just update Windows.” But Microsoft’s own crash analysis attributes roughly 70% of stop errors to third-party driver code, about 10% to hardware, only 5% to Microsoft code, and 15% unknown (the memory was too corrupted to tell). In other words, the single most likely cause is a specific driver — and Windows already saved a file that names it. The correct approach is to read that file, not to guess.

Step 1: Make sure Windows is saving a crash dump

1. Win + R → sysdm.cpl → Advanced tab → Startup and Recovery → Settings.
2. Under Write debugging information, choose Automatic memory dump (the default). Dumps are written to %SystemRoot%\MEMORY.DMP and mini-dumps to %SystemRoot%\Minidump.
3. Leave Automatically restart ticked; let the next crash happen so a fresh dump is captured.

Step 2: Note the stop code — it narrows things fast

The blue screen shows a stop code (e.g. DPC_WATCHDOG_VIOLATION). Several have a documented, code-specific fix you can try before deep analysis:

Stop code	Most common cause	First fix
SYSTEM_SERVICE_EXCEPTION (c000021a)	Corrupted system files	Run sfc /scannow
NTFS_FILE_SYSTEM (0x24)	NTFS corruption / bad sectors	Run chkdsk (disk check)
PAGE_FAULT_IN_NONPAGED_AREA (0x50)	Bad sector or faulty driver	chkdsk /f /r + update drivers
DPC_WATCHDOG_VIOLATION (0x133)	A driver not finishing in time (often SSD/SATA firmware or an old driver)	Update storage/chipset drivers

This already beats the one-size-fits-all “reinstall Windows” answer. If the crashes continue, name the driver directly:

Step 3: Read the dump to name the faulting driver

1. Install WinDbg — it ships with the Windows SDK (“Debugging Tools for Windows”); the modern WinDbg is also in the Microsoft Store.
2. Open WinDbg → File → Open dump file → select C:\Windows\MEMORY.DMP (or a file from \Minidump).
3. Point it at Microsoft’s public symbol server so it can resolve names. In the command box:

   .sympath srv*C:\symbols*https://msdl.microsoft.com/download/symbols
   .reload

4. Run the analyzer:

   !analyze -v

5. Read the output: MODULE_NAME / IMAGE_NAME and the STACK_TEXT name the driver or .sys file that triggered the crash (e.g. nvlddmkm.sys = NVIDIA, rt640x64.sys = Realtek NIC).

Step 4: Fix the named driver

Once you have the .sys name:

• Update it from the hardware maker’s site (GPU, network, storage, chipset) — not just Windows Update.
• If the crash started right after a driver update, roll it back: Device Manager → the device → Properties → Driver → Roll Back Driver.
• If you can’t identify which driver is misbehaving, run Driver Verifier (verifier) to stress-test third-party drivers — but only with a way to boot into Safe Mode, since it will bug-check on the offender.

FAQ

Do I need to be a developer to use WinDbg? No. You only need the one !analyze -v command and to read the driver name it prints. You’re not debugging code, just identifying a culprit.

It says the dump is corrupt / no dump was created. Confirm Step 1 settings, ensure your page file is on C: and large enough, and that you have free disk space. Then wait for the next crash.

Could it still be hardware? Yes — ~10% are hardware. If !analyze keeps blaming different random drivers, test your RAM (Windows Memory Diagnostic) and check drive SMART health. Constant 100% disk pressure can also masquerade as instability — see 100% disk usage.

Sources: Microsoft Learn — Advanced troubleshooting for Stop errors / Blue Screen, Microsoft Learn — Stop error / bug check code reference