What is the cause of this BSOD? PAGE_FAULT_IN_NONPAGED_AREA Bugcheck

Hi,

One of production server, windows 2008 shutdown itself and I am trying to find the reason of this BSOD. Event viewer just tells that it was shutdown unexpectedly, so I decided to investigate minidump using Windbg tool. Once I started to look at the command log after I run !Analyze -v, I got the following result. Further research, I found the following

https://msdn.microsoft.com/en-us/library/windows/hardware/ff559023%28v=vs.85%29.aspx
Cause

Bug check 0x50 usually occurs 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).
Another common cause is the installation of a faulty system service.
Antivirus software can also trigger this error, as can a corrupted NTFS volume.


I don't see any memory error nor disk errors on hard drives....
In order to report the incident, I need more details out of it.  If I could get the straight & clear answer and how to avoid it in the future, that would be great! Please take a look.

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fffff900c0c1fad8, memory referenced.
Arg2: 0000000000000001, value 0 = read operation, 1 = write operation.
Arg3: fffff960002bdec5, If non-zero, the instruction address which referenced the bad memory
	address.
Arg4: 0000000000000000, (reserved)

Debugging Details:
------------------


Could not read faulting driver name

WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff80001c85080
GetUlongFromAddress: unable to read from fffff80001c85160
 fffff900c0c1fad8 

FAULTING_IP: 
win32k!ttfdSemDestroyFont+81
fffff960`002bdec5 4883631800      and     qword ptr [rbx+18h],0

MM_INTERNAL_CODE:  0

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT_SERVER

BUGCHECK_STR:  0x50

PROCESS_NAME:  csrss.exe

CURRENT_IRQL:  0

ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) amd64fre

TRAP_FRAME:  fffffa601048f4a0 -- (.trap 0xfffffa601048f4a0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000713340 rbx=0000000000000000 rcx=0000000000000e00
rdx=182b80048007bc2f rsi=0000000000000000 rdi=0000000000000000
rip=fffff960002bdec5 rsp=fffffa601048f630 rbp=fffff900c2826a60
 r8=0000000000000001  r9=fffff90000411ff8 r10=fffff90000012000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na pe nc
win32k!ttfdSemDestroyFont+0x81:
fffff960`002bdec5 4883631800      and     qword ptr [rbx+18h],0 ds:00000000`00000018=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80001b19a10 to fffff80001ab5150

STACK_TEXT:  
fffffa60`1048f3b8 fffff800`01b19a10 : 00000000`00000050 fffff900`c0c1fad8 00000000`00000001 fffffa60`1048f4a0 : nt!KeBugCheckEx
fffffa60`1048f3c0 fffff800`01ab3cd9 : 00000000`00000001 fffff800`01adb13e 00000000`00000000 fffff900`c0c1fac0 : nt! ?? ::FNODOBFM::`string'+0x2d48c
fffffa60`1048f4a0 fffff960`002bdec5 : fffffa60`1048f6a0 fffff960`002bde44 00000000`00000000 fffffa80`17dae250 : nt!KiPageFault+0x119
fffffa60`1048f630 fffff960`0028b0ab : fffff960`002bde44 fffff900`c2826a60 00000000`00000001 fffffa60`1048f758 : win32k!ttfdSemDestroyFont+0x81
fffffa60`1048f660 fffff960`0028961c : fffffa60`1048f710 00000000`00000000 00000000`00000000 00000000`746e6647 : win32k!PDEVOBJ::DestroyFont+0xcb
fffffa60`1048f6a0 fffff960`00293f37 : 00000000`00000000 00000000`00000001 fffff900`c0010000 00000000`00000000 : win32k!RFONTOBJ::vDeleteRFONT+0x4c
fffffa60`1048f700 fffff960`00293bae : 00000000`00000000 fffff900`c2826a60 fffff900`c227ca10 fffff900`c25f5ca0 : win32k!vRestartKillRFONTList+0xab
fffffa60`1048f750 fffff960`0013c5d6 : fffff900`c01ec9c8 00000000`00000000 00000000`00000000 fffff900`00000002 : win32k!PFTOBJ::bUnloadWorkhorse+0x196
fffffa60`1048f7d0 fffff960`0013d1ec : fffff900`c01ec940 00000000`00000000 00000000`00000001 00000000`00000001 : win32k!vCleanupPrivateFonts+0x72
fffffa60`1048f810 fffff960`00131378 : 00000000`00000000 fffff800`01d0ac00 fffff900`c2439d10 00000000`ffffffff : win32k!NtGdiCloseProcess+0x4a8
fffffa60`1048f870 fffff960`00130be7 : 00000000`00000000 fffff900`c2439d10 00000000`00000000 fffff800`01d0acb0 : win32k!GdiProcessCallout+0x1f4
fffffa60`1048f8f0 fffff800`01d1745c : 00000000`00000000 00000000`00000000 fffff800`01c01ec0 00000000`00000000 : win32k!W32pProcessCallout+0x6f
fffffa60`1048f920 fffff800`01d0accd : fffffa60`00000000 fffffa60`1048fa01 fffffa80`1a7e0bb0 fffffa60`78457350 : nt!PspExitThread+0x41c
fffffa60`1048fa10 fffff800`01ad6b61 : 00000000`00000000 fffffa60`1048fc20 00000000`00000000 00000000`00000000 : nt!PsExitSpecialApc+0x1d
fffffa60`1048fa40 fffff800`01ada475 : fffffa60`1048fca0 fffffa60`1048fae0 fffff800`01d0acdc 00000000`00000001 : nt!KiDeliverApc+0x441
fffffa60`1048fae0 fffff800`01ada337 : fffffa60`1048fca0 00000000`00000000 fffff800`01d0acdc 00000000`00000000 : nt!KiInitiateUserApc+0x75
fffffa60`1048fc20 00000000`6a25e6b4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiApcInterrupt+0x137
00000000`0042e350 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x6a25e6b4


STACK_COMMAND:  kb

FOLLOWUP_IP: 
win32k!ttfdSemDestroyFont+81
fffff960`002bdec5 4883631800      and     qword ptr [rbx+18h],0

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  win32k!ttfdSemDestroyFont+81

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: win32k

