PAGE_FAULT_IN_NONPAGED_AREA 0x00000050 – what the stop code really means

Fix it now

0x00000050 means invalid system memory was referenced – typically an address that is wrong, or one pointing at memory that has already been freed. Microsoft’s own cause list names a faulty driver or system service, antivirus software, a corrupted NTFS volume and faulty hardware, in that order.

sfc /scannow
chkdsk C: /f /r
fltmc

1. Get parameters 2 and 4 from the BugCheck event in the System log or from !analyze -v on the newest dump. Parameter 2 says whether it was a read (0), a write (2) or an execute (10) on x64 and x86; parameter 4 says what kind of page fault it was.
2. If the dump names a third-party driver, that is where to start. Get the current build from the hardware vendor rather than letting Windows Update choose one.
3. Microsoft names antivirus software explicitly among the causes. Disable the third-party agent and confirm whether the crash stops – that test is the diagnosis, not a fix.
4. Run chkdsk C: /f /r. A corrupted NTFS volume is a documented cause and the check is cheap.
5. Test memory. Type Windows Memory Diagnostics at Start, run the extended test mix, and read the results in the System log.

driverquery /si /fo table gives you a signed-driver inventory, and pnputil /enum-drivers lists the installed driver packages by their oem names, which is what you need to remove one cleanly.

If the machine is stable after the driver or volume repair, stop here. The next section explains how to read the parameters and which sibling codes change the answer.

Why it happens

Nonpaged kernel memory is memory the system has promised will always be resident. Code running at a raised IRQL relies on that promise, because it cannot take a page fault – there is no safe point at which to wait for a disk read. 0x00000050 is what happens when that promise turns out to be false: a reference was made to an address that is not backed by anything valid. Microsoft’s description is deliberately plain – the memory address is wrong, or it is pointing at freed memory.

The parameters are the whole diagnostic and they are not on the stop screen. Parameter 1 is the address referenced. Parameter 2 says what was being done to it: on current x64 and x86 builds, 0 is a read, 2 is a write and 10 is an execute; on Arm the values are 0, 1 and 8. Parameter 3 is the address that made the reference, where it is known. Parameter 4 is the type of page fault, and it is the most informative of the four.

That parameter 4 table separates cases that look identical otherwise. 0x0 means the address sits on a page table entry marked free – a use-after-free. 0x2 means there is no valid active page table entry at all. 0x3 means a session space address was referenced from a process with no session. 0x4 means a non-canonical, illegal virtual address, which usually means a pointer was built from something that was not a pointer. 0xF means kernel-mode code touched a user-mode address where that is not allowed.

Two codes in this family are commonly confused with 0x50 and should not be. 0x000000C5 is not a pool corruption detector; its published description is the same as 0x000000D0 – invalid memory accessed at too high an IRQL, almost certainly because a driver corrupted the system pool – and the only thing that separates the two is allocation size, with 0xC5 the small case. 0x000000D8 and 0x000000DA are about system page table entries rather than pool at all.

Full reference

The parameters, in the form you will actually use them

The siblings, and why they are not the same fault

When the machine is running out of page table entries

0x000000D8 is the one code here with a name written on it. Parameter 1 points at the name of the driver that consumed the most system PTEs, while the call stack shows the driver that happened to be asking when the last one ran out. Those are frequently different, and the first is the one to act on. It is a slow failure that shows up after long uptime, so a machine that only crashes after weeks is a candidate.

0x000000DA is a misuse rather than an exhaustion: a PTE routine used in an improper way, with parameter 1 naming which – duplicate frees of a mapping, mismatched frees, MDL misuse, and mapping ownership errors. It is also what 0x000000DB turns into when you set TrackPtes to 3, so if you enabled that diagnostic on purpose, this is the result you were after.

Getting a clean answer out of a driver replacement

1. Record the current driver version before you change anything, so a rollback is possible.
2. Take the replacement from the hardware vendor’s page for that exact model, not from a driver aggregator.
3. On laptops, prefer the notebook manufacturer’s build where they publish one – it carries the panel and switchable-graphics customisation generic packages do not.
4. Remove the old package with pnputil /delete-driver <oem#.inf> /uninstall rather than leaving it available for Windows to reinstall.
5. Restart twice and run the workload that crashed before calling it fixed.

Checks worth doing before you conclude it is hardware

• sfc /scannow, then DISM /Online /Cleanup-Image /RestoreHealth if it reports files it could not repair.
• The System log around each crash, for storage or device errors that arrive just before the bug check.
• Device Manager for anything marked with an exclamation point.
• fltmc for filters belonging to products that are no longer installed.
• Whether more than one real-time scanner is installed. Microsoft names antivirus among the causes of this specific code, which is unusual and worth taking at face value.

Every code this article covers

Confirm the fix worked

1. chkdsk C: /f /r completes with no unrecoverable errors reported.
2. sfc /scannow reports no integrity violations.
3. Windows Memory Diagnostics passes an extended run, with the result recorded in the System log.
4. The workload that used to crash the machine runs to completion twice.
5. fltmc lists only filters belonging to products that are installed and supported.

Questions people ask about this