A blue screen of death is not Windows failing. It is Windows detecting that its own kernel state is no longer trustworthy and stopping on purpose, because continuing would mean writing corrupt data to disk.
Microsoft calls the event a bug check or a stop error. The screen shows a stop code, which names the kind of failure. The useful part is the minidump written on the way down, because it names a module, and the module is the suspect.
- A BSOD is the kernel choosing to stop rather than corrupt data
- The stop code names the symptom; the dump names the module
- Most bug checks come from drivers, because drivers run in kernel space
- Dump files only exist if Windows was configured to write them
- !analyze -v in WinDbg does the first pass of the analysis for you
On this page
The decisionWhat a BSOD actually is
The kernel runs with unrestricted access to the hardware, and everything in kernel space shares one address space with no boundaries between the parts.
When code in that space does something impossible, dereferences a null pointer, writes past the end of a buffer, touches paged memory at an interrupt level where paging is not allowed, Windows cannot contain the damage the way it contains a misbehaving application. There is no smaller thing to kill.
So Windows stops. It halts every processor, writes what it can of system memory to dump files on disk, and displays the stop code.
That is a deliberate choice with a clear rationale: a system whose kernel state is wrong will corrupt whatever it touches next, and a crash that loses the last few seconds of work is cheaper than a database written with garbage in it.
Linux makes the same decision and calls it a kernel panic. macOS calls it a panic too, and reboots. The BSOD is the Windows presentation of a behavior every serious operating system has.
This framing matters because it changes the question. The BSOD is not the error. It is the system reporting an error, in the only way available to it, along with files full of evidence.
Stop codesThe stop code names the symptom, not the cause
Every article about the blue screen of death is a list of BSOD stop codes. The codes are worth understanding and they are not the answer, because most of them describe what the kernel noticed rather than who caused it.
| Stop code | What the kernel noticed | Usually caused by |
|---|---|---|
| IRQL_NOT_LESS_OR_EQUAL | Paged memory touched at too high an IRQL | A driver |
| DRIVER_IRQL_NOT_LESS_OR_EQUAL | The same, with the driver named | A driver, named on screen |
| SYSTEM_SERVICE_EXCEPTION | A fault crossing into kernel space | A driver, sometimes a service |
| PAGE_FAULT_IN_NONPAGED_AREA | Memory that should be resident was not | A driver, or failing RAM |
| KMODE_EXCEPTION_NOT_HANDLED | Kernel code raised something nothing caught | A driver |
| CRITICAL_PROCESS_DIED | A process the system needs ended | System file corruption |
| UNEXPECTED_KERNEL_MODE_TRAP | The CPU raised a trap the kernel cannot handle | Hardware, or overclocking |
| INACCESSIBLE_BOOT_DEVICE | The boot volume cannot be read | Storage driver or controller change |
Read the right-hand column and the pattern is obvious. Six of these eight stop codes point at kernel mode drivers, which is not a coincidence: drivers are the largest body of third-party code running with kernel privileges on a typical Windows system. Two point at hardware, and only one at Windows files themselves.
DRIVER_IRQL_NOT_LESS_OR_EQUAL is the one worth hoping for, because Windows prints the offending driver file name on the BSOD underneath it. When that name is present, the investigation is mostly over.
Dump filesGetting the evidence
A stop code alone rarely settles anything. The dump files do, and they have to be configured before the crash, not after.
Windows can write several kinds. Automatic memory dump is the default on current client Windows and writes a kernel dump while managing the paging file size itself. Kernel memory dump writes kernel space only, which is nearly always enough.
Complete memory dump writes all of physical memory, which is large and slow and worth setting only when somebody has asked for it. Active memory dump trims the pages that are not useful, which helps on servers with a lot of RAM.
The setting lives under Startup and Recovery, in the Writing Debugging Information box, and behind it in the registry at HKLM\SYSTEM\CurrentControlSet\Control\CrashControl. The full dump goes to %SystemRoot%\Memory.dmp by default and the path is editable, which matters when the system drive does not have room.
A minidump accumulates in the Minidump folder under %SystemRoot%, one per crash, and the minidump set is what to collect on a system that crashes repeatedly, because each file is a few hundred kilobytes rather than gigabytes.
Two failure modes to check before you go hunting. A system with too small a paging file may not be able to write dump files at all. And a machine set to restart automatically will do so before anybody photographs the screen, which is fine once dumps are working and a problem when they are not.
When it does, the stop code survives in the event log: event ID 41 carries the bug check code on the next boot, in decimal rather than hexadecimal.
The analysisReading the dump
Install the Windows debugging tools, open the dump in WinDbg, and run one command.
!analyze -vIn kernel mode, !analyze displays information about the most recent bug check, and it runs automatically when a dump is opened. The -v switch adds verbose output, and it accepts a number from 0 to 99 for more still. If you want only the raw bug check parameters without the analysis, .bugcheck prints those.
What you are looking for in the output is a module name, which is to say the name of a file.
The verbose analysis names the module and image it believes is responsible, along with the call stack at the moment of the fault. That name is a file, the file belongs to a driver, and the driver belongs to a vendor.
From there the work is ordinary. Find that driver's version and date, check whether it was updated shortly before the crashes started, and check whether the vendor has published a newer one.
A driver dated four years ago on hardware whose Windows build was upgraded last month is a strong candidate. So is a driver that arrived in last week's patch cycle.
Two cautions. First, the named module is a suspect and not a verdict, because a driver that corrupts memory frequently causes the crash to surface inside innocent code somewhere else. Second, when !analyze names a core Windows component such as ntoskrnl.exe, that almost always means it could not attribute the fault, not that Windows itself is at fault.
No suspectWhen the dump does not name anything useful
This is the case worth having a procedure for, because it is common and it is where people start reinstalling.
Turn on Driver Verifier. It is the most effective fix-finding tool Windows ships. It puts kernel mode drivers under aggressive checking, so a driver that corrupts memory crashes immediately at the point of the offense rather than later somewhere innocent.
It will make the machine crash more, on purpose, and the crashes will be attributable. Enable it for non-Microsoft drivers only, reproduce the crash, then turn it off, and know how to get back in through safe mode before you start.
Test the memory. PAGE_FAULT_IN_NONPAGED_AREA and UNEXPECTED_KERNEL_MODE_TRAP with no consistent module are the classic pattern for failing RAM, and RAM is the hardware fault that produces the widest variety of blue screen errors, because it corrupts whatever happens to be resident.
Windows Memory Diagnostic is built into Windows, and a long MemTest86 pass is more thorough.
Check for a common denominator across machines. If several Windows computers hit a blue screen in the same week, the cause is almost never hardware. It is something all of them received: a driver, an agent, a firmware update pushed by the vendor's management tool.
Check the temperatures and the power. Bug checks that only happen under load, and only on one machine, are frequently a thermal or power supply hardware fault rather than software.
Storage is worth ruling out at the same time, because a failing disk under load looks like almost anything, which is why the SSD or drive health is a cheap thing to read early.
Check what changed, and when. Windows Update keeps an update history with install dates, and a computer that started producing stop errors the day after a quality update or a driver update has told you where to look.
A driver delivered that way can be rolled back in Device Manager, and keeping it from coming back is a separate job, covered in how to stop Windows Update and how to update drivers. System Restore is the blunt version of the same idea, and it only helps when the restore point predates the errors.
Look at the Windows event log before the crash. The System log entries in the minute before the bug check often name a hardware device that reset or a critical service that failed, and that is context the minidump does not carry.
Boot loopWhen the blue screen happens before Windows loads
Everything above assumes a computer that boots. A blue screen of death that repeats during startup is a different problem, because there is no desktop to read the dump from and no way to uninstall the driver that is causing it.
Windows handles the first part itself. Microsoft's Windows RE technical reference states that the recovery environment starts automatically after two consecutive failed attempts to start Windows, two consecutive unexpected shutdowns within two minutes of boot completion, two consecutive restarts within that same window, a Secure Boot error, or a BitLocker error on touch-only devices.
So a machine in a blue screen loop usually lands in the recovery environment on its own. If it does not, holding Shift while choosing Restart gets there from a working session, and installation media offers the same menu under Repair your computer.
From that menu, Startup Settings leads to safe mode, and safe mode is the point of the exercise. It starts Windows with a minimal set of drivers, so the third-party driver behind most blue screen errors usually never loads, and the machine stays up long enough to remove it.
Three things to do once you are in. Roll back or uninstall the driver for the device you suspect, in Device Manager. Uninstall the most recent quality update if the errors started with it. Copy the Minidump folder off, because the evidence is still on the disk even when Windows will not start.
Have the BitLocker recovery key before you begin. An encrypted system drive will ask for it at the recovery environment, and looking for it afterward is how a two hour repair becomes a two day one. Where it is kept is covered in BitLocker recovery key.
PitfallsWhere people go wrong
Searching the stop code and stopping there. Stop codes are categories, not errors with one fix. A fix written for somebody else's IRQL_NOT_LESS_OR_EQUAL is a fix for a different driver.
Reinstalling Windows to fix a driver. It works, in the sense that it removes the driver, and it also destroys the dump files and takes a day. Read the dump first.
Updating every driver at once. If the crashes stop, you have learned nothing about which one it was, and you have created a new baseline you cannot roll back cleanly.
Leaving dump files disabled after the incident. The single most expensive error here is a Windows computer that crashed three times and wrote nothing, because the only path left is waiting for the next blue screen.
Ignoring the pattern across an estate. One blue screen is one computer. Five in a week on different hardware is a deployment, and the thing to look at is what was deployed. A directory query by operating system and build tells you which machines share the change faster than any agent report.
Trusting a driver because it is signed. Signing proves origin, not quality. A signed driver that corrupts memory is still a driver that corrupts memory.
ComparisonA bug check, a panic, and an ordinary crash
| Criterion | Windows bug check | Linux kernel panic | An application crash |
|---|---|---|---|
| What failed | Kernel space code | Kernel space code | User space code |
| What stops | The whole machine | The whole machine | One process |
| Evidence written | Memory.dmp and minidumps | vmcore via kdump | A user mode dump |
| First command | !analyze -v | crash on the vmcore | Attach a debugger |
| Usual culprit | A third-party driver | A module or firmware | The application |
| Preventable by | Staging kernel mode software | Staging modules | Normal testing |
The last row is the operational point. An application crash is contained, so ordinary release practice is enough. Anything that loads into kernel space carries no containment at all, which is why the same rollout that is fine for an application is not fine for an endpoint agent or a storage driver.
FAQFrequently asked questions
What is the blue screen of death?
The error screen Windows shows when the kernel stops on purpose after detecting that its own state is no longer trustworthy. Microsoft calls the event a bug check or a stop error, and it is the Windows form of what Linux calls a kernel panic.
What causes a blue screen of death?
Most often a kernel mode driver, because drivers are the largest body of third-party code running with kernel privileges. After that, hardware: failing RAM, storage or controller problems, firmware, and thermal or power faults.
Is a BSOD a hardware or software problem?
Both are possible and drivers are the most common single cause. The dump files tell you which, and guessing without them is why the same system gets reinstalled twice.
What is a BSOD stop code?
The name of the error condition the kernel detected, such as IRQL_NOT_LESS_OR_EQUAL. It describes the symptom, not the culprit, which is why two machines with the same stop code often have different causes.
Where are the BSOD dump files stored?
The full dump goes to %SystemRoot%\Memory.dmp by default, and the path is configurable in Startup and Recovery. Small dumps collect in a Minidump folder under %SystemRoot%, one per crash.
How do I read a minidump file?
Open the minidump in WinDbg from the Windows debugging tools and run !analyze -v. The verbose output names the module it believes is responsible along with the call stack at the fault.
How do I fix a BSOD that blames ntoskrnl.exe?
Not by replacing Windows files. That name usually means the analysis could not attribute the error to anything more specific, not that the Windows kernel is broken. Treat it as an unattributed crash and reach for Driver Verifier.
What is Driver Verifier and when should I use it?
A built-in tool that puts kernel mode drivers under aggressive checking so a memory-corrupting driver crashes at the point of the offense instead of later. Use it when the dumps are not naming a consistent module, enable it for non-Microsoft drivers, and know your way into safe mode first.
Why did Windows reboot without showing a BSOD?
Automatic restart on system failure is on by default. Turn it off while investigating, or rely on the dump instead of the screen.
Can I get a dump file if Windows never wrote one?
No. Dump files have to be configured before the crash. Check the Startup and Recovery setting and that the paging file is large enough, then wait for the next error.
Can I force a BSOD to test the configuration?
Yes, with the Sysinternals NotMyFault tool, which triggers a bug check on purpose so you can confirm the dump files are written and readable before you need them.
Several systems hit a BSOD this week. Where do I start?
With what they have in common rather than with any one machine. Different hardware crashing in the same window points at something deployed: a driver, an endpoint agent, a firmware push.
Does a signed driver mean it is safe?
Signing proves who published it. It says nothing about whether the code is correct, and a signed driver has exactly the same critical privileges as an unsigned one once Windows has loaded it.
How is a BSOD different from an application crash?
An application crash kills one process and the machine keeps running, because user space code is contained. A bug check happens in kernel space, where there is no containment and no smaller thing to stop than the machine.
What is a Windows stop error?
A Windows stop error is the official name for the blue screen. Windows halts because continuing could damage data, shows a stop code such as CRITICAL_PROCESS_DIED, and writes a memory dump. The stop code and the dump are what identify the driver or hardware fault behind a blue screen on Windows.
Keep readingRelated concepts
Read next · Platforms What a Kernel Is, and Why a Driver Can Take Down the Machine Why a driver fault stops the machine instead of ending a process: everything in kernel space shares one address space with no boundaries. Open this next10 min- Disks and drives · 12 min SSD vs HDD The hardware worth ruling out early, because a failing disk under load can look like almost any stop code.
- Operations · 13 min Patch Management, and Why the Hard Part Is Not the Patching Where a driver that arrived last week shows up, and why anything loading into kernel space needs a slower rollout.
- Windows administration · 11 min The DISM Command, and What Each Repair Switch Actually Does The repair commands to run when a bug check points at a Windows system file.
- Windows administration · 11 min How to Reset a Graphics Driver, and What Windows Already Does for You What the screen means when a display driver reset fails: VIDEO_TDR_FAILURE, 0x116.
- Windows · 8 min Reboot Event IDs, and the One That Names the Culprit The event log entry that tells you a Stop error happened.