윈도우 구조 - 메모리 덤프 생성과 분석 기초

윈도우에서 메모리 덤프 분석은 난이도가 높고 넓어서, 하지만 운영 중 발생하는 문제점들을 해결하는 것 역시 관리의 중요 이슈이기에, 여기서 다루어야 한다고 판단하였다. 아마 문제 해결을 원활히 하기 위해서는 커널 분석뿐만 아니라 시스템 영역을 전반적으로 이해하고, Windbg가 숙달되었을 때, 원활한 분석을 진행할 수 있을 것이다. 여기에서 설명하는 정도로 장애시 커널 분석을 원활히 진행하기는 어렵지만, 블루스크린의 처리 프로세스에 대해 이해하고, 메모리 덤프를 생성하는 것과 일반적인 분석 방법론에 대해 이해할 수 있도록 하여, 여러분들이 더 큰 그림을 볼 수 있는 안목을 만들어, 앞으로 나아갈 수 있게 하고자 함이 목표임을 이야기하고 진행하도록 하겠다.

BSOD (Blue Screen of Death)란

시스템을 더 이상 유지할 수 없을 정도의 예외가 발생하였을 때, 윈도우는 블루스크린이 발생한다. 그리고 이 블루스크린 역시 문제를 해결할 수 있는 코드를 제공하는 예외 상황이라 할 수 있다(몇몇 오류는 블루 스크린을 볼 수 없다. 이와 같은 경우를 Dirty Shutdown, 즉 예기치 않은 종료라 부른다). 대부분이 CPU 혹은 커널 모드에서 동작하는 드라이버들의 예외 상황이 발생하면 블루 스크린이 발생하게 되며(유저모드 예외 상황 시에는 블루 스크린이 뜨지 않고 Windows Error Reporting에 의해 좀더 정교한 작업이 진행된다), 이는 윈도우 시스템을 보호하기 위한 기능으로 커널에서 시스템 오류를 감지하여, CPU 프로세서는 실행을 멈추고 Trap Frame을 생성한 후 KeBugCheckEX 함수를 실행해 오류 코드와 4개의 파라미터를 생성하게 된다. 그 후 아래와 같이 블루스크린 화면을 표시하고, 메모리 덤프를 레지스트리 설정에 따라 생성 혹은 생성하지 않은 상태로 운영제체를 재시작하게 된다.

공포의 파란화면으로 불리던 BSOD

 

이 오류 코드와 4개의 파라미터는 문제점을 분석할 수 있는 단서가 되며, 이를 통해 생성된 메모리 덤프르 분석하여 원인을 찾을 수 있게 된다. 그럼 간단히 위 블루스크린의 화면을 조사해보자.

위 화면에 나타난 오류 코드는 다음과 같다.

STOP: 0x00000050 (0xFD3094C2, 0x00000001, 0xFBFE7617, 0x00000000)

여기서 오류코드는 Bugcheck 0x50이며 파라미터는 0xFD3094C2, 0x00000001, 0xFBFE7617, 0x00000000가 된다.

블루 스크린 상단에 나오듯 이 문제점은 Page Fault Nonpage Area 즉, Nonpage Pool에 페이지를 할당할 수 없어 발생된 오류로, 해당 드라이버는 SPCMDCON.SYS라고 추측된다고 알려주고 있다. 하지만 이는 실제 오류를 일으킨 드라이버와 다를 수 있으니, 블루스크린에서 지목한 드라이버가 항상 문제이다라는 생각은 버리기 바란다.

메모리 덤프 구분과 생성

분석에 중요한 자료인 시스템에 심각한 문제점이 발생하면, 시스템은 현재 사용하던 물리적 메모리 영역을 파일로 저장하게 된다. 이를 메모리 덤프라 하는데, 이 메모리 덤프에 대해 알아보도록 하자.

메모리 덤프를 생성하기 위해서는 먼저 특정 조건을 만족해야 한다.

종종 이 조건에 맞지 않아, 메모리 덤프를 생성할 수 없는 경우가 발생한다. 이는 BSOD 상황시 메모리 덤프를 생성 조건이 만족하지 않아 발생하는 상황으로 본 내용들을 확인하고, 조건이 충족되는지 확인하기 바란다(첫째 물리메모리보다 커야 하고, 둘째 %Systemroot% 위치에 생성, 그리고 ASR(Auto system restart, 특정 하드웨어에서 제공) 비활성화).

