Windows stop code · 0x00000050

0x50 PAGE_FAULT_IN_NONPAGED_AREA

What stop code 0x50 PAGE_FAULT_IN_NONPAGED_AREA means, how to read its four parameters, and the WinDbg commands that find the code that touched bad memory.

Published 2026-10-22 by PerformanceInsights.ai

Short answer: 0x50 means kernel-mode code referenced memory that isn't valid: an address that was never mapped, memory that has already been freed, or a garbage pointer. Parameter 1 is the address it touched and Parameter 3, when Windows knows it, is the instruction that touched it: ln on Parameter 3 names the function and the driver. A buggy or out-of-date driver is the usual cause; antivirus, a corrupted NTFS volume and faulty RAM are the others Microsoft lists.

Parameters

Parameter	Meaning
1	The memory address referenced.
2	The kind of access. After Windows 10 1507 (TH1), on x64 and x86: `0x0` = read, `0x2` = write, `0x10` = execute; on Arm: `0x0` = read, `0x1` = write, `0x8` = execute. Before 1507, on x64 and x86: `0x0` = read, `0x1` = write. WinDbg's own `!analyze` text may still say "0 = read operation, 1 = write operation", so go by this table.
3	The address of the instruction that referenced the memory, if known.
4	The type of page fault: `0x0` `NONPAGED_BUGCHECK_FREED_PTE`, the address is on a page table entry marked free; `0x2` `NONPAGED_BUGCHECK_NOT_PRESENT_PAGE_TABLE`, no valid active page table entry; `0x3` `NONPAGED_BUGCHECK_WRONG_SESSION`, a session address used from a process with no session (until Windows 10 RS3; later reported as `0x2`); `0x4` `NONPAGED_BUGCHECK_VA_NOT_CANONICAL`, a non-canonical address; `0xF` `NONPAGED_BUGCHECK_USER_VA_ACCESS_INCONSISTENT`, kernel code touched a user-mode address where that isn't allowed. Microsoft documents only these; other values (its own example shows `0xc`, labelled reserved) aren't explained.

Source: Microsoft Learn, Bug Check 0x50.

Reading the dump

!analyze -v                 # MODULE_NAME / IMAGE_NAME, and the four arguments
dx KiBugCheckDriver         # the driver Windows named on the blue screen, if any
.trap <address>             # if !analyze shows a TRAP_FRAME, switch to it, then:
kv                          # stack at the faulting instruction
ln <Arg3>                   # function that made the access
ub <Arg3>                   # the instructions just before it
r                           # registers: which one held the bad address
!pte <Arg1>                 # is the address mapped at all
!pool <Arg1>                # is it in pool, and is it freed?
lmvm <driver>               # version and date of the suspect

!pte and !pool need a kernel or complete memory dump. A small minidump usually doesn't contain page tables or pool pages, so an error from them there means "not in this dump", not "not mapped".

Arg3 in a third-party driver: that driver made the bad access. Check lmvm for its version and update it.
Arg3 in ntoskrnl.exe or another Windows module: Windows code followed a bad pointer it was given. Look further down the stack for the third-party driver that passed it in (file-system filters such as antivirus are frequent).
Parameter 4 = 0x0: the page was released, so the code is using memory after it was given back. If !pool also shows a freed pool block, it is a pool use-after-free: the driver at Arg3 may be the victim of whoever freed the block, and Driver Verifier with Special Pool enabled can catch the culprit.
Parameter 4 = 0x4 (non-canonical address): no valid pointer looks like that, so the pointer value itself was corrupted or never set. Find where it came from with ub and r.
Parameter 2 = execute: the CPU tried to run code at an invalid address. Look at the caller on the stack to see where the bad call target came from, typically a corrupted or stale function pointer.

Typical causes and fixes

A faulty or out-of-date driver or system service: update the one named in IMAGE_NAME, on the blue screen or on the stack.
Antivirus software: disable it and see whether the crashes stop, then ask the vendor for an update.
A corrupted NTFS volume: run chkdsk /f /r (on the system volume it runs at the next restart).
Faulty RAM, including video memory, or hardware that was just added: run Windows Memory Diagnostic, and remove the new hardware to test. Random 0x50s in different drivers, or alongside other stop codes, suggest hardware.
If the named driver keeps changing, run Driver Verifier (verifier) on the third-party drivers to catch the real culprit. On a production machine, plan for the extra overhead and possible boot loops; know how to turn it off (verifier /reset from safe mode).

Rather not read the dump yourself?

Upload it to DumpTriage. It runs the debugger, reads the output and sends back the faulting module, the stack and a plain-language root cause (how the analysis works). Cases the automated passes can't settle go to an engineer. Free during the pilot.

Create an account