BSOD pointing to CSRSS.exe

[thrasherlife]

Hello All,

I am having problems with a customer's computer getting a lot of BSODs. I've obtained a few minidump files and most are referencing csrss.exe. Can anyone take a look at these dumps and help shed some light on the issue?

Thanks,

Jason

Mini022509_01.zip

[CoffeeFiend]

Seemingly it's terminating csrss.exe alright:

FAILURE_BUCKET_ID: 0xF4_IOERR_IMAGE_csrss.exe

BUCKET_ID: 0xF4_IOERR_IMAGE_csrss.exe

CRITICAL_OBJECT_TERMINATION (f4)

Arguments:

Arg1: 00000003, Process

Looking further:

EXCEPTION_CODE: (NTSTATUS) 0xc0000006 - The instruction at 0x%08lx referenced memory at 0x%08lx. The required data was not placed into memory because of an I/O error status of 0x%08lx.

BUGCHECK_STR: 0xF4_IOERR

Oh, some I/O error. Hmm, I wonder what could prevent it from getting something in memory from disk? (AV driver comes to mind already)

Next:

DEFAULT_BUCKET_ID: DRIVER_FAULT

Can't say I'm surprised. Next:

ba2274f4 a8608564 8a14db48 c0000006 ba227584 nt!NtTerminateProcess+0x7d

WARNING: Stack unwind information not available. Following frames may be wrong.

ba227574 805413fc ffffffff c0000006 ba2279b0 SYMEVENT+0x12564

Oh, look! Norton garbage, followed by a call to NtTerminateProcess.

Need I say more? SymNRT is your fix. You're doing them a great favor by ditching it, nevermind it's 3 years out of date (Tue Nov 07 22:38:37 2006)

[cluberti]

All I/O goes through the filesystem filter drivers - it's not enough just to show it loaded on the stack. While it may be symevent, we need a full memory dump to see the IRP and the status of the IRP, the I/O path we're in, and anything loaded into csrss.exe that would otherwise cause an issue as well. While you may be right, it's never enough with a minidump to say what causes csrss.exe to terminate - as can be seen here:

// It's an F4, so what does param 4 say:
0: kd> .bugcheck
Bugcheck code 000000F4
Arguments 00000003 86fa28b0 86fa2a24 805d164c

// Param 4 should be an ASCII string:
0: kd> da 805d164c
805d164c  "Terminating critical process 0x%"
805d166c  "p (%s)."

// The thread actually does seem to indicate it's NOT symevent, as the terminate call came before
// we went through that driver - note that this thread is an LPC server, so it would be interesting
// to know who is the client thread and exactly what that thread was doing (there should be an IRP
// there as well to take apart).  This thread is a worker thread to crash the box, note it's just running
// through the exception handler:
0: kd> !thread
GetPointerFromAddress: unable to read from 80561134
THREAD 86b1a528  Cid 0380.0eac  Teb: 7ffac000 Win32Thread: e9bed9d0 RUNNING on processor 0
Not impersonating
GetUlongFromAddress: unable to read from 805611cc
Owning Process			0	   Image:		 <Unknown>
Attached Process		  86fa28b0	   Image:		 csrss.exe
ffdf0000: Unable to get shared data
Wait Start TickCount	  8394		 
Context Switch Count	  94				 LargeStack
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime				  00:00:00.000
KernelTime				00:00:00.000
Win32 Start Address 0x0000aded
LPC Server thread working on message Id aded	  // <- Would be nice to see this thread and it's IRP
Start Address 0x75b44616
Stack Init a7b07000 Current a7b06c1c Base a7b07000 Limit a7b04000 Call 0
Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 0
ChildEBP RetAddr  Args to Child			  
a7b0649c 805d07f3 000000f4 00000003 86fa28b0 nt!KeBugCheckEx+0x1b (FPO: [5,0,0])
a7b064c0 805d16f7 805d164c 86fa28b0 86fa2a24 nt!PspCatchCriticalBreak+0x75 (FPO: [3,0,0])
a7b064f0 a8ea2175 86fa2af8 c0000006 86ab3f70 nt!NtTerminateProcess+0x7d (FPO: [2,4,4])
WARNING: Stack unwind information not available. Following frames may be wrong.
a7b06574 805413fc ffffffff c0000006 a7b069b0 SYMEVENT+0x12175
a7b06574 a7b069d8 ffffffff c0000006 a7b069b0 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ a7b06574)
a7b065e8 80501131 00000008 00000246 804fe7de 0xa7b069d8
a7b065f4 804fe7de ffffffff c0000006 a7b069f8 nt!ZwTerminateProcess+0x11 (FPO: [2,0,0])
a7b069b0 8050289f a7b069d8 00000000 a7b06d64 nt!KiDispatchException+0x3a0 (FPO: [Non-Fpo])
a7b06d34 80544cc7 015af288 015af2a8 00000000 nt!KiRaiseException+0x175 (FPO: [Non-Fpo])
a7b06d50 805413fc 015af288 015af2a8 00000000 nt!NtRaiseException+0x33
a7b06d50 75b7cfd5 015af288 015af2a8 00000000 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ a7b06d64)
015afe9c 00000000 00000000 00000000 00000000 0x75b7cfd5

Don't jump to conclusions just because there's something non-Microsoft in the stack, especially on a bad I/O dump or F4 dump - all I/O goes through registered system filter drivers, not just bad ones. We need a complete memory dump and another .dmp file from said complete dump before we can say more.

[thrasherlife]

Thanks for the help so far. I have configured the computer to provide a full memory dump next time it has a BSOD.