메모리 덤프는 전체 메모리 덤프, 커널 메모리 덤프, 작은 메모리 덤프로, 총 3개로 구분할 수 있다. 분석가 입장에서는 전체 메모리 덤프를 생성하는 것을 권장하지만, 중요한 서비스인 경우 문제 발생 빠르게 재부팅할 필요가 있다면, 메모리 덤프를 작은 메모리 덤프로 생성하는 것도 고려해 보아야 할 것이다(비스타 이후 버전부터 작은 메모리 덤프를 WER(Windows Error Reporting)기능을 통해, 마이크로소프트에서 운영하는 OCA(Online Crash Analysis)로 전송하여 비슷한 문제점의 해결방안을 검색하여 준다. 이를 통해 사용자는 해당 버그의 원인 해결에 도움을 받을 수 있다).

그럼 각 덤프의 특성에 대해 확인해 보자.

전체 메모리 덤프: 물리 메모리의 저장된 모든 메모리(사용하지 않는 영역포함)를 파일로 덤프한 것으로, 물리 메모리 용량만큼의 저장 공간이 필요하다. 그리고, 물리 메모리를 저장할 때 페이지 파일(가상메모리)를 이용하므로, 사전에 물리 메모리 이상으로 페이지 파일을 설정하여야 한다.

(물리메모리가 4GB인 경우, 최소 +1MB 이상으로 가상메모리 설정)

내 컴퓨터 > 속성 > 고급 탭으로 이동 후 성능을 선택 다시 고급 탭을 확인하면, 가상 메모리 용량을 설정할 수 있다.

 

 

위와 같이 가상 메모리를 설정하였다면, 고급 탭의 시작 및 복구를 통해 메모리 덤프 유형을 선택할 수 있는데, 각 메모리 덤프별 다음과 같은 특성을 가진다.

커널 메모리 덤프: 전체 메모리 덤프보다 작은 메모리 덤프로, 물리 메모리에서 사용되지 않는 영역과 유저 모드에서 동작하는 프로그램에서 사용하는 메모리 영역은 제외된다. 즉 커널 영역의 메모리(HAL, 커널 드라이버, 커널 프로그램)만 파일로 생성하게 된다. 간혹 덤프 분석시 유저모드 데이터가 필요한 경우가 발생할 수 있기 때문에 추천하는 설정은 아니다.

이 메모리 덤프 역시 기본적으로 %SystemRoot%\Memory.dmp에 저장되며, 시스템 장애로 다시 덤프를 생성하게 되면 덮어쓰기로 생성된다.

작은 메모리 덤프: 64Kb의 작은 메모리 덤프로써, 장애 상화 발생 당시의 데이터들만 저장한 덤프이다. 이 덤프에는 아래와 같은 내용이 포함되어 있다.

오류코드와 파라미터(블루스크린), 오류 프로세스(EPROCESS), 오류 스레드(ETHREAD), 오류 호출 스택(16Kb이상인 경우 최신부터 16Kb만 저장), 로드된 드라이버 리스트.

작은 메모리 덤프는 %SystemRoot%\Minidump 디렉토리에 저장되며, 새로운 덤프가 저장될 필요가 있을 시 덮어쓰지 않고, 년도월일방식으로 파일이름을 생성하게 된다.(예: mini020111-01.dmp)

그럼 전체 메모리 덤프를 생성하기 위해서는 어떻게 해야 할까?

아래 몇 가지 조건만 충족되면, 전체 메모리 덤프를 생성할 수 있다.

-  물리 메모리 보다 많은 공간을 가상메모리로 설정
-  레지스트리 HKLM\SYSTEM\CurrentControlSet\Control\CrashControl키 아래

REG_DWORD 값으로 CrashDumpEnabled를 1~3으로 설정

0 = 메모리 덤프 생성 않함
1 = 전체 메모리 덤프
2 = 커널 메모리 덤프
3 = 미니 메모리 덤프

위 2가지 설정이 충족되면 전체 메모리 덤프가 생성된다(물론 디스크 공간도 충분하여야 한다).

특정 운영체제 버전에서는 메모리 덤프 생성 경로를 기본값인 %SystemRoot%\Memory.dmp 에서 다른 위치로 변경한 경우에도 안 되는 경우가 발생하므로, 메모리 덤프 생성 경로는 되도록 기본 위치를 변경하지 말고 사용하기 바란다.

