PAGE_FAULT_IN_NONPAGED_AREA: What 0x00000050 Reports

The machine stops with a blue screen carrying the text PAGE_FAULT_IN_NONPAGED_AREA and the stop code 0x00000050. The screen usually names a file, often a .sys driver, and the dump file written to disk records the address that was referenced and the address of the instruction that referenced it. The code is produced when kernel-mode code references an address that should have been valid and resident, and the memory manager finds no valid page behind it. The nonpaged pool is the region of kernel memory that is never allowed to be paged out to disk, because the code that uses it may run at an interrupt level where paging is impossible. A reference into that region is expected to succeed without a disk read. When it does not, the fault is fatal by design: the kernel cannot defer the access or retry it later. Either a driver handed the kernel a pointer to memory it did not own, or faulty memory corrupted a pointer or a kernel structure so that a valid-looking reference led nowhere. The first case is a software defect; the second is failing RAM, an unstable memory setting or a failing memory path. The stop code does not distinguish between them, so the diagnostic work is to separate the two before changing anything.

What the nonpaged pool is and why a fault there is fatal

Windows divides kernel memory into paged and nonpaged pools. Paged pool can be written to disk when physical RAM is under pressure and read back when needed. Nonpaged pool cannot, because the routines that use it, including interrupt service routines and code running at DISPATCH_LEVEL, are not allowed to trigger a page fault that would require disk I/O. A page fault in nonpaged pool therefore means one of two things happened. A driver dereferenced an address that was never valid, or was freed and then reused, and the memory manager found no valid page behind it. Or the pointer was correct when it was stored but faulty memory changed it before it was used, which points at the RAM itself or the path between the CPU and the RAM. The bug check parameters record the referenced address and, in the second parameter, the kind of access, such as a read or a write. The dump file is the only reliable record of which module was executing at the time.

Distinguishing this from IRQL_NOT_LESS_OR_EQUAL

IRQL_NOT_LESS_OR_EQUAL (0x0000000A) is a related but different rule. It fires when code running at an elevated interrupt request level touches paged memory, which is illegal because paging would require a wait the current IRQL forbids. PAGE_FAULT_IN_NONPAGED_AREA fires when memory that should never page is either invalid or corrupt. A driver can produce either code depending on which pointer it mishandles. The repair path overlaps, because both often trace to a third-party driver, but the dump analysis differs: 0x0A points at an IRQL violation, while 0x50 points at an address resolution failure. Treating them as the same fault leads to replacing RAM when the actual problem is a filter driver.

Causes in order of likelihood

A third-party driver is the most common cause. Antivirus and endpoint security products install file system filter drivers that sit between Windows and the disk. Storage drivers, network drivers, and virtualization or backup filter drivers are also frequent. The blue screen often names the driver file, which is the strongest single clue available without a debugger.

Faulty RAM is the next cause. A failing module can return a bit-flipped value from an address that is otherwise valid, and a corrupted pointer or kernel structure then leads to an invalid reference. This cause becomes more likely when the same stop code appears with different driver names across successive crashes, or when the machine crashes under load rather than during a specific operation.

Disk or file system corruption is the third cause. If the page file or a system file is damaged, a driver that reads from it can receive bad data. This is less common than the first two but is cheap to rule out.

A wrong setting is the fourth cause and is more common than a dead disk. Overclocked memory, an XMP profile that the board cannot sustain, a page file that has been disabled or moved to a failing volume, or a third-party driver installed by a utility that has since been removed all produce this code without any hardware fault.

Reading the blue screen and the dump

The file name on the blue screen is the first thing to record. If it names a driver, note the exact path. If it names ntoskrnl.exe or ntkrnlmp.exe, the fault occurred in the kernel itself and the offending driver is not directly named, which shifts weight toward RAM or toward a driver that corrupted kernel structures.

The dump file is written to %SystemRoot%\Minidump by default. Opening it requires a debugger. WinDbg from the Windows SDK can open the minidump and the !analyze -v command prints the faulting module and the stack. That output is the definitive answer to which component was executing. Without a debugger, the file name on the blue screen and the pattern of crashes across time are the available evidence.

