BSOD Master Guide ⚡ PAGE_FAULT, IRQL, MEMORY & All Stop Errors Fixed

Note the Stop Code First — Before You Touch Anything

A blue screen is not one problem; it is Windows reporting dozens of different failures in the same colour. The fix depends entirely on the stop code written on the screen, so the first step is always the same: take a photo of the blue screen, write down the exact code (for example PAGE_FAULT_IN_NONPAGED_AREA or 0x00000050), and note three things — when it happens (at boot, in a game, randomly), what changed just before it started (a new driver, new RAM, a Windows update, an overclock), and whether it repeats at the same moment or moves around. A code that always appears at the same action points at software; a code that changes every crash points at hardware, usually RAM.

PAGE_FAULT_IN_NONPAGED_AREA (0x50) — Memory or Driver

This code means code tried to read a page of memory that does not exist or is not valid. In practice the cause is one of two families. First, RAM: a faulty stick, a badly seated stick, or unstable XMP/overclock settings corrupting memory — test it as shown in Step 4. Second, drivers: a driver (very often graphics, network or antivirus filter drivers) referencing freed or wrong memory. If this code started right after a driver update, roll that driver back in Device Manager or uninstall it in Safe Mode; if it started after adding RAM, remove the new stick and test again. Run the memory test before blaming software — a PAGE_FAULT with random other codes alongside it is a RAM signature.

IRQL_NOT_LESS_OR_EQUAL (0x0A) — A Driver Misbehaving

IRQL_NOT_LESS_OR_EQUAL means kernel code or a driver accessed paged memory at too high an interrupt request level — in plain words, a buggy driver did something it is never allowed to do. This is the most driver-caused code of all: recently updated or newly installed drivers are the prime suspects, especially graphics, Wi-Fi/LAN, chipset and third-party antivirus drivers. The fix order: uninstall or roll back whatever driver changed last; update the remaining drivers from the PC or motherboard maker's official support page (not random driver-updater tools); remove third-party antivirus temporarily to test. Because memory corruption caused by bad RAM can disguise itself as an IRQL crash, run the RAM test too if no driver change explains it.

MEMORY_MANAGEMENT (0x1A) — Test the RAM Properly

MEMORY_MANAGEMENT means Windows' memory manager found its own bookkeeping corrupted — the classic bad-RAM code, though a corrupt page file or a driver writing where it should not can also trigger it. Test first, conclude second. Start with the built-in tool: run mdsched.exe (Windows Memory Diagnostic), choose "Restart now and check for problems", and let it complete. For a verdict you can trust, use MemTest86 from a bootable USB and let it run multiple full passes — errors that appear only under long testing are still failures: even a single error means the memory subsystem is faulty. Then isolate: test one stick at a time, in one slot at a time, to find the guilty stick or slot. If the RAM is overclocked or on an XMP/EXPO profile, set it back to stock speeds and retest — RAM that only fails at XMP is still the problem.

WHEA_UNCORRECTABLE_ERROR (0x124) — Real Hardware Is Failing

WHEA is different from the other codes: it is the Windows Hardware Error Architecture reporting that the hardware itself raised an uncorrectable error — most often the CPU, but also a failing power supply, overheating, an unstable overclock, or occasionally a dying drive or motherboard. Software fixes do not cure a genuine WHEA. Work through it physically: remove every overclock (CPU, RAM XMP included) and test at stock; check temperatures under load and clean/repaste if the CPU is cooking; reseat RAM and power cables; test with a known-good power supply if crashes happen under load; and check Event Viewer's WHEA-Logger entries for which component reported the error. If WHEA crashes continue at stock settings with good temperatures, the CPU or motherboard is the likely end of the road.

Repair System Files — DISM First, Then SFC

For the software family of codes — CRITICAL_PROCESS_DIED (0xEF), SYSTEM_SERVICE_EXCEPTION (0x3B), and crashes caused by corrupt Windows files — repair the system image before anything drastic. Open Command Prompt as Administrator and run the two commands exactly as shown, in this order: DISM repairs the component store that SFC depends on, then SFC checks and replaces corrupt system files. Let each one finish completely; a restart between them is fine.

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Two neighbours worth knowing: INACCESSIBLE_BOOT_DEVICE (0x7B) after a BIOS change usually means the storage mode was switched (RAID/RST vs AHCI) or the boot drive's driver is missing — set the mode back, do not reinstall. DPC_WATCHDOG_VIOLATION (0x133) most often traces to a stuck driver or an SSD firmware/storage driver problem — update the storage and chipset drivers from the maker first. And if Windows will not stay up long enough to work, do all of this from Safe Mode (hold Shift while choosing Restart → Troubleshoot → Advanced options → Startup Settings → Safe Mode), where most third-party drivers never load — a PC that is stable in Safe Mode but crashes normally has just told you the fault lives in a driver or startup service.

Read the Minidump and Confirm the Fix

Every blue screen leaves evidence: a small dump file in C:\Windows\Minidump, named by its date. Open the newest one in a dump reader such as BlueScreenView or WinDbg and read two things — the bug check code (does it match what the screen showed?) and the "caused by driver" module name. Treat names honestly: graphics drivers like nvlddmkm.sys (NVIDIA) and amdkmdag.sys (AMD) blame themselves directly, but ntoskrnl.exe is the Windows kernel — it is where the crash surfaced, not the culprit, so look at the stack and at your RAM test results instead. The fix is confirmed only when the crashes stop in real use and no new .dmp files appear — keep the PC under its normal workload for a few days before calling it solved.