전체 메모리 덤프 관련 설정은 내 컴퓨터 아이콘에서 마우스 오른쪽 클릭 후 속성을 눌러 고급 탭 > 시작 및 복구 설정에서 할 수 있다.

 

 

메모리 덤프 분석

이제 조금 전에 케이스에 대해 문제점 분석을 처음부터 차근차근 진행해보도록 하자.

 

Crash Dump를 메뉴를 통해 파일을 오픈 하면, Windbg는 기본적인 메모리 덤프에 정보를 표시하게 된다.

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.



Loading Dump File [C:\WINDOWS\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: srv*c:\Symbols*http://msdl.microsoft.com/download/symbols ß 현재 설정된 심볼 경로 정보
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible ß 덤프를 생성한 머신의 운영체제 정보
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp3_gdr.100427-1636
Machine Name: # 머신이름
Kernel base = 0x804d9000 PsLoadedModuleList = 0x805654c0
Debug session time: Mon Jan 30 21:49:41.585 2012 (GMT+9) # 디버깅 세션 시작 시간
System Uptime: 0 days 0:01:17.640 # 덤프를 생성했을때의 시스템 동작한 시간, 이 정보를 이용해 자주 발생하는지, 발생 빈도로를 유추할 수 있다.
Loading Kernel Symbols
...............................................................
..........................................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffde00c).  Type ".hh dbgerr001" for details
Loading unloaded module list
..........
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************


Use !analyze -v to get detailed debugging information.


BugCheck F4, {3, 82103020, 82103194, 8060777e} ß 버크코드 정보


unable to get nt!KiCurrentEtwBufferOffset
unable to get nt!KiCurrentEtwBufferBase
PEB is paged out (Peb.Ldr = 7ffde00c).  Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffde00c).  Type ".hh dbgerr001" for details
Probably caused by : csrss.exe

Followup: MachineOwner

--------

위 내용을 Windbg를 이용하여 메모리 덤프를 열면 기본적으로 생성되는 정보들이다.

이중 심볼 설정 유무와 시스템 정보, 그리고 덤프 생성 시간과 시스템 작동시간은 유용하므로, 덤프 분석시 확인하기 바란다(이 정보를 통해 서버의 경우 언제 주로 발생하는지, 발생 빈도와 버전을 통해 제품 자체 버그가 있는지 등 관련 정보를 빠르게 확인할 수 있다).

그리고 우리가 앞서 확인한 버그체크 코드가 나오게 된다. 그러면서 !analyze –v를 통해 세부 정보를 확인하라고 권유하고 있다. !analyze –v는 앞서 애기 했듯이 Windbg각 각 오류코드에 알맞은 분석을 자동적으로 진행하여, 원인을 추리해주는 확장 명령어이다. 이를 통해 문제점을 쉽게 확인할 수도 있고, 단서를 얻을 수도 있다.

따라서 직접 분석을 진행하기 전 먼저 !analyze –v를 진행하도록 하자.

0: 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: 00000003, Process
Arg2: 82103020, Terminating object
Arg3: 82103194, Process image file name
Arg4: 8060777e, Explanatory message (ascii)


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

unable to get nt!KiCurrentEtwBufferOffset
unable to get nt!KiCurrentEtwBufferBase
PEB is paged out (Peb.Ldr = 7ffde00c).  Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffde00c).  Type ".hh dbgerr001" for details

PROCESS_OBJECT: 82103020

IMAGE_NAME:  csrss.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  0

MODULE_NAME: csrss

FAULTING_MODULE: 00000000

PROCESS_NAME:  BSOD.exe

BUGCHECK_STR:  0xF4_BSOD.exe

DEFAULT_BUCKET_ID:  DRIVER_FAULT

LAST_CONTROL_TRANSFER:  from 80637e9d to 805396ba

STACK_TEXT: 
b1a16d00 80637e9d 000000f4 00000003 82103020 nt!KeBugCheckEx+0x1b
b1a16d24 8060773c 8060777e 82103020 82103194 nt!PspCatchCriticalBreak+0x75
b1a16d54 804df99f 82103268 ffffffff 0012f3e4 nt!NtTerminateProcess+0x7d
b1a16d54 7c93e514 82103268 ffffffff 0012f3e4 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012f3e4 00000000 00000000 00000000 00000000 0x7c93e514

!analyze -v는 누차 얘기하지만 각 오류코드 상황에 맞게 오류를 자동으로 검색하여주는 편리한 확장 명령어이다. 이 결과를 100% 신뢰할 수는 없지만, 참고용도로 유용하다. 즉 자동 분석 결과라 생각하면 편리할 것이다.

