Skip to main content
A Blue Screen of Death (BSOD) is Windows’ last resort when it detects a fatal error from which it cannot safely recover — the kernel halts all operations, saves a memory dump to disk, and displays a stop code on a blue (or, on Windows 11, black) screen. While alarming, most BSODs are caused by a bad driver, failing hardware, or corrupt system files rather than anything permanently catastrophic. This guide walks you through reading the stop code, finding the root cause, and applying targeted fixes.

​
Step 1 — Read and Record the Stop Code

The stop code is the single most important piece of information on the BSOD screen.
1

Photograph or write down the stop code

When the BSOD appears, look for the large text in the format YOUR_STOP_CODE_HERE (e.g., IRQL_NOT_LESS_OR_EQUAL). Below it you will also see a hexadecimal bug check code such as (0x0000000A). Record both.
2

Note what you were doing when it occurred

Was it triggered by opening a specific application, connecting a device, resuming from sleep, or during a Windows Update? Timing and context dramatically narrow the cause.
3

Check if it is reproducible

A BSOD that occurs every time you perform the same action points to a software or driver fault. A BSOD that occurs randomly under load is more likely hardware (RAM, CPU, or GPU instability or overheating).

​
Step 2 — Understand Common Stop Codes

The stop code displayed on the BSOD screen directly identifies the category of failure. Expand the entry that matches what you recorded to understand the root cause and which fix to apply first.
Meaning: A driver or kernel component attempted to access memory at an invalid interrupt request level (IRQL). This is almost always a driver bug.Most common causes:
  • A recently installed or updated device driver
  • Faulty or incompatible RAM
  • Antivirus or security software conflict
Primary fix: Roll back or uninstall the most recently installed driver. Run a RAM test with Windows Memory Diagnostic.
Meaning: A process requested a page of memory that was not present — typically because RAM is faulty, a driver tried to access freed memory, or the paging file is misconfigured.Most common causes:
  • Defective RAM module
  • Corrupt or outdated driver (especially antivirus or filter drivers)
  • Damaged system files
Primary fix: Run sfc /scannow, check RAM health, and verify that the paging file is set to System Managed.
Meaning: An exception occurred while executing a routine that transitions between user-mode and kernel-mode code. The most frequent culprit is a graphics driver or a system service crashing.Most common causes:
  • Outdated or corrupt GPU driver
  • Third-party antivirus kernel drivers
  • Corrupt system files (ntfs.sys, win32k.sys, ataport.sys)
Primary fix: Update or roll back the GPU driver; run sfc /scannow and DISM.
Meaning: Similar to IRQL_NOT_LESS_OR_EQUAL but specifically implicates a driver attempting a memory access at an elevated IRQL. The second parameter in the bug check output names the offending driver file.Primary fix: Identify the named driver from the minidump and update or uninstall it.
Meaning: A critical system process (such as csrss.exe, wininit.exe, or winlogon.exe) terminated unexpectedly. Often caused by corrupt system files or a failing drive.Primary fix: Run sfc /scannow, DISM, and chkdsk.

​
Step 3 — Locate and Analyze the Minidump File

Every BSOD (when properly configured) writes a small dump file that records the kernel state at the moment of the crash. Analyzing it reveals the exact driver or module responsible.
1

Verify dump file settings

Open System Properties → Advanced → Startup and Recovery → Settings. Under Write debugging information, select Small memory dump (256 KB). Confirm the dump file path is set to %SystemRoot%\Minidump.
2

Locate the minidump files

3

Install WinDbg

Download WinDbg from the Microsoft Store or install it as part of the Windows SDK:
4

Open and analyze the dump file in WinDbg

Launch WinDbg, go to File → Open Crash Dump, and select the most recent .dmp file. Once loaded, run the automated analysis command:
Look for the MODULE_NAME, IMAGE_NAME, and FAULTING_IP fields — these name the driver or binary that triggered the crash.
5

Interpret the output

The STACK_TEXT section shows the call stack leading up to the crash. A driver filename like nvlddmkm.sys (NVIDIA), ataport.sys (storage), or a third-party xyz.sys file directly identifies the component to target.
If minidump files do not appear after a BSOD, the system may be configured to perform a full memory dump, or the crash happened too fast for Windows to write to disk. Ensure the page file on the system drive is at least 1.5× the installed RAM.

