말그대로 시스템 필수 프로세스 (csrss.exe, svchost.exe)등이 비정상 종료되었을 때 발생하는 BugCheck입니다.
테스트를 위해 taskkill.exe /F /IM svchost.exe 커맨드로 BSoD를 발생시켜 보았습니다.
11: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* CRITICAL_PROCESS_DIED (ef) A critical system process died Arguments: Arg1: ffff970fbee5f080, Process object or thread object Arg2: 0000000000000000, If this is 0, a process died. If this is 1, a thread died. Arg3: 0000000000000000 Arg4: 0000000000000000 Debugging Details: ------------------ // 중간 생략 PROCESS_NAME: svchost.exe CRITICAL_PROCESS: svchost.exe EXCEPTION_CODE: (NTSTATUS) 0xcbedd080 - ERROR_CODE: (NTSTATUS) 0xcbedd080 - // 이하 생략 |
이 케이스의 문제는 어떤 프로세스의 어떤 모듈에서 TerminateProcess 관련 api를 호출했는지가 콜스택상에 나타나지 않는다는 점입니다.
!analyze 결과에도 PROCESS_NAME (현재 Context)과 CRITICAL_PROCESS (죽임을 당한 프로세스)에 동일하게 svchost.exe가 찍혀 있죠.
현재 프로세스 컨텍스트도 svchost.exe로 나오고, 콜스택도 커널부분만 표시되니까 도움이 안되죠.
11: kd> !process 11: kd> k |
(이건 메모리 덤프를 열었을 때의 모습이고, Live Debugging일 땐 유저 영역의 Stack까지 잘 표시되기 때문에 문제가 안됩니다.)
현재 프로세스가 Target Process로 표시되는 것은 Caller Thread가 Target Process에 Attach된 상태에서 BSoD가 발생했기 때문입니다.
이럴 땐 !thread 해서 현재 스레드의 상세 정보를 확인해주시면 됩니다.
11: kd> !thread THREAD ffff970fcbedd080 Cid 10dc.47fc Teb: 000000e9038ce000 Win32Thread: ffff970fcb3cc3e0 RUNNING on processor b Not impersonating DeviceMap ffffe206310134e0 Owning Process ffff970fc90cb080 Image: taskkill.exe Attached Process ffff970fbee5f080 Image: svchost.exe Wait Start TickCount 112947 Ticks: 0 Context Switch Count 108 IdealProcessor: 3 UserTime 00:00:00.015 KernelTime 00:00:00.031 Win32 Start Address 0x00007ff7ca2af900 Stack Init ffffce80a841bc90 Current ffffce80a841b480 Base ffffce80a841c000 Limit ffffce80a8416000 Call 0000000000000000 Priority 9 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5 // 이후 생략 |
위와 같이 TargetProcess에 Attach되기 전의 Owning Process를 확인할 수 있습니다. 즉, 누가 최초에 NtTerminateProcess를 호출했는지 확인할 수 있는거죠.
만약 메모리덤프가 '전체 메모리덤프'라면 다음과 같이 Process Context를 변경하여 Owning Process에서의 콜스택을 확인해볼 수 있습니다.
11: kd> .process ffff970fc90cb080 Implicit process is now ffff970f`c90cb080 11: kd> .reload /user Loading User Symbols .................................... ************* Symbol Loading Error Summary ************** Module name Error SharedUserData No error - symbol load deferred You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded. You should also verify that your symbol search path (.sympath) is correct. 11: kd> k # Child-SP RetAddr Call Site 00 ffffce80`a841b938 fffff803`24aa213d nt!KeBugCheckEx 01 ffffce80`a841b940 fffff803`249b46a9 nt!PspCatchCriticalBreak+0xfd 02 ffffce80`a841b9e0 fffff803`2485607c nt!PspTerminateAllThreads+0x15f7a5 03 ffffce80`a841ba50 fffff803`24817529 nt!PspTerminateProcess+0xe0 04 ffffce80`a841ba90 fffff803`243ded05 nt!NtTerminateProcess+0xa9 05 ffffce80`a841bb00 00007ffa`9220fcd4 nt!KiSystemServiceCopyEnd+0x25 06 000000e9`036ef5e8 00007ffa`8f14eac0 ntdll!NtTerminateProcess+0x14 07 000000e9`036ef5f0 00007ff7`ca2a3af3 KERNELBASE!TerminateProcess+0x30 08 000000e9`036ef620 00007ff7`ca2a380f taskkill!CTaskKill::ForciblyKillProcessOnLocalSystem+0x73 09 000000e9`036ef650 00007ff7`ca2a2f6b taskkill!CTaskKill::Kill+0xfb 0a 000000e9`036ef6b0 00007ff7`ca2a11eb taskkill!CTaskKill::DoTerminate+0x813 0b 000000e9`036ef820 00007ff7`ca2af87d taskkill!wmain+0x1e3 0c 000000e9`036ef9b0 00007ffa`8f487974 taskkill!__wmainCRTStartup+0x14d 0d 000000e9`036ef9f0 00007ffa`921da261 KERNEL32!BaseThreadInitThunk+0x14 0e 000000e9`036efa20 00000000`00000000 ntdll!RtlUserThreadStart+0x21 |
'Kernel Inside' 카테고리의 다른 글
Enumerate WFP Callouts (0) | 2021.09.04 |
---|---|
EV인증서 갱신 후 MS 파트너센터(하드웨어 센터)에서 MS Attestation Signing에 실패함. (0) | 2020.02.03 |
BSoD 발생 시 메모리 덤프가 생성되지 않는 경우 (0) | 2015.05.12 |
PsSetCreateProcessNotifyRoutineEx 와 DLL Injection 시점에 관한 이슈... (4) | 2014.09.04 |
Windbg Extension - 커널 콜백 뷰어 (KnCbView) 1.0.0.1 (0) | 2013.09.13 |