이제 analyze 명령의 분석 결과를 살펴 보기 전에 해당 Bugchek 코드를 Windbg 도움말에서 찾아 해당 문제점이 무엇을 의미하고 파라미터 값들이 무엇을 의미하는지 확인해 보도록 하자.

각 파라미터 의미 확인

Windbg 도움말에 의하면, 시스템 운영 프로세스 혹은 스레드가 강제 종료되었다고 나온다.

추가로 각 파라미터는 다음을 의미한다.

파라미터 1: 강제 종료된 오브젝트 유형으로 0x3- 프로세스, 0x6- 스레드를 의미

파라미터 2: 강제 종료된 오브젝트

파라미터 3: 프로세스 이미지 파일 이름

파라미터 4: 관련 설명 메시지(ASCII로 표시됨, 없을 수도 있다.) 

 

이제 해당 오류코드와 파라미터의 의미를 알았으니 현재 메모리 덤프의 오류 상황에 대입해 보도록 하자.

파라미터 1: 0x3 à 프로세스의 의해 발생되었다.

파라미터 2: 82103020 à 0x82103020 주소의 오브젝트임을 알린다.

파라미터 3: 82103194 à 파라미터 2에서 가르키는 오브젝트의 이름값은 0x82103194 주소

파라미터 4: 8060777e à ASCII로 관련 메시지가 8060777e에 존재함

 

그럼 각 파라미터를 Windbg를 이용해서 확인해 보자.

// !process 명령을 통해 파라미터 2: 82103020의 오브젝트를 확인하자 3옵션을 사용하면 세부정보까지 확인 가능하다.
0: kd> !process 82103020 3
PROCESS 82103020  SessionId: 0  Cid: 0320    Peb: 7ffdb000  ParentCid: 0274
    DirBase: 07028000  ObjectTable: e165c7a0  HandleCount: 411.
    Image: csrss.exe
    VadRoot 81c56818 Vads 112 Clone 0 Private 404. Modified 570. Locked 0.
    DeviceMap e10001b8
    Token                             e16b6908
    ElapsedTime                       00:00:49.631
    UserTime                          00:00:03.156
    KernelTime                        00:00:02.296
    QuotaPoolUsage[PagedPool]         80148
    QuotaPoolUsage[NonPagedPool]      6848
    Working Set Sizes (now,min,max)  (1377, 50, 345) (5508KB, 200KB, 1380KB)
    PeakWorkingSetSize                1380
    VirtualSize                       61 Mb
    PeakVirtualSize                   61 Mb
    PageFaultCount                    2477
    MemoryPriority                    BACKGROUND
    BasePriority                      13
    CommitCharge                      523

        THREAD 81cf2588  Cid 0320.0368  Teb: 7ffde000 Win32Thread: 00000000 WAIT: (UserRequest) UserMode Non-Alertable
            823ad528  NotificationEvent

        THREAD 81cf2310  Cid 0320.036c  Teb: 7ffdd000 Win32Thread: e1d8ceb0 WAIT: (UserRequest) UserMode Alertable
            822b0540  SynchronizationEvent
            8226d0b0  SynchronizationEvent
            822b9168  SynchronizationEvent

        THREAD 822a2b88  Cid 0320.0370  Teb: 7ffdc000 Win32Thread: e1687930 WAIT: (WrLpcReceive) UserMode Non-Alertable
            821cf140  Semaphore Limit 0x7fffffff

        THREAD 822a2910  Cid 0320.0374  Teb: 7ffda000 Win32Thread: 00000000 WAIT: (WrLpcReceive) UserMode Non-Alertable
            821cfab0  Semaphore Limit 0x7fffffff

        THREAD 8203c020  Cid 0320.0390  Teb: 7ffd9000 Win32Thread: e15d9eb0 WAIT: (WrLpcReceive) UserMode Non-Alertable
            821cf140  Semaphore Limit 0x7fffffff

        THREAD 822a2698  Cid 0320.03bc  Teb: 7ffd8000 Win32Thread: e1aaed60 WAIT: (WrUserRequest) KernelMode Alertable
            81ce7250  SynchronizationEvent
            8226d808  SynchronizationEvent
            820b72c0  NotificationTimer
            81d39898  SynchronizationEvent
            8056b4c0  NotificationEvent
            81d36e30  SynchronizationEvent
            82041130  SynchronizationTimer

        THREAD 81ce3158  Cid 0320.03c0  Teb: 7ffd7000 Win32Thread: e1665678 WAIT: (WrUserRequest) UserMode Non-Alertable
            821ce898  SynchronizationEvent
            81ce3128  SynchronizationEvent
            8203e5d8  SynchronizationEvent

        THREAD 8204b9e0  Cid 0320.0450  Teb: 7ffd6000 Win32Thread: e1ab4008 WAIT: (WrUserRequest) UserMode Non-Alertable
            81ce2078  SynchronizationEvent
            8204b970  SynchronizationEvent

        THREAD 8202c020  Cid 0320.0540  Teb: 7ffd5000 Win32Thread: e1db8388 WAIT: (WrLpcReceive) UserMode Non-Alertable
            821cf140  Semaphore Limit 0x7fffffff

        THREAD 81c90630  Cid 0320.07fc  Teb: 7ffd4000 Win32Thread: e2050508 WAIT: (WrLpcReceive) UserMode Non-Alertable
            821cf140  Semaphore Limit 0x7fffffff

        THREAD 81c0ea28  Cid 0320.0758  Teb: 7ffd3000 Win32Thread: e20c77f0 WAIT: (WrUserRequest) UserMode Non-Alertable
            81fc7608  SynchronizationEvent

