말그대로 시스템 필수 프로세스 (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
PROCESS ffff970fbee5f080
    SessionId: 0  Cid: 0078    Peb: a0cd706000  ParentCid: 0364
    DirBase: 11b860000  ObjectTable: ffffe20635406080  HandleCount: 1139.
    Image: svchost.exe
    VadRoot ffff970fbee53f30 Vads 145 Clone 0 Private 2191. Modified 1024. Locked 0.
    DeviceMap ffffe206310134e0
    Token                             ffffe2063597d060
    ElapsedTime                       00:29:14.617
    UserTime                          00:00:00.312
    KernelTime                        00:00:01.109
    QuotaPoolUsage[PagedPool]         561672
    QuotaPoolUsage[NonPagedPool]      22064
    Working Set Sizes (now,min,max)  (6606, 50, 345) (26424KB, 200KB, 1380KB)
    PeakWorkingSetSize                6639
    VirtualSize                       2101376 Mb
    PeakVirtualSize                   2101388 Mb
    PageFaultCount                    15762
    MemoryPriority                    BACKGROUND
    BasePriority                      8
    CommitCharge                      2654

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 00000000`00000000 ntdll!NtTerminateProcess+0x14 

(이건 메모리 덤프를 열었을 때의 모습이고, 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

 

Posted by kuaaan
,


사랑합니다. 편안히 잠드소서