> ## Documentation Index
> Fetch the complete documentation index at: https://docs.derekdinh.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting Windows Blue Screen of Death (BSOD)

> Read stop codes, analyze minidump files, and resolve the most common Windows Blue Screen of Death errors with drivers, disk checks, and system file repair.

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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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>
</Steps>

***

## 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.

<Accordion title="IRQL_NOT_LESS_OR_EQUAL (0x0000000A)">
  **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.

  ```powershell theme={null}
  # Launch Windows Memory Diagnostic
  mdsched.exe
  ```
</Accordion>

<Accordion title="PAGE_FAULT_IN_NONPAGED_AREA (0x00000050)">
  **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.
</Accordion>

<Accordion title="SYSTEM_SERVICE_EXCEPTION (0x0000003B)">
  **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.
</Accordion>

<Accordion title="DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1)">
  **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.
</Accordion>

<Accordion title="CRITICAL_PROCESS_DIED (0x000000EF)">
  **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`.
</Accordion>

***

## 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.

<Steps>
  <Step title="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`.

    ```powershell theme={null}
    # Open Startup and Recovery settings directly
    Start-Process sysdm.cpl
    ```
  </Step>

  <Step title="Locate the minidump files">
    ```powershell theme={null}
    # List all minidump files sorted by date (newest first)
    Get-ChildItem -Path "$env:SystemRoot\Minidump" -Filter "*.dmp" |
        Sort-Object LastWriteTime -Descending
    ```
  </Step>

  <Step title="Install WinDbg">
    Download WinDbg from the Microsoft Store or install it as part of the Windows SDK:

    ```powershell theme={null}
    # Install WinDbg via winget
    winget install Microsoft.WinDbg
    ```
  </Step>

  <Step title="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:

    ```windbg theme={null}
    !analyze -v
    ```

    Look for the **MODULE\_NAME**, **IMAGE\_NAME**, and **FAULTING\_IP** fields — these name the driver or binary that triggered the crash.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Note>
  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.
</Note>

***

## 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.

<Steps>
  <Step title="Open Device Manager">
    ```powershell theme={null}
    devmgmt.msc
    ```
  </Step>

  <Step title="Locate the suspect device">
    Expand the relevant category (Display adapters, Network adapters, etc.). Right-click the device and choose **Properties**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Tip>
  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.
</Tip>

***

## 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`.

<Steps>
  <Step title="Run chkdsk with repair flags">
    Open an elevated Command Prompt or PowerShell:

    ```cmd theme={null}
    chkdsk C: /f /r /x
    ```

    * `/f` — Fixes file system errors
    * `/r` — Locates bad sectors and attempts recovery
    * `/x` — Forces the volume to dismount first (required for the system drive)
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.

    ```powershell theme={null}
    # View the chkdsk log entry directly
    Get-WinEvent -LogName Application |
        Where-Object { $_.ProviderName -eq 'Microsoft-Windows-Chkdsk' } |
        Select-Object -First 5 | Format-List Message
    ```
  </Step>
</Steps>

***

## 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.

<Steps>
  <Step title="Open an elevated Command Prompt">
    Right-click **Start** and choose **Terminal (Admin)** or **Command Prompt (Admin)**.
  </Step>

  <Step title="Run the System File Checker">
    ```cmd theme={null}
    sfc /scannow
    ```

    The scan runs for several minutes. Do not close the window.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Run DISM if SFC cannot repair files">
    DISM repairs the Windows Component Store that SFC draws from:

    ```cmd theme={null}
    DISM /Online /Cleanup-Image /CheckHealth
    DISM /Online /Cleanup-Image /ScanHealth
    DISM /Online /Cleanup-Image /RestoreHealth
    ```

    After DISM completes, run `sfc /scannow` a second time to apply the now-repaired source files.
  </Step>
</Steps>

<Warning>
  Always run SFC and DISM from an elevated prompt. Running them as a standard user silently fails without reporting an error.
</Warning>

***

## Step 7 — Test RAM with Windows Memory Diagnostic

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

<Steps>
  <Step title="Launch Windows Memory Diagnostic">
    ```powershell theme={null}
    mdsched.exe
    ```

    Choose **Restart now and check for problems**. The tool runs before Windows loads and takes 10–20 minutes depending on RAM size.
  </Step>

  <Step title="Review the results">
    After reboot, results appear as a notification. To retrieve them later:

    ```powershell theme={null}
    Get-WinEvent -LogName System |
        Where-Object { $_.Id -eq 1201 -or $_.Id -eq 1101 } |
        Select-Object -First 3 | Format-List TimeCreated, Message
    ```
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Tip>
  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.
</Tip>

***

## 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.