// 파라미터 3: 82103194의 위치를 dc명령을 통해 Double-word 방식으로 확인해 보면, 문제가 발생한 프로세스에 대해 알 수 있다.
0: kd> dc 82103194

82103194  73727363 78652e73 00000065 00000000  csrss.exe
// 파라미터 4: 8060777e의 위치를 ASCII 방식으로 표시하는 da 명령을 통해 확인해보자.

0: kd> da 8060777e
8060777e  "Terminating critical process 0x%"
8060779e  "p (%s)."

Windbg를 이용하여, 해당 오류 코드의 값 확인

결과 Csrss.exe 프로세스가 종료되었음을 할 수 있다. 그럼 어떻게 종료된 것일까를 조사해야 한다. 이를 위해 예외 상황 발생 당시 저장해 놓은 프레임을 이용하여 해당 포인터로 이동하여 문제점 발생 당시의 상황을 확인할 수 있다.

// 먼저 저장된 트랩프레임을 이용해 문제 발생 당시로 되돌아 가자.
0: kd> .trap b1a16d64
ErrCode = 00000000
eax=0012f3b0 ebx=00160050 ecx=00000001 edx=001771b0 esi=0012f428 edi=0012f688
eip=7c93e514 esp=0012f3d4 ebp=0012f3e4 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
001b:7c93e514 ??              ???
// 그 당시 처리중인 스레드를 확인하자.
0: kd> !thread -1
THREAD 81c10da8  Cid 0538.0578  Teb: 7ffdd000 Win32Thread: e2027eb0 RUNNING on processor 0
Not impersonating
DeviceMap                 e1e308f8
Owning Process            0       Image:         <Unknown>
Attached Process          81c10020       Image:         BSOD.exe
Wait Start TickCount      4969           Ticks: 0
Context Switch Count      510                 LargeStack
UserTime                  00:00:00.000
KernelTime                00:00:00.093
Win32 Start Address 0x79004ddb
Start Address 0x7c7e0705
Stack Init b1a17000 Current b1a1677c Base b1a17000 Limit b1a13000 Call 0
Priority 10 BasePriority 8 PriorityDecrement 2 DecrementCount 16
ChildEBP RetAddr  Args to Child             
b1a16d00 80637e9d 000000f4 00000003 82103020 nt!KeBugCheckEx+0x1b (FPO: [5,0,0])
b1a16d24 8060773c 8060777e 82103020 82103194 nt!PspCatchCriticalBreak+0x75 (FPO: [3,0,0])
b1a16d54 804df99f 82103268 ffffffff 0012f3e4 nt!NtTerminateProcess+0x7d (FPO: [2,4,4])
b1a16d54 7c93e514 82103268 ffffffff 0012f3e4 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ b1a16d64)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012f3e4 00000000 00000000 00000000 00000000 0x7c93e514
// 사용된 스레드 프로세스가 BSOD.exe임을 확인하였다. 이 정보를 통해 해당 프로세스정보와 스레드 정보를 확인하자.
0: kd> !process 81c10020 3
PROCESS 81c10020  SessionId: 0  Cid: 0538    Peb: 7ffde000  ParentCid: 02a8
    DirBase: 14964000  ObjectTable: e1dc2950  HandleCount:  83.
    Image: BSOD.exe
    VadRoot 81f7f1d0 Vads 80 Clone 0 Private 277. Modified 5. Locked 0.
    DeviceMap e1e308f8
    Token                             e1fcab60
    ElapsedTime                       00:00:05.109
    UserTime                          00:00:00.015
    KernelTime                        00:00:00.093
    QuotaPoolUsage[PagedPool]         54816
    QuotaPoolUsage[NonPagedPool]      4260
    Working Set Sizes (now,min,max)  (1291, 50, 345) (5164KB, 200KB, 1380KB)
    PeakWorkingSetSize                1306
    VirtualSize                       87 Mb
    PeakVirtualSize                   87 Mb
    PageFaultCount                    1375
    MemoryPriority                    BACKGROUND
    BasePriority                      8
    CommitCharge                      2227

