Bug Check 0x50: PAGE_FAULT_IN_NONPAGED_AREA
The PAGE_FAULT_IN_NONPAGED_AREA bug check has a value of 0x00000050. This indicates that invalid system memory has been referenced. Typically the memory address is wrong or the memory address is pointing at freed memory.
Important
This article is for programmers. If you're a customer who has received a blue screen error code while using your computer, see Troubleshoot blue screen errors.
PAGE_FAULT_IN_NONPAGED_AREA Parameters
| Parameter | Description |
|---|---|
1 |
Memory address referenced |
2 |
After Windows 1507 (TH1) Version - x64 0: Read operation 2: Write operation 10: Execute operation After Windows 1507 (TH1) Version - x86 0: Read operation 2: Write operation 10: Execute operation After Windows 1507 (TH1) Version - Arm 0: Read operation 1: Write operation 8: Execute operation Before Windows 1507 (TH1) Version x64 / x86 0: Read operation 1: Write operation |
3 |
Address that referenced memory (if known) |
4 |
Type of page fault 0x0 - NONPAGED_BUGCHECK_FREED_PTE - The address referenced is on a page table entry marked as free. 0x2 - NONPAGED_BUGCHECK_NOT_PRESENT_PAGE_TABLE The address referenced does not have a valid active page table entry. 0x03 - NONPAGED_BUGCHECK_WRONG_SESSION - An attempted reference to a session space address was made in the context of a process that has no session. Typically this means the caller is improperly trying to access a session address without correctly obtaining an object reference to the correct process and attaching to it first. This bugcheck & subtype was last used in Windows 10 RS3. In Windows 10 RS4 and above, this error is instead surfaced as 0x02 (NONPAGED_BUGCHECK_NOT_PRESENT_PAGE_TABLE). 0x04 - NONPAGED_BUGCHECK_VA_NOT_CANONICAL - An attempted reference to a non-canonical (illegal) virtual address (Parameter 1) was attempted. The caller should not ever be trying to access this address. 0xF - NONPAGED_BUGCHECK_USER_VA_ACCESS_INCONSISTENT - Kernel mode code attempted to access a user mode virtual address when such access is not allowed. |
If the driver responsible for the error can be identified, its name is printed on the blue screen and stored in memory at the location (PUNICODE_STRING) KiBugCheckDriver. You can use the debugger dx command to display this - dx KiBugCheckDriver.
Cause
Bug check 0x50 can be caused by the installation of a faulty system service or faulty driver code. Antivirus software can also trigger this error, as can a corrupted NTFS volume.
It could also occur after the installation of faulty hardware or in the event of failure of installed hardware (usually related to defective RAM, be it main memory, L2 RAM cache, or video RAM).
Remarks
Event Log: Check the System Log in Event Viewer for additional error messages that might help pinpoint the device or driver that is causing the error. For more information, see Open Event Viewer. Look for critical errors in the system log that occurred in the same time window as the blue screen.
Resolving a faulty driver: Examine the name of the driver if that was listed on the blue screen or is present in the event log. Contact the driver vendor to see if an updated driver is available.
Resolving a faulty system service problem: Disable the service and confirm that this resolves the error. If so, contact the manufacturer of the system service about a possible update. If the error occurs during system startup, investigate the Windows repair options. For more information, see Recovery options in Windows 10.
Resolving an antivirus software problem: Disable the program and confirm that this resolves the error. If it does, contact the manufacturer of the program about a possible update.
Resolving a corrupted NTFS volume problem: Run Chkdsk /f /r to detect and repair disk errors. You must restart the system before the disk scan begins on a system partition. Contact the manufacture of the hard driver system to locate any diagnostic tools that they provide for the hard drive sub system.
Windows Memory Diagnostics: Run the Windows Memory Diagnostics tool, to test the physical memory. Select the Start button, and then select the Control Panel. In the search box, type Memory, and then select Diagnose your computer's memory problems. After the test is run, use Event viewer to view the results under the System log. Look for the MemoryDiagnostics-Results entry to view the results.
Resolving a faulty hardware problem: If hardware has been added to the system recently, remove it to see if the error recurs. If existing hardware has failed, remove or replace the faulty component. You should run hardware diagnostics supplied by the system manufacturer. For details on these procedures, see the owner's manual for your computer.
For general blue screen troubleshooting information, see Analyze Bug Check Blue Screen Data and Advanced troubleshooting for Stop error or blue screen error issue.
Resolution
To determine the specific cause and to create a code fix, programming experience and access to the source code of the faulting module, is required.
Typically, the referenced address is in freed memory or is simply invalid. This cannot be protected by a try - except handler -- it can only be protected by a probe or similar programming techniques. For information on buffer handling and probes in file system drivers, see Buffer Handling. For information on best practices for driver development, and common mistakes made by driver developers, see Surface Team Driver Development Best Practices.
Use the !analyze debug extension with the -v verbose option to display information about the bug check to work to determine the root cause.
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: ffffffff00000090, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff80240d322f9, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 000000000000000c, (reserved)
In this example Parameter 2 indicates that the bug check occurred when an area of memory was being read.
Look at all of the !analyze output to gain information about what was going on when the bug check occurred. Examine MODULE_NAME: and the FAULTING_MODULE: to see which code is involved in referencing the invalid system memory.
Look at the STACK TEXT for clues on what was running when the failure occurred. If multiple dump files are available, compare information to look for common code that is in the stack.
Use the .trap command provided in the !analyze output to set the context.
TRAP_FRAME: fffff98112e8b3d0 -- (.trap 0xfffff98112e8b3d0)
Use debugger commands such as use kb (Display Stack Backtrace) to investigate the faulting code.
Use the lm t n to list modules that are loaded in the memory.
Use the d, da, db, dc, dd, dD, df, dp, dq, du, dw (Display Memory) command to investigate the areas of memory referenced by parameter 1 and parameter 3.
2: kd> db ffffffff00000090
ffffffff`00000090 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
ffffffff`000000a0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
ffffffff`000000b0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
ffffffff`000000c0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
ffffffff`000000d0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
ffffffff`000000e0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
ffffffff`000000f0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
ffffffff`00000100 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
In this case doesn't look like there is data in this area of memory in parameter 1, which is the area of memory that was attempting to be read.
Use the !address command to look at parameter 3 which is the address of the instruction which referenced the bad memory.
2: kd> !address fffff80240d322f9
Usage: Module
Base Address: fffff802`40ca8000
End Address: fffff802`415fb000
Region Size: 00000000`00953000
VA Type: BootLoaded
Module name: ntoskrnl.exe
Module path: [\SystemRoot\system32\ntoskrnl.exe]
Use u, ub, uu (Unassemble)Dissasemble with parameter 3, to examine the which referenced the bad memory. For more information on X64 processor and assembly language see The x64 Processor.
2: kd> u fffff80240d322f9
nt!RtlSubtreePredecessor+0x9:
fffff802`40d322f9 488b4810 mov rcx,qword ptr [rax+10h]
fffff802`40d322fd eb07 jmp nt!RtlSubtreePredecessor+0x16 (fffff802`40d32306)
fffff802`40d322ff 488bc1 mov rax,rcx
fffff802`40d32302 488b4910 mov rcx,qword ptr [rcx+10h]
fffff802`40d32306 4885c9 test rcx,rcx
fffff802`40d32309 75f4 jne nt!RtlSubtreePredecessor+0xf (fffff802`40d322ff)
fffff802`40d3230b c3 ret
fffff802`40d3230c c3 ret
Use ub to dissassemble backwards from the a given address.
Use the r (Registers) command to examine what was being executed as the system bug checked.
2: kd> r
Last set context:
rax=ffffffff00000080 rbx=0000000000000000 rcx=ffffa68337cb7028
rdx=7a107838c48dfc00 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80240d322f9 rsp=ffff840c96510958 rbp=ffffffffffffffff
r8=ffffffffffffffff r9=0000000000000000 r10=7ffffffffffffffc
r11=ffff840c96510a10 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=0000 es=0000 fs=0000 gs=0000 efl=00010282
nt!RtlSubtreePredecessor+0x9:
fffff802`40d322f9 488b4810 mov rcx,qword ptr [rax+10h] ds:ffffffff`00000090=????????????????
In this case fffff80240d322f9 is in the instruction pointer register, rip.
The !pte and !pool command may also be used to examine memory.
Use !memusage and to examine the general state of the system memory.
For more information on Windows memory usage, see Windows Internals 7th Edition Part 1 by Pavel Yosifovich, Mark E. Russinovich, David A. Solomon and Alex Ionescu.
Driver Verifier
Driver Verifier is a tool that runs in real time to examine the behavior of drivers. For example, Driver Verifier checks the use of memory resources, such as memory pools. If it sees errors in the execution of driver code, it proactively creates an exception to allow that part of the driver code to be further scrutinized. The driver verifier manager is built into Windows and is available on all Windows PCs. Use Driver Verifier to track down the specific cause of a failure.
To start the driver verifier manager, type Verifier at a command prompt. You can configure which drivers you would like to verify. The code that verifies drivers adds overhead as it runs, so try and verify the smallest number of drivers as possible. If a faulting driver was identified, select it. For more information, see Driver Verifier.