Blue Screen of Death: How to Read One and Find the Driver

Updated: October 2026

The blue screen is black now, and has been since Windows 11 version 24H2. The colour is the least useful thing on it either way: the stop code and the faulting module are the only parts worth writing down, and everything else you need is in a dump file and the event log. This guide covers what the screen tells you, where the evidence lives, how to read it, and the recovery feature that is switched off on every managed fleet by default.

TL;DR

• Microsoft's own split: 70% of crashes are third-party driver code, 10% hardware, 5% Microsoft code.
• Write down the stop code, not the colour. The screen is black on 24H2 and later.
• Minidumps are kept, MEMORY.DMP is overwritten. Check %SystemRoot%\Minidump first.
• Quick Machine Recovery is off by default on domain-joined and managed devices.

It Is a Black Screen Now

Microsoft renamed the consumer page to "Troubleshooting Windows unexpected restarts and stop code errors", and the Windows 11 tab now lists the names as a stop code error, a bug check, a kernel error, a Blue Screen error, or a Black Screen error. The Windows 10 tab of the same page still says blue only.

The change shipped with KB5062660 on Windows 11 version 24H2, build 26100.4770, described as a more streamlined interface that appears with a black background while keeping the technical details visible. David Weston, then corporate vice president for enterprise and OS security, framed the reason as speed rather than aesthetics: 24H2 improved crash dump collection enough to cut downtime during an unexpected restart to about two seconds, in Microsoft's stated figure.

For a technician the practical effect is small. The stop code still appears at the bottom of the screen, and where Windows can identify it, so does the module that was executing. On preview builds the same screen renders green, which is why you will occasionally hear it called a green screen.

Worth knowing that the redesign created an operational problem nobody planned for. Because the black screen shows a progress percentage and a short message, users read it as a Windows Update screen and stop reporting it, so machines sit bugchecked and unticketed.

What Causes Them, by Microsoft's Own Numbers

Microsoft publishes its analysis of crash root causes, and it is the most useful thing in the entire troubleshooting corpus because it tells you where to look first.

Microsoft does not date that analysis or state the sample, so treat it as a published position rather than a 2026 measurement. It still sets the priority correctly. Seven times in ten this is a driver, and the driver is usually one somebody installed or updated recently.

The corollary matters just as much when a user insists an application caused it. Microsoft's wording is that the root cause is rarely a user-mode process, and that while something like a browser or a chat client may trigger a stop error, it is usually exposing an underlying fault in a driver, hardware or the operating system.

The Stop Codes You Will See Most

The stop code is a lookup, not a diagnosis. These are the ten that fill helpdesk queues, with Microsoft's own descriptions rather than paraphrases.

A few carry triage shortcuts worth knowing. On 0x0000000A, if the first parameter is less than 0x1000 the issue is likely a null pointer dereference. On 0x00000116 the default timeout is two seconds, and Windows will bug check outright after more than five timeout events in a minute. On 0x0000007B, Microsoft explicitly names the trap to check first: recent UEFI changes, such as switching a controller from legacy to AHCI.

0x0000007F is the one to read carefully at fleet scale. Trap 0x00000008 is a double fault, and Microsoft names kernel stack overflow as a cause, giving the example of two file system filter drivers attached to the same stack. On a managed endpoint that usually means stacked security and backup agents.

Stop Code: Critical Process Died

CRITICAL_PROCESS_DIED (0x000000EF) means a process Windows can't run without stopped unexpectedly, so the kernel halted the machine on purpose. Processes like csrss.exe, wininit.exe and smss.exe are in that category. The stop code names the symptom. The dump names the process, so open the minidump before you guess.

The causes cluster into four groups: corrupted system files, a failing disk, a bad driver or update, and occasionally malware killing a protected process. Work through them in that order:

• Boot into Windows Recovery Environment and run Startup Repair if the machine loops.
• From Safe Mode or WinRE, run DISM /Online /Cleanup-Image /RestoreHealth, then sfc /scannow.
• Check the disk: chkdsk /scan and the drive's SMART status.
• Roll back the last driver or cumulative update if the crashes started after it.

If the same stop code appears on several machines after one patch window, stop fixing endpoints one by one. Pause the update ring and compare what changed.

Where the Evidence Lives

Two paths, and the difference between them decides whether you still have the crash from last Tuesday.

%SystemRoot%\MEMORY.DMP holds the kernel, complete, automatic or active dump, and it is overwritten by the next crash. %SystemRoot%\Minidump holds small memory dumps, and those are preserved. Microsoft's own note is that each additional minidump gets a distinct name with the date encoded, so a machine that has been crashing for a fortnight has a fortnight of evidence sitting in that folder.

Set which one gets written from Advanced system settings, on the Advanced tab, under Startup and Recovery, in the Write debugging information dropdown. Microsoft's recommendation for general use is Automatic memory dump, which contains the same information as a kernel dump but lets Windows manage the paging file size. The registry equivalent is CrashDumpEnabled under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl, where 1 is complete, 2 kernel, 3 small and 7 automatic.

While you are in that dialog, clear Automatically restart if you want a technician to be able to read the screen rather than hear about it second-hand.

At fleet scale the useful move is batch analysis rather than one dump at a time. A shop running the same stop code across hundreds of endpoints is looking for the module those dumps have in common, not for a single root cause per machine.

Reading the Dump

One piece of naming to settle first, because half the internet still gets it wrong. WinDbg Preview is retired branding. Microsoft's install page states that what was released as WinDbg Preview in the Store is now simply WinDbg, running the same engine and supporting the same commands as the classic build. Install it with winget install Microsoft.WinDbg.

