Fix PAGE_FAULT_IN_NONPAGED_AREA on Windows 11

The system needed data from a chunk of memory that’s supposed to always be resident — nonpaged pool, the stuff Windows never swaps to disk because it needs instant access — and the data wasn’t there. Either the RAM cell holding it went bad, or a driver wrote garbage over it, or the page file on disk is corrupted. Stop code 0x00000050. The blue screen sometimes names a .sys file, sometimes just says ntoskrnl.exe which isn’t helpful by itself.

Check Event Viewer first. Win+X, Event Viewer, Windows Logs, System. Look for the BugCheck entry — the first parameter is the memory address that was referenced, and the second tells you the type of access: 0 for a read, 2 for a write, 0x10 for an execute (older Windows versions used 1 for a write). A write fault usually points at a driver actively corrupting memory. A read fault could be bad RAM, bad page file, or a driver trying to read from memory it already freed.

When It Names a Driver

If the blue screen or Event Viewer shows a specific .sys file, that’s your starting point. Common ones with this particular stop code: win32kfull.sys (display subsystem, usually an outdated GPU driver), ntfs.sys (filesystem driver — usually means a failing drive rather than a driver bug), and ndis.sys or various network adapter .sys files.

A common case: a Surface Pro 9 crashing every couple hours with PAGE_FAULT naming win32kfull.sys, running the November 2025 Intel Iris Xe driver that Windows Update pushed. Rolling back to the October version through Device Manager stops it. Driver updates delivered through Windows Update are occasionally withdrawn after problems like this surface, so rolling back is a reasonable first move.

For any driver-specific crash, the sequence is the same: Safe Mode, roll back or uninstall the driver, restart, install a known-good version from the manufacturer’s website. If it’s the GPU driver, DDU clean install is the proper method — just updating on top of a corrupted driver installation doesn’t always clear the problem.

When It Doesn’t Name Anything

No .sys file, or just ntoskrnl.exe — suspect RAM or page file. If your blue screen says MEMORY_MANAGEMENT instead of PAGE_FAULT, same diagnostic — different stop code, overlapping causes. But if it names a .sys driver and reads SYSTEM_THREAD_EXCEPTION_NOT_HANDLED, that one is driver-first, not RAM-first — start from the filename instead.

The page file is the easy one to rule out. This is the file Windows uses as overflow when physical RAM fills up. If it’s on a dying sector of the drive, any attempt to swap data in or out of it hits a read error and you get PAGE_FAULT. Open System Properties (Win+R, sysdm.cpl), Advanced tab, Performance Settings, Advanced tab, Virtual Memory Change. Uncheck “Automatically manage,” set it to System managed for your C: drive specifically, click Set, restart. This forces Windows to rebuild the page file from scratch. If the crash was a corrupted page file, this fixes it.

If that doesn’t help, or if the crashes happen when you’re not even close to using all your RAM, suspect the physical memory. Same story as every other memory-related blue screen — MemTest86 from a USB boot, overnight, minimum four passes. Windows Memory Diagnostic misses a lot of what MemTest86 finds. Some machines only crash when ambient temperature is high — summer afternoons, for example. A RAM stick with a marginal cell can work fine cool but fail when the inside of the case warms up, so MemTest86 may only catch it when run with the case side panel on and the room warm. Weird, but memory faults don’t always show up under ideal test conditions.

If MemTest86 comes back clean and the page file rebuild didn’t help, run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth from an admin Command Prompt. Corrupted system files in the nonpaged pool area cause the same crash pattern. Our SFC guide covers what to do when those commands find but can’t fix problems.

This stop code is one of the harder ones to nail down because it sits at the intersection of RAM, storage, and drivers. If you’ve been chasing it for more than a couple hours, send us your crash dump files — they’re in C:\Windows\Minidump and they contain the exact faulting address and call stack that pinpoints the cause.