How to Find Your Windows Stop Code

Q: I have the code but no driver name. What now?

Read the dump. The What failed line only appears when Windows could confidently attribute the fault, which is a minority of crashes - but the dump frequently identifies a module even when the screen did not. Fifteen minutes with WinDbg, covered in the dump reading guide.And compare several dumps rather than one. The same driver appearing every time is a finding; a different one each time usually means memory corruption rather than a driver problem at all.

You need the stop code before anything else on this site is useful - it is the difference between troubleshooting and guessing. The problem is that the crash screen has become genuinely hard to read: Microsoft redesigned it and now reboots from it in about two seconds. This page covers what the screen shows, how to make it stay long enough to read, and four ways to recover the code after the machine has already restarted.

Updated 2026-07-28

What the crash screen looks like now

If you have looked this up before, what you remember may not be what you see. Microsoft redesigned the screen for Windows 11 version 24H2.

	Windows 10 and earlier Windows 11	Windows 11 24H2 onward
Colour	Blue	Black
Sad face	Yes	Removed
QR code	Yes	Removed
Stop code	Yes	Yes - still there
Faulty driver name	Sometimes	Sometimes

The two things you actually need survived the redesign. Stop code is the line naming the fault - SYSTEM_SERVICE_EXCEPTION, IRQL_NOT_LESS_OR_EQUAL and so on. What failed names a driver file when Windows managed to identify one, and if you get that, it is often the whole diagnosis.

You have about two seconds

Alongside the redesign, Microsoft made the machine restart far faster - reportedly around two seconds from crash screen to reboot. That is not enough time to read a stop code, let alone photograph one.

So on current Windows, the realistic advice is no longer "write down what it says". It is: turn off automatic restart so the screen waits for you, and in the meantime recover the code from the logs.

The percentage counter you may remember was the memory dump being written. If your machine still shows one, letting it finish is worth it - that dump is the most detailed evidence you will get.

Make the screen stay next time

Two minutes of setup, and every future crash becomes readable. Worth doing before you troubleshoot anything.

Press Win+R, type sysdm.cpl, press Enter.
Go to the Advanced tab.
Under Startup and Recovery, click Settings.
Under System failure, clear Automatically restart.
While you are there, set Write debugging information to Automatic memory dump.

The first change makes the crash screen wait until you restart the machine yourself. The second makes sure a dump file gets written, which matters for everything else on this site.

Route 1 - Event Viewer, the direct answer

Windows records the stop code and all four of its parameters at the next boot. This is the most reliable route and it needs no tools.

Press Win+R, type eventvwr, press Enter.
Expand Windows Logs, click System.
Click Find on the right and search for bugcheck.

You are looking for Event ID 1001 from source BugCheck. The message reads:

The computer has rebooted from a bugcheck.  The bugcheck was:
0x0000003b (0x00000000c0000005, 0xfffff8036a1c4e10,
0xffffb80f9c2a7530, 0x0000000000000000).
A dump was saved in: C:\Windows\MEMORY.DMP.

The first value is your stop code - 0x0000003b here. The four in brackets are its parameters, and on many codes they narrow the diagnosis considerably.

From PowerShell, the same thing without the clicking:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} -MaxEvents 20 |
  Where-Object { $_.Message -match 'bugcheck was' } |
  Select-Object TimeCreated, Message | Format-List

Route 2 - Kernel-Power 41, when there is no BugCheck entry

Sometimes Event 1001 is missing but the machine clearly crashed. Kernel-Power Event 41 is written on every unclean shutdown and carries the stop code in its structured data.

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kernel-Power'; Id=41} -MaxEvents 10 |
  ForEach-Object {
    $x = [xml]$_.ToXml(); $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
      Time = $_.TimeCreated
      Dec  = $d['BugcheckCode']
      Hex  = if ($d['BugcheckCode']) { '0x{0:X8}' -f [uint32]$d['BugcheckCode'] }
    }
  } | Format-Table -AutoSize

This field is in decimal

Every other place you meet a stop code it is hexadecimal. Here it is not, and it catches people constantly.

A BugcheckCode of 59 is not stop code 0x59 - it is 0x3B. 209 is 0xD1. 340 is 0x154. The script above converts it for you.

A BugcheckCode of zero means no stop code was recorded, which is a different situation and not necessarily a power problem - the Event 41 page covers how to read it.

Route 3 - Reliability Monitor, the friendly one

The least technical route, and the best one for seeing the shape of a problem rather than a single incident.

Press Win+R and run:

perfmon /rel

You get a calendar with a red cross on every day something failed. Click one, then View technical details - the stop code appears there.

What makes this worth opening even when you already have the code is the timeline. A machine that was stable for two years and started failing three weeks ago tells a completely different story from one that has always been unreliable, and this view shows that in seconds. The crash history guide goes further into reading the pattern.

Route 4 - The dump file, when you need the driver name

The stop code tells you the category. The dump often tells you which driver, which is what you actually want.

Dumps live in C:\Windows\Minidump\ - one file per crash, named by date - and C:\Windows\MEMORY.DMP for the larger kind. Reading one is a fifteen-minute job with WinDbg from the Microsoft Store, and the dump reading guide walks through it.

No dump files at all?

That is informative in itself. Check the Startup and Recovery settings above, and confirm the page file is on the system drive and system-managed - dump writing needs it.

If dumps still never appear despite repeated crashes, look for volmgr Event ID 46, "Crash dump initialization failed!". And if there is no Event 46 either, the machine may be dying too abruptly to write anything, which points at power or hardware rather than software.

Now use it

Once you have a code, go to the stop codes index and find it. Search the exact value including the 0x prefix - and note that codes are conventionally written padded to eight digits, so 0x3B and 0x0000003B are the same thing.

If what you have is not a stop code at all but an Event Viewer entry from a machine that is still running - a WHEA-Logger warning, a display driver timeout, a disk error - those live under hardware errors instead. Those are the entries that tell you something is degrading before it starts crashing, and they are worth reading while you still have the choice.

Frequently asked

The blue screen is black now. Is that a different error?

No - it is the same mechanism with a new appearance. Microsoft redesigned the crash screen for Windows 11 version 24H2: it is black rather than blue, and the frowning face and QR code are gone. The stop code and the faulty driver line both remain, which are the only parts you needed.

So a black crash screen is not a distinct or worse category of failure, and everything on this site applies to it unchanged.

It restarts before I can read anything.

That is now the normal experience rather than bad luck - current Windows reboots from the crash screen in roughly two seconds. Turn off automatic restart using the steps above and the screen will wait for you next time.

For the crash that already happened, use Event Viewer. The code is recorded whether or not anyone read the screen.

Where did the QR code go?

Removed in the 24H2 redesign. It is no real loss - it always pointed at a generic Microsoft troubleshooting page rather than anything specific to your stop code, so scanning it told you very little that the code itself did not.

I have the code but no driver name. What now?

Read the dump. The What failed line only appears when Windows could confidently attribute the fault, which is a minority of crashes - but the dump frequently identifies a module even when the screen did not. Fifteen minutes with WinDbg, covered in the dump reading guide.

And compare several dumps rather than one. The same driver appearing every time is a finding; a different one each time usually means memory corruption rather than a driver problem at all.

Event Viewer shows nothing under BugCheck.

Try Kernel-Power Event 41 instead, using the PowerShell above - it is written on every unclean shutdown and carries the code in its data. If that shows a BugcheckCode of zero and no dumps have ever been written, then the machine is going down without reaching the point where it can record anything, which shifts suspicion toward power, thermals or hardware.