windbg -z C:\Windows\Minidump\<dumpfile>.dmp

The debugger opens the dump. Inside the debugger, run the analysis command to print the faulting module, the referenced address, and the stack. If the module is a third-party driver, the repair is to update or remove that driver. If the module is the kernel and the referenced address changes across dumps, suspect RAM.

Testing memory

Windows Memory Diagnostic runs outside Windows and tests physical RAM. It is started with mdsched.exe or from the Start menu. The machine reboots and runs the test. A full pass takes time; a single quick pass can miss intermittent faults. If errors are reported, the RAM is the cause and the fix is to reseat or replace the module. If no errors are reported after a full pass, RAM is less likely but not eliminated, because some faults only appear under thermal load.

mdsched.exe

The command opens the scheduling dialog. The test runs after a restart. Results appear in Event Viewer under Windows Logs > System, source MemoryDiagnostics-Results, after Windows returns.

Checking the disk and system files

Run chkdsk in read-only mode first. It reports file system errors and bad sectors without changing anything. If it reports errors, schedule a repair on the next restart, which requires exclusive access to the volume. A repair can move or truncate data in damaged file system structures, so back up important files before running it if the disk is still readable.

chkdsk C: /scan

The scan reports whether the file system is healthy. A clean result means disk corruption is unlikely to be the cause. Errors mean the repair step is warranted.

chkdsk C: /spotfix

The spotfix repair runs at the next restart and corrects file system metadata. It does not recover user data that was already lost.

System File Checker verifies the protected system files against the component store. If SFC reports corruption it cannot repair, run DISM to repair the component store, then run SFC again.

sfc /scannow

A clean result means the protected files match their expected versions. Corruption reported here means a system file was damaged, which can produce bad data for a driver that reads it.

DISM /Online /Cleanup-Image /RestoreHealth

The command repairs the component store from Windows Update or from a specified source. It requires network access or installation media. A failure here usually means the source files are unavailable, not that the machine is beyond repair.

Driver removal and rollback

If the blue screen names a third-party driver, the repair is to update it from the vendor or remove it. Device Manager allows a driver to be rolled back to the previous version if an update introduced the fault. Removing a security product requires its own uninstaller; deleting its driver files by hand can leave the driver registered and Windows still trying to load it.

A clean boot isolates whether a third-party service is the cause. The steps are in msconfig: disable all non-Microsoft services and all startup items, restart, and observe. If the crash stops, re-enable services in groups to find the offender. This is diagnostic, not a repair; leaving the machine in a clean boot disables security software.

What people get wrong

The natural first move is to replace the RAM, because the stop code mentions memory and the word fault appears in the name. That is a reasonable reading of the message. The code reports a fault in memory, but the memory it refers to is a kernel data structure, not necessarily the physical modules. A driver that writes past the end of its buffer corrupts that structure and produces the same code with healthy RAM. Replacing modules before reading the dump wastes money and leaves the actual defect in place.

The second common mistake is to treat every 0x50 as the same fault. The referenced address and the named module differ between crashes, and the pattern across dumps is the evidence. A single crash with a named driver and a clean memory test points at the driver. Repeated crashes with different modules and no named driver point at RAM.

The third mistake is to disable the page file to stop paging activity. The nonpaged pool is not the page file, and disabling the page file can cause other failures without addressing this one.

When the hardware is fine

If the memory test is clean, the disk scan is clean, and the crash began after a driver update or a BIOS change, the fault is configuration. Reverting the change is the repair. Memory overclock profiles, including XMP, should be returned to the default JEDEC setting for the test period. A page file that has been moved to a failing or removable volume should be returned to the system volume. A driver installed by a utility that has since been uninstalled should be removed through its own uninstaller, not by deleting files.

If all recoverable options are exhausted and the crash persists with clean hardware tests, a repair install of Windows preserves files and applications while replacing system files. A clean install destroys the contents of the system volume and requires a backup first.