Fix PAGE_FAULT_IN_NONPAGED_AREA in Windows 11

Most people who hit PAGE_FAULT_IN_NONPAGED_AREA on Windows 11 go straight to buying new RAM. Don't — not yet. This bug check does show up with bad memory sometimes, but in the dumps I've actually looked at, a driver or a corrupted NTFS volume is behind it at least as often, and those cost nothing to rule out first.

What does PAGE_FAULT_IN_NONPAGED_AREA actually mean?

It's bug check 0x00000050. Microsoft's official reference for this bug check puts it simply: something in the kernel referenced a piece of system memory that's invalid, or that pointed at memory which had already been freed. Nonpaged memory is the part of RAM the kernel guarantees will never be swapped to disk — drivers and kernel code that must always be resident use it, because paging out at the wrong moment would crash the system. When something tries to read or write to a nonpaged address that's invalid, was already freed, or never existed, Windows can't protect that access with an exception handler, so it bugchecks instead of quietly corrupting data.

Microsoft's documentation for this code names the same short list of causes every time it comes up: a faulty system service, faulty driver code, antivirus software, a corrupted NTFS volume, or failing hardware — specifically main memory, L2 cache, or video RAM. That's a wide net on purpose. This is a generic memory-safety violation, not a single component reporting a fault the way WHEA_UNCORRECTABLE_ERROR does — so don't assume you know the cause until you've actually looked.

How do I tell which of those five causes I actually have?

Open Event Viewer, go to Windows Logs → System, and find the "The computer has rebooted from a bugcheck" entry closest to your crash time. It lists four hex parameters after 0x00000050 — the second one tells you whether it was a read (0) or write (1) at the bad address, and if a driver name was identified, Windows prints it right on the blue screen itself before it restarts. Write that name down before you do anything else. If nothing legible shows and you can boot normally, check C:\Windows\Minidump for a .dmp file with a timestamp matching the crash — you don't need WinDbg installed to at least confirm one exists and note its filename for later if a tech asks.

What you see	Confirming check	Fix
Driver name printed on the blue screen or in the dump	Check that driver's version against the vendor's current release; note if it was updated right before crashes started	Update to current version, or roll back if the crash started right after an update
Crashes started after installing new hardware or a driver	Device Manager → check for yellow warning icons; Reliability Monitor timeline around the install date	Uninstall the new driver, get the current one from the vendor, not Windows Update's generic version
No specific driver named, crashes are random	`chkdsk /f` on the system volume for NTFS corruption; Windows Memory Diagnostic for RAM	Repair the volume, or replace/reseat memory if the diagnostic reports errors
Third-party antivirus installed	Check whether crashes stopped during a clean boot with the AV's real-time protection off temporarily	Update the AV to current version, or switch to Microsoft Defender if it keeps recurring
Crash happens specifically under heavy GPU load	Update GPU driver from the vendor's site (not the Windows Update generic driver) and check GPU temps during the workload	Reinstall GPU driver clean via the vendor's own uninstall/DDU-style option, then reinstall current version

Is there an official fix I should check for before doing any of this myself?

Yes — check it before touching drivers or hardware. Open Settings → Windows Update → Update history and see if a cumulative update landed right before the crashes started. If it did, search that specific KB number on support.microsoft.com; Microsoft documents known-issue rollbacks for cumulative updates when a patch causes regressions, and if one exists for your build it supersedes any manual fix below. Separately, run Windows Update's optional driver updates (Settings → Windows Update → Advanced options → Optional updates) — a stale storage or chipset driver bundled by Windows Update is a common, boring, easily-fixed cause of this exact bug check.

What fixes should I run, and in what order?

Check the system volume for NTFS corruption

Corrupted NTFS metadata is one of Microsoft's own documented causes for this bug check, and it's non-destructive to check. From an elevated Command Prompt:

chkdsk C: /f /r

Since C: is your boot volume, it'll ask to schedule the check on next restart — say yes and reboot. Expect output like:

Stage 1: Examining basic file system structure...
  393216 file records processed.
Stage 2: Examining file name linkage...
  ...
Windows has checked the file system and found no problems.

If it finds and fixes errors instead, that's your answer, and you should let it complete a second pass to confirm the fix held. If it comes back clean, move on — don't keep re-running it hoping for a different result.

Update or roll back the driver you identified

If Event Viewer or the blue screen itself named a driver, go straight to the vendor's site for the current version — not the generic one Windows Update installs, which is often a version or two behind for GPUs and storage controllers. If the crash started right after you updated that same driver, roll it back instead: Device Manager → right-click the device → Properties → Driver tab → Roll Back Driver. That button is greyed out if no previous driver package is stored, in which case download the last known-good version directly from the vendor.

Test with a clean boot to isolate third-party software

Run msconfig, switch to Selective Startup with "Load system services" checked and "Load startup items" unchecked, then use the Services tab's "Hide all Microsoft services" option before disabling what's left. Reboot and use the machine normally for a day. If the crashes stop, re-enable services in batches until they come back — that narrows it to a specific piece of third-party software, usually antivirus, VPN, or backup software that hooks deep into the kernel.

Third-party antivirus is a disproportionately common culprit for kernel-mode bug checks because its real-time scanning drivers run at a privilege level where a bug can take down the whole system, not just the antivirus process. If you're chasing an unexplained 0x50 and running third-party AV, updating it — or temporarily switching to Microsoft Defender to see if the crashes stop — is worth doing before you assume hardware.

Run Windows Memory Diagnostic only after the software checks are done

Search for "Windows Memory Diagnostic" in the Start menu, or run mdsched.exe, and restart to test. Results land in Event Viewer under Windows Logs → System, source MemoryDiagnostics-Results — search for that source rather than scrolling, since the tool doesn't pop up a result on screen after reboot. If it reports hardware errors, reseat the RAM and retest with one stick at a time before you buy a replacement; a poorly seated stick produces the same diagnostic failure as a genuinely bad one.

Last resort: driver isolation with Driver Verifier

If nothing above turns up an answer and the crashes keep happening with no driver named, Driver Verifier can force a marginal third-party driver to fail faster and more visibly, which at least gives you a name to act on. Run it from an elevated Command Prompt:

verifier /standard /driver *

Set a System Restore point first — Verifier can make an unstable system crash more often, not less, while it's enabled, and on some machines it prevents a clean boot entirely. If that happens, boot into Safe Mode and run verifier /reset to turn it back off. Use it as a short diagnostic window, not a permanent setting.

Does this ever turn out to be nothing you did?

Occasionally, yes. A one-off PAGE_FAULT_IN_NONPAGED_AREA after months of stability, with no repeat and nothing found in Event Viewer, chkdsk, or the memory diagnostic, is sometimes just a transient fault — a driver hit a rare race condition once and hasn't since. I don't chase those. If it happens once and doesn't recur within a couple of weeks of normal use, I don't treat it as an open problem. Where this advice stops applying is if you're getting it every single boot before you can even log in — at that point it's not a driver you can uninstall from within Windows, and you're into Safe Mode, Startup Repair, or a bootable environment to run chkdsk and swap RAM before Windows loads at all.

Checked Event Viewer for the driver name and the four bugcheck parameters
Checked for a known-issue rollback tied to a recent cumulative update
Ran chkdsk C: /f /r and let it complete
Updated or rolled back the specific driver identified
Ruled out third-party antivirus or backup software with a clean boot
Ran Windows Memory Diagnostic and checked MemoryDiagnostics-Results, not just the on-screen prompt
Used Driver Verifier only as a last, temporary diagnostic step