Blue Screen on Windows? Read the Stop Code and Investigate the Driver

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 a crash dump may provide evidence. Read it alongside recent changes and diagnostics; a named module can be where corruption surfaced rather than the original cause.

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	What it indicates	Useful next check
SYSTEM_SERVICE_EXCEPTION (0x3B)	An exception while running a system service routine	Inspect the dump’s exception and stack; investigate implicated drivers and memory corruption
WINLOGON_FATAL_ERROR (0xC000021A)	A critical user-mode subsystem failure	Use the recovery/error details to investigate system files, updates or software changes
NTFS_FILE_SYSTEM (0x24)	An NTFS file-system failure	Preserve data and check storage health and the dump before repair writes
PAGE_FAULT_IN_NONPAGED_AREA (0x50)	Invalid system-memory access	Inspect the dump and recent driver/hardware changes; do not assume a bad disk sector
DPC_WATCHDOG_VIOLATION (0x133)	A DPC/interrupt timing watchdog violation	Review the dump and relevant driver/firmware timing

The code narrows the investigation; it does not prove a single cause. In particular, 0x3B and 0xC000021A are different bug checks.

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 identify modules involved in the crash, which are clues rather than proof of the original cause (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.

The BSOD happens at boot, not during use. Boot-time stop errors are a different category (storage driver or stuck update) — see INACCESSIBLE_BOOT_DEVICE (0x7B).

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