// 해당 프로세스에서 실행중이던 스레드들을 확인할 수 있다.
        THREAD 81c10da8  Cid 0538.0578  Teb: 7ffdd000 Win32Thread: e2027eb0 RUNNING on processor 0
        THREAD 81f7a140  Cid 0538.03d4  Teb: 7ffdc000 Win32Thread: 00000000 WAIT: (UserRequest) UserMode Non-Alertable
            81d14ff0  SynchronizationEvent
            81d14f90  SynchronizationEvent
            81d14b50  SynchronizationEvent

        THREAD 81d1a020  Cid 0538.03c8  Teb: 7ffdb000 Win32Thread: 00000000 WAIT: (UserRequest) UserMode Non-Alertable
            81f7ce88  SynchronizationEvent
            81d1a110  NotificationTimer

// 동작 중이던 스레드인 81c10da8를 확인해 보면, 크래쉬 상황으로 연결됨을 확인할 수 있다.
0: kd> !thread 81c10da8
THREAD 81c10da8  Cid 0538.0578  Teb: 7ffdd000 Win32Thread: e2027eb0 RUNNING on processor 0
Not impersonating
DeviceMap                 e1e308f8
Owning Process            0       Image:         <Unknown>
Attached Process          81c10020       Image:         BSOD.exe
Wait Start TickCount      4969           Ticks: 0
Context Switch Count      510                 LargeStack
UserTime                  00:00:00.000
KernelTime                00:00:00.093
Win32 Start Address 0x79004ddb
Start Address 0x7c7e0705
Stack Init b1a17000 Current b1a1677c Base b1a17000 Limit b1a13000 Call 0
Priority 10 BasePriority 8 PriorityDecrement 2 DecrementCount 16
ChildEBP RetAddr  Args to Child             

// 해당 스레드에서 문제가 발생하였음을 알 수 있다.
b1a16d00 80637e9d 000000f4 00000003 82103020 nt!KeBugCheckEx+0x1b (FPO: [5,0,0])
b1a16d24 8060773c 8060777e 82103020 82103194 nt!PspCatchCriticalBreak+0x75 (FPO: [3,0,0])
b1a16d54 804df99f 82103268 ffffffff 0012f3e4 nt!NtTerminateProcess+0x7d (FPO: [2,4,4])
b1a16d54 7c93e514 82103268 ffffffff 0012f3e4 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ b1a16d64)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012f3e4 00000000 00000000 00000000 00000000 0x7c93e514

// 현재 메모리 덤프가 커널 메모리 덤프로써 명령이 실행된 유저 영역을 담고 있지 않아 충돌 당시의 상황을 확인하기는 어려움이 있음을 확인할 수 있다. 따라서 문제점 분석을 진행할 때는 전체 메모리 덤프를 생성하는 것을 습관화하자 J
0: kd> dds esp
0012f3d4  ????????
0012f3d8  ????????
0012f3dc  ????????
0012f3e0  ????????
0012f3e4  ????????
0012f3e8  ????????
0: kd> dds eip-10 eip+10 l10
7c93e504  ????????
7c93e508  ????????
7c93e50c  ????????
7c93e510  ????????
7c93e514  ????????
7c93e518  ????????
7c93e51c  ????????
7c93e520  ????????
7c93e524  ????????
7c93e528  ????????
7c93e52c  ????????
7c93e530  ????????
7c93e534  ????????
7c93e538  ????????
7c93e53c  ????????
7c93e540  ????????