IMAGE_NAME:  win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  54ee6961

IMAGE_VERSION:  6.0.6002.19327

FAILURE_BUCKET_ID:  X64_0x50_win32k!ttfdSemDestroyFont+81

BUCKET_ID:  X64_0x50_win32k!ttfdSemDestroyFont+81

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:x64_0x50_win32k!ttfdsemdestroyfont+81

FAILURE_ID_HASH:  {7da2468f-cdea-220b-a23e-d4a9bf4ba830}

Followup: MachineOwner
---------

Open in new window

KimiteruSystem AdministratorAsked:
Who is Participating?
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
"Removing font info" means that a font used for displaying or printing is now about to get removed from memory, because it is not needed anymore at that exact time. For example, a font Arial, 17.5 pt.  scaled to 120%, will most likely only be used while printing.

Very likely the printing is causing this BSOD, but there have to be some circumstances triggering it Maybe a particular (client) printer. The isue with RDP sessions is that users can and will bring in their own printer drivers noone else uses ... But maybe you can find something in the event log about user sessions connecting just before the BSOD, or see them printing (if logged).
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
0x50 is almost always a driver issue. If we can trust the stack dump, the BSOD occurred while trying to remove font info from memory. This hints towards a graphics or printer driver being the culprit, with the latter being more likely.
Can you associate the BSOD with an action?
0
 
KimiteruSystem AdministratorAuthor Commented:
Hi, Qlemo,

Thank you for your quick reply and information. This is a terminal server and users access to this server through RDP and run our custom application and print reports. Some users might print reports from the server when the BSOD occurred. Users don't have admin rights. Could print jobs cause this issue? I'm not too sure what is removing font info from memory means.
0
 
KimiteruSystem AdministratorAuthor Commented:
Thank you.

Unfortunately, we only keep the records of failure logs, so I don't really know who logged in just before the BSOD. Since the BSOD happened around the time the users start logging for the day, (8:15am in our time) I would say that is very likely the cause of the issue.

I will monitor and request to change the policy so that I can trace the user session that caused it.
0
 
KimiteruSystem AdministratorAuthor Commented:
Today, I kept monitoring the user's on / off and the server was stable allready. I guess I will leave it and change the policy to record success logs.

Thank you for your help!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.