A stop code is the line of capitalised text on a Windows blue screen, such as MEMORY_MANAGEMENT or IRQL_NOT_LESS_OR_EQUAL. It names the class of failure, not the culprit. Microsoft’s root-cause analysis of crashes attributes 70% to third-party driver code and 10% to hardware.
The odds are known before you diagnose anything. Drivers, memory and storage account for the overwhelming majority of blue screens, and a stop code’s real job is to tell you which of those three to check first. Find your code in the table below and start on that row.
Where to find your stop code
The code is printed in plain text near the bottom of the blue screen, under the percentage counter. The QR code beside it leads to a general Microsoft support page rather than a diagnosis of your particular crash, so photograph the words instead. If the screen vanishes before you can read it, there is more on reading a blue screen and what the rest of that screen is telling you.
When the machine restarted too fast, two records survive.
Event Viewer. Press Win + R, run eventvwr.msc, then open Windows Logs → System. Click Filter Current Log and tick Critical and Error. The crash is recorded as a BugCheck entry, event ID 1001, which repeats the stop code and its four parameters.
The minidump. Windows writes a small dump file for each bug check. Microsoft lists the location as %SystemRoot%Minidump, which on a standard install is C:WindowsMinidump. That file is the only record naming the .sys file actually involved. If the folder is empty, dump collection is switched off or greyed out: search Advanced system settings, open Settings under Startup and Recovery, and set Write debugging information to Automatic memory dump.
Every stop code you are likely to meet
The hex values below come from Microsoft’s bug check code reference, the authoritative catalogue of every code Windows can raise.
| Stop code | Hex | Usual cause | Where to start |
|---|---|---|---|
CRITICAL_PROCESS_DIED | 0x000000EF | A process Windows cannot run without was killed, usually damaged system files | DISM then SFC, then Safe Mode |
MEMORY_MANAGEMENT | 0x0000001A | Memory management fault, most often RAM | Windows Memory Diagnostic, then MemTest86 |
IRQL_NOT_LESS_OR_EQUAL | 0x0000000A | Kernel-mode code touched memory it should not have, almost always a driver | Roll back the most recently updated driver |
PAGE_FAULT_IN_NONPAGED_AREA | 0x00000050 | Invalid system memory referenced: a bad address, or a driver pointing at freed memory | Memory test, then chkdsk /f /r |
SYSTEM_SERVICE_EXCEPTION | 0x0000003B | A driver faulted crossing into kernel mode, frequently graphics | Graphics and chipset drivers, then SFC |
KERNEL_SECURITY_CHECK_FAILURE | 0x00000139 | A kernel data structure failed an integrity check: driver, RAM or disk corruption | Memory test and disk check together |
DPC_WATCHDOG_VIOLATION | 0x00000133 | A driver failed to finish its work in the allotted time | Storage controller driver and SSD firmware |
VIDEO_TDR_FAILURE | 0x00000116 | The display driver stopped responding and could not be reset | Clean-install the GPU driver, check temperatures |
UNEXPECTED_STORE_EXCEPTION | 0x00000154 | The store component hit an exception it did not expect | Drive SMART health, then chkdsk /f /r |
INACCESSIBLE_BOOT_DEVICE | 0x0000007B | Windows lost access to the system partition while booting | Undo the last update or BIOS storage mode change |
WHEA_UNCORRECTABLE_ERROR | 0x00000124 | A fatal hardware error reported by the platform itself | Clear all overclocks, then test CPU, RAM and PSU |
One pattern runs down that table: driver, memory, storage. If your code is not here, the reference above lists the complete set, and the four checks below apply whichever code you have.
The four checks worth doing before anything else
1. Write down what changed. New RAM, a new graphics card, a driver update, a Windows update, a fresh antivirus, an overclock, a BIOS setting. Crashes that started on a specific day almost always have a cause from that day. This single question resolves more blue screens than any command on this page, and skipping it is how people end up reinstalling Windows over a driver they installed on Tuesday.
2. Boot into Safe Mode. Safe Mode loads a minimal set of Microsoft drivers. If the crashes stop there, you have a software or driver fault and the rest of this page applies. If they continue, skip to the hardware section. The routes to boot into Safe Mode differ depending on whether Windows still starts, so pick the one that matches your situation.
3. Run DISM, then SFC. Open Terminal or Command Prompt as administrator and run these in order:
DISM /Online /Cleanup-Image /RestoreHealthsfc /scannowThe order is not optional. Microsoft’s instruction is to run DISM before the System File Checker, because DISM supplies the healthy files that SFC then uses for replacement. Restart when both finish.
4. Test the RAM. Bad memory produces different stop codes on different days, which is exactly why random-looking crashes need a memory test early rather than late. Microsoft’s guidance for error 0xA is to check memory with the Windows Memory Diagnostic tool: press Win + R, run mdsched, and choose Restart now and check for problems. Press F1 during the test to switch to the Extended pass, which catches faults the standard pass misses.
Results land in Event Viewer under Application and Services Logs → Microsoft → Windows → MemoryDiagnostics-Results → Debug, where event ID 2001 means no errors were found. A clean result is worth confirming with MemTest86 from a USB stick over several passes before you rule memory out. A single error anywhere means a bad stick, so test them one at a time to identify which.
When it is hardware, not software
Four signs move the diagnosis out of Windows entirely.
| Tell | What it means |
|---|---|
| Crashes continue in Safe Mode | Minimal drivers are loaded, so the fault is below the driver layer |
| Freezes or resets during POST or in the BIOS | Windows is not running at all, so Windows cannot be the cause |
WHEA_UNCORRECTABLE_ERROR (0x00000124) | The hardware itself reported a fatal error it could not correct |
| SMART data showing reallocated or pending sectors | The drive is failing, and file corruption follows |
Any of those and software repair is wasted effort. Back your files up first, because a failing drive gets worse and a crashing machine corrupts what it was writing. Then reduce the variables: clear every overclock including XMP and EXPO memory profiles, run on one RAM stick, remove the discrete graphics card if the board has onboard video, and check temperatures under load. People in this position often decide to reinstall Windows as a last resort, which is sound advice for a software fault and a waste of an afternoon for a hardware one. Establish which you have before you commit.
Three fixes that do not do what people think
Running sfc /scannow on its own. SFC repairs damaged system files from the component store, and if that store is damaged too it reports files it “could not fix” and stops. Running DISM first is what makes the second command work.
Reading the stop code as a diagnosis. MEMORY_MANAGEMENT names the part of Windows that detected the fault, not the part that caused it. A driver writing to memory it does not own produces a memory-flavoured code while being a driver problem throughout. The minidump names the component; the stop code only narrows the search.
Driver updater utilities. These bundle generic packages and frequently install older versions than you already have. Get graphics drivers from Nvidia, AMD or Intel directly, and chipset and storage drivers from your motherboard or laptop manufacturer’s support page for your exact model.
Common questions
Does the stop code tell me which driver crashed?
Rarely. Some blue screens name a .sys file beneath the stop code, which identifies the driver immediately. Most do not. The minidump in C:WindowsMinidump records the faulting module for every crash, and a free reader such as BlueScreenView parses it and names the driver without needing a debugger.
Is one blue screen worth worrying about?
A single crash after installing a driver or new hardware is worth noting, not panicking over. A crash once a week means something is genuinely faulty. Daily blue screens usually point at failing RAM or a dying drive, so back up your files before troubleshooting further rather than after.
Where does Windows save blue screen crash logs?
Two places. Event Viewer logs each bug check in Windows Logs → System as a BugCheck entry containing the stop code. Windows also writes a memory dump, with small dumps saved to %SystemRoot%Minidump, normally C:WindowsMinidump. The dump holds the detail; the event log holds the timeline.
Can bad RAM cause different stop codes each time?
Yes, and that inconsistency is itself a clue. Faulty memory corrupts whatever happens to be stored in the failing cells, so the code reflects whichever component read the corruption. MEMORY_MANAGEMENT, PAGE_FAULT_IN_NONPAGED_AREA and KERNEL_SECURITY_CHECK_FAILURE appearing in rotation is a classic memory pattern.
Will reinstalling Windows fix blue screens?
It fixes crashes caused by damaged system files, bad driver installations and software conflicts, which covers a large share of them. It fixes nothing caused by failing RAM, a dying drive, an unstable overclock or an overheating component. Test the hardware first, or you will crash again on the fresh install.
Answer one question before touching anything: do the crashes still happen in Safe Mode? No means it is a driver and the dump file will name it. Yes means it is hardware and no amount of reinstalling will help.
