http://mikemstech.blogspot.com/2011/11/windows-crash-dump-analysis.html
0x000000F4 CRITICAL_OBJECT_TERMINATION is a common blue screen error on the Windows platform (Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, and Windows 8). This error occurs when a critical system process or thread is terminated. The termination is detected and results in a bug check that dumps information on the state of the system when the thread or process is killed. Critical system processes include
- smss.exe - Session Management Subsystem
- csrss.exe - Client/Server Runtime Subsystem
- wininit.exe - Session 0 initialization
- logonui.exe - Windows logon process
- lsass.exe - Local Security Authority Subsystem
- services.exe - Service Control Manager
- services.exe processes hosting RPC Endpoint Mapper (RPCSS), DCOM Server Process Launcher, and Plug and Play services
Case 1: Critical Process Termination (Parameter 1 = 3)
A starting point for debugging a critical process termination dump is to use the !analyze -v debugger command,kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* CRITICAL_OBJECT_TERMINATION (f4) A process or thread crucial to system operation has unexpectedly exited or been terminated. Several processes and threads are necessary for the operation of the system; when they are terminated (for any reason), the system can no longer function. Arguments: Arg1: 0000000000000003, Process Arg2: fffffa80022fd060, Terminating object Arg3: fffffa80022fd340, Process image file name Arg4: fffff800017d2240, Explanatory message (ascii) Debugging Details: ------------------ PROCESS_OBJECT: fffffa80022fd060 IMAGE_NAME: _ DEBUG_FLR_IMAGE_TIMESTAMP: 0 MODULE_NAME: _ FAULTING_MODULE: 0000000000000000 PROCESS_NAME: procexp64.exe BUGCHECK_STR: 0xF4_procexp64.exe CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: from fffff80001855142 to fffff800014c9f00 STACK_TEXT: ... : nt!KeBugCheckEx ... : nt!PspCatchCriticalBreak+0x92 ... : nt! ?? ::NNGAKEGL::`string'+0x17a06 ... : nt!NtTerminateProcess+0xf4 ... : nt!KiSystemServiceCopyEnd+0x13 ... : 0x7707017a ... : nt!KiCallUserMode STACK_COMMAND: kb FOLLOWUP_NAME: MachineOwner FAILURE_BUCKET_ID: X64_0xF4_procexp64.exe_IMAGE__ BUCKET_ID: X64_0xF4_procexp64.exe_IMAGE__ Followup: MachineOwner ---------
The PROCESS_NAME string should hopefully identify a process that caused the exit. Parameter 2 contains the address for the process object that terminated. This can be viewed using the !process debugger command. The Image lne indicates the name of the process (in this example, this was csrss.exe).
kd> !process fffffa80022fd060 GetPointerFromAddress: unable to read from fffff80001700000 PROCESS fffffa80022fd060 SessionId: none Cid: 01b0 Peb: 7fffffd5000 ParentCid: 01a8 DirBase: 7a7ea000 ObjectTable: fffff8a0010d3a50
HandleCount: Image: csrss.exe VadRoot fffffa80023326f0 Vads 75 Clone 0 Private 300. Modified 209. Locked 0. DeviceMap fffff8a000008b30 Token fffff8a0010da970 ReadMemory error: Cannot get nt!KeMaximumIncrement value. fffff78000000000: Unable to get shared data ElapsedTime 00:00:00.000 UserTime 00:00:00.000 KernelTime 00:00:00.000 QuotaPoolUsage[PagedPool] 0 QuotaPoolUsage[NonPagedPool] 0 Working Set Sizes (now,min,max) (1242, 50, 345) (4968KB, 200KB, 1380KB) PeakWorkingSetSize 1244 VirtualSize 42 Mb PeakVirtualSize 42 Mb PageFaultCount 1596 MemoryPriority BACKGROUND BasePriority 13 CommitCharge 439 *** Error in reading nt!_ETHREAD @ fffffa800231e060
Parameter 3 contains the process image file name, usually in ASCII format. Use the display memory command to display an ASCII string (da) or a Unicode string (du).
kd> da fffffa80022fd340 fffffa80`022fd340 "csrss.exe"
Parameter 4 contains a pointer to an explanatory message written in ascii, display with the da debugger command
kd> da fffff800017d2240 fffff800`017d2240 "Terminating critical process 0x%" fffff800`017d2260 "p (%s)."
Case 2: Critical Thread Termination (Parameter 1 = 6)
A starting point for debugging a critical thread termination dump is to use the !analyze -v debugger command,kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* CRITICAL_OBJECT_TERMINATION (f4) A process or thread crucial to system operation has unexpectedly exited or been terminated. Several processes and threads are necessary for the operation of the system; when they are terminated (for any reason), the system can no longer function. Arguments: Arg1: 0000000000000006, Thread Arg2: fffffa8001d4e900, Terminating object Arg3: fffffa8001d65e10, Process image file name Arg4: fffff8000178c210, Explanatory message (ascii) Debugging Details: ------------------ CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP BUGCHECK_STR: 0xF4 PROCESS_NAME: procexp64.exe CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: from fffff8000180f142 to fffff80001483f00 STACK_TEXT: ... : nt!KeBugCheckEx ... : nt!PspCatchCriticalBreak+0x92 ... : nt! ?? ::NNGAKEGL::`string'+0x29a68 ... : nt! ?? ::NNGAKEGL::`string'+0x3f47d ... : nt!KiSystemServiceCopyEnd+0x13 ... : 0x776503ea STACK_COMMAND: kb FOLLOWUP_IP: nt!PspCatchCriticalBreak+92 fffff800`0180f142 cc int 3 SYMBOL_STACK_INDEX: 1 SYMBOL_NAME: nt!PspCatchCriticalBreak+92 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc600 FAILURE_BUCKET_ID: X64_0xF4_nt!PspCatchCriticalBreak+92 BUCKET_ID: X64_0xF4_nt!PspCatchCriticalBreak+92 Followup: MachineOwner ---------
The PROCESS_NAME string should hopefully identify a process that caused the exit. Parameter 2 contains the address for the thread object that terminated. This can be viewed using the !thread debugger command. The Owning Process line indicates the name of the process (in this example, this was smss.exe).
kd> !thread fffffa8001d4e900 GetPointerFromAddress: unable to read from fffff800016ba000 THREAD fffffa8001d4e900 Cid 0130.0134 Teb: 000007fffffdd000
Win32Thread: 0000000000000000 WAIT: (UserRequest) UserMode Non-Alertable fffffa8001e0d730 NotificationEvent Not impersonating GetUlongFromAddress: unable to read from fffff800015f8b74 Owning Process fffffa8001d65b30 Image: smss.exe Attached Process N/A Image: N/A fffff78000000000: Unable to get shared data Wait Start TickCount 692 Context Switch Count 479 ReadMemory error: Cannot get nt!KeMaximumIncrement value. UserTime 00:00:00.000 KernelTime 00:00:00.000 Win32 Start Address 0x0000000048347d9c Stack Init fffff88002222db0 Current fffff88002221fd0 Base fffff88002223000 Limit fffff8800221d000 Call 0 Priority 12 BasePriority 11 UnusualBoost 0 ForegroundBoost 0 IoPriority 2
PagePriority 5 Kernel stack not resident.
Parameter 3 contains the process image file name, usually in ASCII format. Use the display memory command to display an ASCII string (da) or a Unicode string (du).
kd> da fffffa8001d65e10 fffffa80`01d65e10 "smss.exe"
Parameter 4 contains a pointer to an explanatory message written in ascii, display with the da debugger command
kd> da fffff8000178c210 fffff800`0178c210 "Terminating critical thread 0x%p" fffff800`0178c230 " (in %s)."
Further Troubleshooting
Further troubleshooting and potential fixes involve identifying the cause of the termination, this can be anything from a virus to a corrupted image or a problem with the registry. An error in a custom credential provider (Vista and later) or Graphical Identification and Authentication (GINA) DLL (pre-Vista) could also cause this error.Things to try if the system is unbootable/unusable due to this error,
- Perform an offline system integrity check
- Roll back any recent changes (applications, patches, etc) in safe mode
- Perform a clean boot of the system
- Run startup repair
- Examine the registry offline and compare key parts of the registry related to the critical processes and services to a working system
- If you have a custom provider or GINA extension (most user's don't), remotely debug the system and notify the developers of the issue. Temporarily disable the custom provider or GINA DLL through the offline registry edit process mentioned above.
See Also,
Windows Crash Dump Analysis
No comments:
Post a Comment