PAGE_FAULT_IN_NONPAGED_AREA (0x50): Causes and Fixes

Why "nonpaged" makes this crash final

Windows keeps some data in nonpaged memory, which must stay in physical RAM. When code, usually a driver, reads or writes an address there that does not exist or was already released, Windows cannot guess what was meant. Microsoft's page says the problem cannot be caught by a try-except handler, so the system stops instead of risking your data.

That is why one bad driver can crash the whole PC while a normal app that does the same thing would only close itself. Microsoft's own analysis of crashes says 70% come from third-party driver code, 10% from hardware, 5% from Microsoft code, and 15% have unknown causes because memory is too corrupted to read.

The four causes Microsoft lists, and what each looks like

Microsoft's bug check page gives these causes. The order below is the order to test them in, from cheapest to most work.

• A faulty driver or system service: a name such as a .sys file appears on the blue screen, or the crash started right after a driver or program install.
• Antivirus software: the crash began after a security product update. Disable it briefly to test.
• A corrupted NTFS volume: the PC also reports disk errors, or files go missing after unclean shutdowns.
• Hardware, usually defective RAM (main memory, L2 cache or video RAM): the crashes carry different driver names each time, or start after a new memory module was installed.

Read the four parameters in Event Viewer before you change anything

Open Event Viewer, then the System log, and find the critical entry from the time of the crash. Its properties list four values. Parameter 1 is the memory address referenced. Parameter 2 tells the type of access: on x64 Windows, 0 is a read, 2 is a write and 10 is an execute. Parameter 3 is the address of the instruction that did it, if known. Parameter 4 is the page fault type.

Parameter 4 narrows the cause: 0x0 is a freed page table entry, 0x2 means no valid active page table entry, 0x04 is a non-canonical (illegal) address, and 0xF means kernel code touched a user-mode address when that is not allowed.

A worked example using Microsoft's own sample dump

Microsoft's page shows an analysis with Arg1 ffffffff00000090 and Arg2 0. Arg2 of 0 means a read, so a driver tried to read from address ffffffff00000090, where the debugger shows only question marks. There was no data to read.

Arg3, fffff80240d322f9, is the instruction that asked. The debugger resolves it to ntoskrnl.exe, which is a Microsoft file. That alone does not blame Windows, since a driver can pass a bad pointer into a kernel routine. Microsoft's guidance is to look at MODULE_NAME and the stack to see which non-Microsoft driver is further down. You can do the same with the free WinDbg tool and the memory.dmp or Minidump file described below.

Where the crash dump files live

Windows writes a small 256 KB dump to %SystemRoot%\Minidump, and larger kernel, complete or automatic dumps to %SystemRoot%\MEMORY.DMP. To set the type, open Advanced system settings, then the Advanced tab, then Settings under Startup and Recovery, and pick Automatic memory dump under "Write debugging information". Restart to apply it.

In WinDbg, open the dump with File > Open Crash Dump, set the symbol path to https://msdl.microsoft.com/download/symbols, and run !analyze -v. The MODULE_NAME and IMAGE_NAME lines name the driver.

Disk check: chkdsk /f /r and what the exit code means

Microsoft's fix for a corrupted NTFS volume is chkdsk /f /r in an administrator prompt. The /r switch finds bad sectors and recovers readable data and includes /f. If the drive is the system drive, Windows offers to run the scan at the next restart, and on a boot partition it restarts the PC itself after checking.

On a large hard disk, /r can take hours because it reads every sector. On an SSD it is faster, but repeated full scans add write cycles, so run it once, not weekly. The exit codes are 0 for no errors, 1 for errors found and fixed, 2 for cleanup done or not done because /f was missing, and 3 for a disk that could not be checked. To see the result after the restart, open Event Viewer > Application and filter the sources Chkdsk and Wininit.

Memory test: the free tool that is already in Windows

Type Memory in the Control Panel search box and open "Diagnose your computer's memory problems". Choose restart, wait for the test, and after Windows loads read the System log in Event Viewer for the MemoryDiagnostics-Results entry.

If the test reports errors, the module is likely bad. Remove recently added memory first. If you added one stick the day the crashes began, test with that stick out. Microsoft's related MEMORY_MANAGEMENT page (0x1A) also points to this tool, and it says some page-table errors are probably hardware errors.

Driver Verifier is a last resort, and it can make things worse

Driver Verifier is built into Windows; type verifier in an administrator prompt. Microsoft warns that it could cause the computer to crash, and that it uses lots of CPU. Do not verify all drivers at once. Test recently updated or suspicious drivers, in groups of 10-20 at most.

If the PC will not reach the desktop because of it, start Safe mode, where the tool cannot run, and then run verifier /reset and restart. Microsoft says it estimates about 75 percent of stop errors are caused by faulty drivers, which is why this tool exists, but it belongs to testing and debugging, not daily use.

Repair system files: DISM first, then SFC

If the crash looks tied to Windows files, run DISM.exe /Online /Cleanup-image /Restorehealth first and sfc /scannow second, in the same administrator window. Keep it open until verification reaches 100%. Details of any repair land in %windir%\Logs\CBS\CBS.log.

If the PC cannot start, SFC can run offline from the recovery environment with SFC /Scannow /OffBootDir=C:\ /OffWinDir=C:\Windows. Since Windows 10 version 1803 the registry is no longer copied to the RegBack folder, so Microsoft recommends a system restore point for registry damage.

Common mistakes that waste an evening

Skipping the Event Viewer entry, so no driver name is known. Running chkdsk without /f, which only reports and fixes nothing. Reinstalling Windows before testing the RAM. Leaving a new memory module in while running the memory test, which then cannot tell which module is at fault.

If the blue screen shows a file name you do not recognize, Crade can read the screen and explain what the name belongs to.

Who this guide suits

It suits a desktop or laptop you manage yourself, where you can open Device Manager and install drivers. On a work PC, send IT the file name, the time and the four parameters instead of running Driver Verifier, because IT may lock driver versions. If the crash repeats after the driver, disk and memory steps, contact the PC maker with the dump files.