⚠ CrashDecoder

0x00000050 PAGE_FAULT_IN_NONPAGED_AREA

Windows divides kernel memory into paged and non-paged pools. Non-paged memory is guaranteed to stay in physical RAM - that is the entire point of it. When something references an address in that region and the data is not there, a guarantee has been broken, and the most common reason a guarantee like that breaks is that the hardware holding it is faulty.

Updated 2026-07-27Stop errorAlso written: 0x50, PAGE FAULT IN NONPAGED AREA, page_fault_in_nonpaged_area

What you are looking at

:(

Your PC ran into a problem and needs to restart.

Stop code: PAGE_FAULT_IN_NONPAGED_AREA

In Event Viewer the matching entries look like this:

Log Name:      System
Source:        BugCheck
Event ID:      1001
Level:         Error

The computer has rebooted from a bugcheck.  The bugcheck was: 0x00000050 (0xffffb00c3a2e0000, 0x0000000000000000, 0xfffff80369a1c2b4, 0x0000000000000002).

What the error actually means

Most kernel memory can be paged out to disk when it is not needed and fetched back on demand. A page fault is the ordinary mechanism for that, and it happens constantly without anyone noticing.

Non-paged pool is different. Memory allocated there is pinned in physical RAM and can never be written out, because it must be accessible at times when the paging machinery cannot run. Interrupt handlers and other high-priority code depend on that promise.

So a page fault on a non-paged address is a contradiction. The data was supposed to be sitting in RAM and it was not. Either the physical memory holding it failed, or a driver freed the allocation and then kept using the pointer, or the address being used was never valid in the first place.

That first possibility is why this code carries more hardware weight than most.

Reading the parameters

All four carry information, and parameter 4 is far more useful than most write-ups suggest. Note the version caveat on parameter 2 - the values changed and a lot of older guidance is now wrong.

ParameterWhat it holds
1The memory address referenced. A small value near zero means a null pointer with an offset - a software bug. A large, plausible-looking kernel address that is simply not valid suggests the allocation was freed early or the memory holding it is faulty.
2The operation attempted. On x64 and x86 from Windows 10 version 1507 onward: 0 read, 2 write, 0x10 execute. Before 1507 it was 0 read and 1 write only. On Arm it is 0 read, 1 write, 8 execute. Guidance written before 1507 will tell you 2 means execute - on a current x64 machine it means write.
3The address that referenced the memory, if known. Resolves to a driver in a debugger, and !address on it identifies the owning module directly.
4The type of page fault - not reserved. 0x0 means the address sits on a page table entry marked free; 0x2 means it has no valid active page table entry; 0x4 means a non-canonical, illegal virtual address was referenced, which the caller should never have attempted; 0xF means kernel-mode code tried to access a user-mode virtual address where that is not allowed. Value 0x3 was a session-context error, last used in Windows 10 RS3 and since folded into 0x2.

What actually triggers it

The ordering here reflects a genuine tilt toward hardware, which is not true of most stop codes.

CauseHow oftenDetail
Failing RAMCommonThe leading cause. A bad cell means data written to non-paged pool does not read back correctly. Alongside 0x1A, this is one of the two codes where a memory test most often finds a real fault.
A driver using freed memoryCommonA driver releases an allocation and then keeps using the pointer. The memory has been returned to the system and is no longer valid at that address. This is a classic use-after-free and Driver Verifier catches it well.
Unstable memory profileOccasionalAn XMP or EXPO profile beyond what your specific controller and board can sustain produces intermittent corruption that looks exactly like a failing module.
Failing storage or a corrupt page fileOccasionalCorrupt data arriving from disk lands in memory already wrong. Check drive health before buying RAM.
Anti-virus and filter driversOccasionalSecurity products manage their own kernel allocations aggressively and are a recurring source of use-after-free faults.
Corrupt system filesRarePossible, cheap to rule out, and over-recommended as a first answer.

Narrowing it down

The first parameter tells you which branch you are on, so start there.

Read parameters 1 and 4 together

Pull them from the bugcheck event, or read them in WinDbg with !analyze -v. Parameter 1 is the address; parameter 4 says what kind of fault it was. Where Windows identified a responsible driver you can also print its name directly:

dx KiBugCheckDriver
What it tells you

A small address - under about 0x1000 - is a null-pointer bug in a driver, and hardware is not implicated. A large kernel-looking address means valid memory went missing, which is the hardware-leaning case.

Parameter 4 sharpens this considerably. 0x0 - a page table entry marked free - is the signature of memory that was released and then used, pointing at a use-after-free. 0x4 - a non-canonical address - means the pointer itself was garbage rather than merely stale, which leans toward corruption. 0xF means kernel code reached into user space illegally, which is a specific driver bug.

Test memory before anything else

Given how strongly this code points at RAM, do the memory test early rather than after a week of driver reinstalls. MemTest86 from USB, four passes minimum, at stock settings with XMP disabled.

What it tells you

Any error ends the investigation. A clean run at stock, followed by errors with the profile enabled, means the modules are sound and the profile is not.

Check whether the named driver is consistent

Collect several dumps and compare which module each one blames.

What it tells you

The same driver every time is a use-after-free bug in that driver - update or remove it. A different driver each time is memory corruption, and no amount of driver work will help.

Fixes, cheapest first

Memory testing comes first here, which is a departure from the usual order.

  1. Test the RAM properly

    Effort: Overnight · Risk: None

    MemTest86 booted from USB, minimum four passes. Disable XMP or EXPO first so you are testing the modules rather than the profile.

    1. Run with all modules installed to establish whether a fault exists.
    2. If errors appear, test each module individually in the same slot.
    3. If every module passes alone but the full set fails, suspect the slot, the board or the memory controller.
    4. Re-enable the profile only after the modules are proven clean at stock.

  2. Return memory to stock settings

    Effort: 10 minutes · Risk: Low

    Disable XMP, EXPO and any manual tuning. Run for several days. This distinguishes a defective module from an over-ambitious profile, and it is the cheapest test available.

  3. Check drive health

    Effort: 20 minutes · Risk: None

    Read SMART attributes with CrystalDiskInfo and run chkdsk C: /scan. Look at reallocated and pending sectors on a hard drive, and at remaining life, media errors and available spare on an SSD.

    Update the drive's firmware if the vendor has a newer release - SSD firmware bugs that corrupt data under specific conditions are real and are fixed this way.

  4. Update or remove the named driver

    Effort: 20 minutes · Risk: Low

    If the dumps consistently name one module, that driver is the suspect. Install the vendor's current version, or roll back if the crashes started after an update. If it belongs to software you do not need, uninstall it outright.

  5. Catch the use-after-free with Verifier

    Effort: Several hours · Risk: Medium

    Driver Verifier's Special Pool option is designed for exactly this failure. It arranges allocations so that touching freed memory faults immediately and identifiably, rather than corrupting something else and surfacing later.

    1. Create a restore point and confirm you can reach Safe Mode.
    2. Run verifier, choose custom settings, enable Special Pool and Pool Tracking.
    3. Select non-Microsoft drivers only.
    4. Use the machine until it crashes, then read the dump.
    5. Run verifier /reset and reboot.
    Watch out

    Verifier deliberately increases crashes and can cause a boot loop. Run verifier /bootmode resetonbootfail before enabling any checks - it makes Verifier disable itself automatically if the machine fails to start, which removes most of the risk. Your manual exit is Safe Mode followed by verifier /reset. Full settings and the escape route are in the Driver Verifier guide.

When it is the hardware, not Windows

This code starts with hardware already likely. These push it further:

If memory tests clean, the drive is healthy, and Verifier does not implicate a driver, you are looking at the memory controller or the board. That is a harder claim to make - so keep the dumps and the test results, because a warranty conversation backed by four clean MemTest passes and a set of dumps naming different modules is a much stronger position than a description of symptoms.

Frequently asked

Is this always bad RAM?

No, but it is the way to bet before you have other evidence. A driver using freed memory produces an identical stop code, and that case is common enough that you should check whether the named module is consistent across crashes before spending money. Same driver every time means software; different driver each time means memory.

It happens when I open one particular application. Is it still hardware?

It can be. An application that reliably triggers it is not proof of a software bug - it may simply be the thing that allocates enough memory to reach the faulty region. If a bad cell sits in an area only touched under heavy load, the application that creates that load will look responsible. Test the memory before accepting the application as the cause.

How is this different from MEMORY_MANAGEMENT?

0x1A means the memory manager found its own bookkeeping in an impossible state. 0x50 means a specific reference to a specific address failed. Different detection points, largely overlapping causes - and seeing both on one machine is a strong combined signal for failing memory, since they represent two independent checks catching the same underlying corruption.