​
Step 4 — Roll Back a Recent Driver

If the BSODs started after a driver update or new hardware installation, rolling back the driver is the fastest resolution.
1

Open Device Manager

2

Locate the suspect device

Expand the relevant category (Display adapters, Network adapters, etc.). Right-click the device and choose Properties.
3

Roll back the driver

Navigate to the Driver tab and click Roll Back Driver. If the button is greyed out, no previous driver version is stored and you will need to download an older version manually from the manufacturer’s website.
4

Restart and monitor

Reboot and use the system normally for at least 30 minutes. If the BSOD does not recur, the driver update was the cause. Report the faulty driver version to the vendor.
For GPU driver issues, use Display Driver Uninstaller (DDU) in Safe Mode to perform a completely clean uninstall before reinstalling a known-stable driver version. This removes residual registry entries that a standard uninstall leaves behind.

​
Step 5 — Run chkdsk to Check Disk Integrity

Disk errors — bad sectors, file system corruption — can cause several different BSODs including PAGE_FAULT_IN_NONPAGED_AREA and CRITICAL_PROCESS_DIED.
1

Run chkdsk with repair flags

Open an elevated Command Prompt or PowerShell:
  • /f — Fixes file system errors
  • /r — Locates bad sectors and attempts recovery
  • /x — Forces the volume to dismount first (required for the system drive)
2

Schedule for next boot if the drive is in use

For the system (C:) drive, chkdsk cannot run while Windows is loaded. Type Y when prompted to schedule the check for the next restart. Reboot to allow it to run.
3

Review the results

After the check completes, open Event Viewer and navigate to Windows Logs → Application. Look for the source Wininit for the chkdsk results log entry.

​
Step 6 — Run sfc /scannow to Repair System Files

The System File Checker (SFC) scans all protected Windows system files and replaces corrupt or missing versions from a cached copy.
1

Open an elevated Command Prompt

Right-click Start and choose Terminal (Admin) or Command Prompt (Admin).
2

Run the System File Checker

The scan runs for several minutes. Do not close the window.
3

Review the results

  • Windows Resource Protection did not find any integrity violations — System files are clean; the BSOD has another cause.
  • Windows Resource Protection found corrupt files and successfully repaired them — Restart and monitor for further BSODs.
  • Windows Resource Protection found corrupt files but was unable to fix some of them — Proceed to DISM.
4

Run DISM if SFC cannot repair files

DISM repairs the Windows Component Store that SFC draws from:
After DISM completes, run sfc /scannow a second time to apply the now-repaired source files.
Always run SFC and DISM from an elevated prompt. Running them as a standard user silently fails without reporting an error.

​
Step 7 — Test RAM with Windows Memory Diagnostic

Random BSODs with varying stop codes and no clear driver culprit strongly suggest faulty RAM.
1

Launch Windows Memory Diagnostic

Choose Restart now and check for problems. The tool runs before Windows loads and takes 10–20 minutes depending on RAM size.
2

Review the results

After reboot, results appear as a notification. To retrieve them later:
3

If errors are found

Test each RAM stick individually by removing all but one and running the diagnostic again. Replace any stick that produces errors.
For a more thorough RAM test, use MemTest86 (free, bootable from USB). Run it for at least two full passes — ideally overnight. Even a single error in MemTest86 indicates a faulty stick.

​
Escalation Criteria

Escalate to Tier 2 or a hardware specialist if any of the following apply:
  • WinDbg analysis names a Microsoft kernel driver (e.g., ntoskrnl.exe, hal.dll) with no third-party driver in the call stack — this can indicate hardware failure or a deep OS corruption requiring a repair upgrade or reinstall.
  • BSODs persist after rolling back all recently changed drivers and running SFC + DISM successfully.
  • chkdsk reports bad sectors that cannot be recovered — the storage drive should be replaced before further troubleshooting.
  • MemTest86 or Windows Memory Diagnostic reports errors on all RAM sticks individually — check the memory slots and motherboard for physical damage.
  • The machine BSODs during POST or while loading WinRE, indicating a hardware failure too severe to diagnose from within the OS.