Point it at the Microsoft public symbol server, https://msdl.microsoft.com/download/symbols, open the dump, and run !analyze -v. Microsoft's guidance is to use the verbose option specifically.

What you are reading for: BUGCHECK_STR gives the stop code, STACK_TEXT gives the stack trace of the faulting component, and MODULE_NAME and IMAGE_NAME name the module the debugger holds responsible. PROCESS_NAME names the process that raised the exception, which is often innocent.

The caveat is the important part. The debugger walks the stack until it finds a frame whose owner it can identify, and calls that frame the fault. That makes IMAGE_NAME a strong lead rather than proof. Microsoft publishes two worked examples that land in opposite places: one resolves to NDIS.SYS, a Microsoft driver that cannot be removed, so the fix is disabling the network device; the other resolves to a third-party WwanUsbMp.sys, where disconnecting the device is the answer.

The Event Viewer Trail

The dump tells you what broke. The event log tells you what changed first, which is usually the more useful question.

Microsoft's own heuristic is that a normal reboot shows 1074 followed by 13 and 6009, while an unexpected one shows 41, 1001 and 6008 with no 1074. The technique worth stealing is the next one: filter on 7045 alongside 41 and 1001, and look for a driver or service installed shortly before the first crash. Microsoft's worked example does exactly that and lands on a driver service installed days earlier.

Two traps live here. Event ID 41 records the bug check code in decimal while every reference documents it in hexadecimal, so a BugcheckCode of 159 is the 0x0000009F you need to look up. And if Event 41 shows all zeros with no bug check code, check for Event ID 46 from volmgr, crash dump initialization failed, which explains the machine that crashes reliably and never leaves a dump behind.

Driver Verifier, and How to Get Back Out

When the dumps are not conclusive, Driver Verifier stresses drivers until one misbehaves visibly. It is also the fastest way to make a machine unbootable, so treat it as a lab tool.

Launch it with verifier from an elevated prompt. Microsoft's warnings are worth repeating verbatim to anyone about to run it on a production endpoint: it consumes a lot of CPU and can slow the computer significantly, you may see additional crashes, and you should expect several dump files. Its guidance is to test suspicious drivers first, particularly recently updated ones, and to verify in groups of ten to twenty rather than everything at once.

To undo it, run verifier /reset and restart. If the machine will not reach the desktop at all, the escape hatch is Safe Mode, and the reason it works is neat: Driver Verifier cannot run there.

When It Will Not Boot

Windows enters the recovery environment on its own after two consecutive failed startup attempts, or two unexpected shutdowns within two minutes of boot completing. That is the mechanism behind the machine that loops into recovery rather than starting.

Safe Mode sits under Advanced startup, Troubleshoot, Advanced options, Startup Settings, then option 4, 5 or 6. Startup Repair sits alongside it and writes its log to %windir%\System32\LogFiles\Srt\Srttrail.txt, which is worth reading before assuming it did nothing. If the machine is stuck cycling through the recovery screen, Bcdedit /set {default} recoveryenabled no breaks the loop.

One long-circulating tip no longer applies. Since Windows 10 version 1803 Windows no longer automatically backs up the system registry to the RegBack folder, and Microsoft's recommendation for a corrupt hive is a restore point instead. Last Known Good Configuration is in the same category: older Microsoft troubleshooting pages still mention it, but it is not on the modern recovery menu and needs the legacy boot menu policy enabled to reach at all.

Quick Machine Recovery Is Off on Your Fleet

This is the part most relevant to anyone managing endpoints, and most likely to be news.

Quick Machine Recovery uses a network-connected recovery environment to scan Windows Update for a fix and apply it without anyone touching the machine. It is available on Windows 11 version 24H2 build 26100.4700 and later. On unmanaged Home and Pro devices cloud remediation is enabled by default.

On enterprise-managed systems it is disabled by default. That covers Enterprise, Education, and any Pro device that is domain-joined or enrolled in endpoint management, which is to say most of what an MSP looks after. Microsoft's stated reasoning is that organisations should choose the configuration that suits them, but the practical result is that the feature built for exactly this failure is switched off across managed fleets unless somebody turns it on.

Configure it through the Recovery CSP, through Settings under System and Recovery, or with reagentc.exe /setrecoverysettings /path settings.xml. Check the current state with reagentc.exe /getrecoverysettings.

Before you roll it out, check the network constraint, because it is a real blocker. Microsoft supports wired connections and WPA or WPA2 password-based Wi-Fi, and states that Wi-Fi profiles using certificates with TPM-backed private keys are not supported. A fleet on certificate-based enterprise Wi-Fi cannot use this in its current form. Microsoft also describes the feature as best effort, which is fair: it will not find a solution for every failure.

What to Do Next

Write down the stop code and the module name from the screen, then stop looking at the screen. Pull the minidump folder rather than MEMORY.DMP, because the folder has history and the file has only the most recent crash.

Work the event log for what changed before the first crash rather than the crash itself, filtering on 7045 next to 41 and 1001. Given Microsoft's own 70% figure, the answer is usually a driver, and usually a recent one.

Turn Quick Machine Recovery on deliberately rather than discovering later that it was off, and check your Wi-Fi profile type before assuming it will work. Our guide to patch management software covers keeping driver and update rollout controlled enough that you know what changed, which is the difference between a five-minute diagnosis and an afternoon.

For the wider fleet picture, endpoint management platforms are what let you spot the same stop code on eleven machines instead of treating it as eleven tickets.