자주 만날수 있는 디버깅 오류 코드로 PAGE_FAULT_IN_NONPAGED_AREA 에 관한 오류 입니다.

PAGED와 NONPAGED AREA 란
윈도우에서 PAGE는 정보를 사용하기위한 정보를 저장해 놓은 것이라고 생각 하면 되는데, 기본 크기는 4096Byte 입니다. PAGE라는 용어는 여러 곳에서 사용되게 되며, NONPAGED란 가상 메모리화 할 수 없는 영역, 즉 시스템 메모리(실 메모리) 영역에서 오류가 발생했다는 판단 하시면 됩니다.

오류가 발생하는 원인
이유는 크게 2가지로 보실수 있습니다.
첫째는 함수로 지정한 공간이 너무 작은 경우 입력값이 커서 발생할 수 있으며,
두번째는 위의 반대 상황으로, 입력값이 너무 커서 발생할 수 있습니다.
같은 상황 같지만, 장애를 조치하는 방식에 있어서는 엄연히 다른 부분이 되겠지요.

해결 방법
어떠한 값이 잘못된 메모리 영역을 사용하도록 하였는지 확인하는게 키 포인트로,
잘못된 메모리를 찾았다면, 어떻게 잘못되게 되었는지 역으로 트래킹 해보아야 합니다.
사용할 만한 명령들
!analyze -v
.trap
.frame
dv
dt

보다 자세한 내용은 windbg help 파일을 참조하세요

최근  http://blogs.msdn.com/b/ntdebugging/ 에서 제공한 팁으로, CDDB(Critical Device Database)에 대한 내용과 나타날수 있는 장애에 대한 내용이 있습니다.

 BIOS를 업데이트 하고, Bugcheck 0x7B(Inaccessible_Boot_Device)를 나타낼 때 먼저 !devnode 명령을 통해 현재 어떤 디바이스에서 장애가 발생하였는지(Problem 원인) 확인하고, 해당 디바이스의 인스턴스를 확인하여(업데이트시 인스턴스는 동일해야 합니다.), 기존 레지스트리에 등록된 인스턴스 (HKLM\System\CurrentControlSet\ENUM\)와 차이가 없는지 확인하여 설치 파일의 Inf 내용을 수정하거나, 레지스트리를 수정(inf 수정 추천)하여 조치할수 있습니다.

 

많은 분들이 메모리 분석을 시도 하고 있습니다.

 

하지만 어디서부터 시작해야할지 막막할때가 많죠

제가 생각하기에 가장 먼저 해야할일은 스택의 구조를 파악하는 일을 해야한다 생각합니다.

컴퓨터를 하시는 분들은 메모리가 스택구조로 되어 있다고 알고 있으실 겁니다.

선입후출 이라는 것이죠

 

그럼 다음 내용을 보고 어떤 내용인지 알수 있을까요?

42 01001360 8bff mov edi,edi

    42 01001362 55 push ebp

    42 01001363 8bec mov ebp,esp

    42 01001365 83ec14 sub esp,14h

    43 01001368 c745ec03000000 mov dword ptr [ebp-14h],3

    44 0100136f c745f401000000 mov dword ptr [ebp-0Ch],1

    44 01001376 c745f802000000 mov dword ptr [ebp-8],2

    44 0100137d c745fc03000000 mov dword ptr [ebp-4],3

    45 01001384 c745f000000000 mov dword ptr [ebp-10h],0

    47 0100138b 8d45f0 lea eax,[ebp-10h]

    47 0100138e 50 push eax

    47 0100138f 8b4dec mov ecx,dword ptr [ebp-14h]

    47 01001392 51 push ecx

    47 01001393 8d55f4 lea edx,[ebp-0Ch]

    47 01001396 52 push edx

    47 01001397 e824000000 call 05stackdesc!Sum (010013c0)

    48 0100139c 8b45f0 mov eax,dword ptr [ebp-10h]

    48 0100139f 50 push eax

    48 010013a0 6874110001 push offset 05stackdesc!`string' (01001174)

    48 010013a5 ff1584100001 call dword ptr [05stackdesc!_imp__wprintf (01001084)]

    48 010013ab 83c408 add esp,8

     49 010013ae 8be5 mov esp,ebp

    49 010013b0 5d pop ebp

    49 010013b1 c3 ret
자 선입후출의 의미로만 알수 있을까요?

이 의미만으로는 아무것도 알수가 없지요..

 

정확히 메모리의 구조를 이해하기 위해서는 스레드들이 어떻게 처리되는지 더 자세히 확인해볼 필요가 있습니다.

 

그럼 위 구조 내용을 통해, 확인해 보도록하겠습니다.

 

스택은 아래와 같이 구분할 수 있습니다.

함수 도입부

함수 코드

함수 종결부

 

그러다면 함수 도입부를 확인해 보도록 하겠습니다.

42 01001360 8bff mov edi,edi

    42 01001362 55 push ebp

    42 01001363 8bec mov ebp,esp

    42 01001365 83ec14 sub esp,14h

    43 01001368 c745ec03000000 mov dword ptr [ebp-14h],3

    44 0100136f c745f401000000 mov dword ptr [ebp-0Ch],1

    44 01001376 c745f802000000 mov dword ptr [ebp-8],2

    44 0100137d c745fc03000000 mov dword ptr [ebp-4],3

    45 01001384 c745f000000000 mov dword ptr [ebp-10h],0

    47 0100138b 8d45f0 lea eax,[ebp-10h]

    47 0100138e 50 push eax

    47 0100138f 8b4dec mov ecx,dword ptr [ebp-14h]

    47 01001392 51 push ecx

    47 01001393 8d55f4 lea edx,[ebp-0Ch]

    47 01001396 52 push edx

양이 많죠? 위 부분이 함수 도입부 인데, 함수를 저장할 공간을 할당하고, 기존 포인터 위치를 기억하는 게 주된 목적 입니다.

위 부분에서 ebp에 대해 알아 보도록 합시다.

ebp는 알아두어야 할 내용이 항상 주어진 프레임의 베이스 포인터(Base Pointer)를 포함한다고 생각하시면 됩니다.

그럼 아래내용은 무엇을 뜻하는 것일까요?

42 01001362 55 push ebp

    42 01001363 8bec mov ebp,esp

Push 명령을 통해 ebp를 집어넣으라는 명령으로, Stack에 자료를 집어넣을 때 사용하는 것입니다.

쉽게 말해 ebp를 집어넣으라는 뜻이지요

그래서 mov 명령으로 esp 값(Stack Pointer)을 ebp에 저장하라는 명령이 나오게됩니다.

esp는 현재 스택 포인터 값으로, 이 포인터 위치는 항상 변하게 되므로, 항상 호출 이전의 원래 상태로 복귀됨을 보장하여야하는 메모리 구조상 esp의 복귀 주소를 사용할수 없기 때문에 ebp를 통해 복귀할 수 있는 주소를 저장하게 됩니다. (이 행동의 거희 모든 스택의 기본 동작으로 들어가 있습니다.)

mov edi,edi는 긴급 패치를 위해 사용하는데 대부분 nop(no operation)으로 상태가 됩니다. 가용성 측면으로 비사용시간을 줄이기위해 필수적으로 사용하게 됩니다. 이는 나중에 jmp 코드를 이용하기 위해 넣어 둔것이라고 생각하시면 됩니다.

 

자 그럼 도입부분으로 프레임의 베이스 포인터 위치를 ebp에 저장하여 프레임 복귀위치를 저장하였습니다.

이제 다음 스택을 보도록 하겠습니다.

    42 01001365 83ec14 sub esp,14h

    43 01001368 c745ec03000000 mov dword ptr [ebp-14h],3

    44 0100136f c745f401000000 mov dword ptr [ebp-0Ch],1

    44 01001376 c745f802000000 mov dword ptr [ebp-8],2

    44 0100137d c745fc03000000 mov dword ptr [ebp-4],3

    45 01001384 c745f000000000 mov dword ptr [ebp-10h],0

esp, 14h가 의미하는건 14h를 10진수로 변환해 보면, 20바이트가 되며, sub는 빼는것으로, 20바이트 만큼 공간을 생성하도록 되어 있습니다.

왜 이렇게 공간을 생성하는게 빼기를 하였을까요?

메모리의 저장 위치를 잘 보시면 저장 위치의 값이 감소하도록 되어 있습니다.

즉 밑으로 갈수록 값이 감소하고 있는것이지요

그래서 아래 공간은 빼기를 통해 확보하게 됩니다.

그렇게 확보한 공간에 ebp(베이스 포인터)의 위치 값을 이용하여 (베이스 포인터는 절대 위치 값처럼 그 프레임 내에서는 변화하지 않기 때문에 변수 저장과 같은 절대 위치가 필요한 값 저장에 사용하게 됩니다.)스택기반 지역 변수를 초기화 하게 됩니다.

그 내용이

    43 01001368 c745ec03000000 mov dword ptr [ebp-14h],3

    44 0100136f c745f401000000 mov dword ptr [ebp-0Ch],1

    44 01001376 c745f802000000 mov dword ptr [ebp-8],2

    44 0100137d c745fc03000000 mov dword ptr [ebp-4],3

    45 01001384 c745f000000000 mov dword ptr [ebp-10h],0

위 부분이 되겠습니다.

그리고 포인터 전달 명령인 lea를 통해 인자를 스택에 저장 합니다.

42 01001360 8bff mov edi,edi

    42 01001362 55 push ebp

    42 01001363 8bec mov ebp,esp

    42 01001365 83ec14 sub esp,14h

    43 01001368 c745ec03000000 mov dword ptr [ebp-14h],3

    44 0100136f c745f401000000 mov dword ptr [ebp-0Ch],1

    44 01001376 c745f802000000 mov dword ptr [ebp-8],2

    44 0100137d c745fc03000000 mov dword ptr [ebp-4],3

    45 01001384 c745f000000000 mov dword ptr [ebp-10h],0

    47 0100138b 8d45f0 lea eax,[ebp-10h]

    47 0100138e 50 push eax

    47 0100138f 8b4dec mov ecx,dword ptr [ebp-14h]

    47 01001392 51 push ecx

    47 01001393 8d55f4 lea edx,[ebp-0Ch]

    47 01001396 52 push edx

이렇게 지역 변수를 다 저장하고 나면, Call 명령을 통해 해당 변수를 사용하게 됩니다.

그리고 수행을 마치고 마지막에 esp에 처음 저장한 ebp를 대입하여, 복귀하고, 해당 프레임을 빠져 나오게 됩니다.

49 010013ae 8be5 mov esp,ebp

    49 010013b0 5d pop ebp

    49 010013b1 c3 ret

이렇게 하나하나의 프레임의 복귀 주소를 저장하고 변수를 저장후 Call을 통해 해당 명령을 수행하는 구조가 메모리의 기본 구조가 되겠습니다.

^^;

아직 알아야하는부분은 더 많지만 오늘은 스택의 기본 구조 1은 이 정도로 마무리 하도록 하겠습니다.

메모리 깨짐 증상으로 인해 발생하는 Clush 상황에 따른 덤프 분석내용 입니다.


분석 내용

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fffffa821440c7fe, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffffa6009fe1763, If non-zero, the instruction address which referenced the bad memory
 address.
Arg4: 0000000000000005, (reserved)

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

PEB is paged out (Peb.Ldr = 000007ff`fffdc018).  Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 000007ff`fffdc018).  Type ".hh dbgerr001" for details

READ_ADDRESS:  fffffa821440c7fe

FAULTING_IP:
V3Flt2K+11763
fffffa60`09fe1763 0fb70441        movzx   eax,word ptr [rcx+rax*2]

MM_INTERNAL_CODE:  5

IMAGE_NAME:  V3Flt2K.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4afbd730

MODULE_NAME: V3Flt2K

FAULTING_MODULE: fffffa6009fd0000 V3Flt2K

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x50

PROCESS_NAME:  w3wp.exe

CURRENT_IRQL:  0

TRAP_FRAME:  fffffa600a7f22e0 -- (.trap 0xfffffa600a7f22e0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000ffffffff rbx=0000000000000000 rcx=fffffa801440c800
rdx=fffffa80153355e0 rsi=0000000000000000 rdi=0000000000000000
rip=fffffa6009fe1763 rsp=fffffa600a7f2470 rbp=fffffa8011d1d450
 r8=fffffa801440c800  r9=fffffa800acf5910 r10=0000000000000001
r11=0000000000000002 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz ac po nc
V3Flt2K+0x11763:
fffffa60`09fe1763 0fb70441        movzx   eax,word ptr [rcx+rax*2] ds:24d0:c7fe=????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff8000165bce0 to fffff8000164dbd0

STACK_TEXT: 
fffffa60`0a7f21e8 fffff800`0165bce0 : 00000000`00000050 fffffa82`1440c7fe 00000000`00000000 fffffa60`0a7f22e0 : nt!KeBugCheckEx
fffffa60`0a7f21f0 fffff800`0164c759 : 00000000`00000000 00000000`00000000 fffffa80`0bb78700 00000000`00000000 : nt!MmAccessFault+0x4f0
fffffa60`0a7f22e0 fffffa60`09fe1763 : 00000000`00000000 00000000`00000000 fffffa80`11d1d5a0 fffffa60`09fe1182 : nt!KiPageFault+0x119
fffffa60`0a7f2470 fffffa60`09fe1182 : fffffa80`1440c800 fffffa60`09fd632f fffffa80`11d1d500 fffffa60`0a7f2598 : V3Flt2K+0x11763
fffffa60`0a7f2490 fffffa60`09fd64f6 : fffffa80`15335510 fffffa80`153355e0 fffffa80`1440c800 fffffa80`0acf5910 : V3Flt2K+0x11182
fffffa60`0a7f24f0 fffffa60`00d4505a : fffffa80`11d1d500 fffffa60`0a7f2598 fffffa60`0a7f2580 00000000`00000010 : V3Flt2K+0x64f6
fffffa60`0a7f2540 fffffa60`00d4432c : 00000000`00000000 fffffa80`0fb7e300 fffffa80`0c666f00 fffffa80`1000000c : fltmgr!FltpPerformPreCallbacks+0x28a
fffffa60`0a7f2620 fffffa60`00d60256 : fffffa80`09dac040 fffffa80`0c666f20 fffffa80`0fb7e0c0 fffffa60`0a7f26a0 : fltmgr!FltpPassThroughInternal+0x3c
fffffa60`0a7f2650 fffff800`018d5393 : 00000000`00000005 fffffa80`0ccf4b10 00000000`00000040 00000000`00000000 : fltmgr!FltpCreate+0x247
fffffa60`0a7f2700 fffff800`018cf069 : fffffa80`0960dcc0 00000000`00000000 fffffa80`1f44b010 fffff800`018fa501 : nt!IopParseDevice+0x5e3
fffffa60`0a7f28a0 fffff800`018d2f54 : 00000000`00000000 fffffa80`18f14101 00000000`00000040 00000000`00000000 : nt!ObpLookupObjectName+0x5eb
fffffa60`0a7f29b0 fffff800`018df430 : 00120089`80100080 00000000`0909ddb8 fffffa80`1e07e501 fffffa80`1e07e540 : nt!ObOpenObjectByName+0x2f4
fffffa60`0a7f2a80 fffff800`018dff5c : 00000000`0909dd48 00000000`80100080 fffffa80`1d9db060 00000000`0909dd68 : nt!IopCreateFile+0x290
fffffa60`0a7f2b20 fffff800`0164d673 : fffffa80`1d9db060 00000000`0909fcc8 fffffa60`0a7f2bc8 fffff800`018cc4d4 : nt!NtCreateFile+0x78
fffffa60`0a7f2bb0 00000000`777b5fca : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0909dcd8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x777b5fca

STACK_COMMAND:  kb

FOLLOWUP_IP:
V3Flt2K+11763
fffffa60`09fe1763 0fb70441        movzx   eax,word ptr [rcx+rax*2]

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  V3Flt2K+11763

FOLLOWUP_NAME:  MachineOwner

FAILURE_BUCKET_ID:  X64_0x50_V3Flt2K+11763

BUCKET_ID:  X64_0x50_V3Flt2K+11763

Followup: MachineOwner
---------

3: kd> .trap 0xfffffa600a7f22e0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000ffffffff rbx=0000000000000000 rcx=fffffa801440c800
rdx=fffffa80153355e0 rsi=0000000000000000 rdi=0000000000000000
rip=fffffa6009fe1763 rsp=fffffa600a7f2470 rbp=fffffa8011d1d450
 r8=fffffa801440c800  r9=fffffa800acf5910 r10=0000000000000001
r11=0000000000000002 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz ac po nc
V3Flt2K+0x11763:
fffffa60`09fe1763 0fb70441        movzx   eax,word ptr [rcx+rax*2] ds:24d0:c7fe=????

3: kd> dd fffffa821440c7fe <-- 잘못된 메모리 영역 참조
fffffa82`1440c7fe  ???????? ???????? ???????? ????????
fffffa82`1440c80e  ???????? ???????? ???????? ????????
fffffa82`1440c81e  ???????? ???????? ???????? ????????
fffffa82`1440c82e  ???????? ???????? ???????? ????????
fffffa82`1440c83e  ???????? ???????? ???????? ????????
fffffa82`1440c84e  ???????? ???????? ???????? ????????
fffffa82`1440c85e  ???????? ???????? ???????? ????????
fffffa82`1440c86e  ???????? ???????? ???????? ????????

3: kd> db fffffa801440c800
fffffa80`1440c800  00 00 0d 17 80 fa ff ff-69 00 63 00 65 00 5c 00  ........i.c.e.\. <--- 깨진부분
fffffa80`1440c810  48 00 61 00 72 00 64 00-64 00 69 00 73 00 6b 00  H.a.r.d.d.i.s.k.
fffffa80`1440c820  56 00 6f 00 6c 00 75 00-6d 00 65 00 32 00 5c 00  V.o.l.u.m.e.2.\.
fffffa80`1440c830  48 00 59 00 55 00 4e 00-44 00 41 00 49 00 5c 00  H.Y.U.N.D.A.I.\.
fffffa80`1440c840  30 00 34 00 20 00 1c ac-1c bc 8c c1 a4 c2 5c 00  0.4. .........\.
fffffa80`1440c850  30 00 34 00 20 00 31 00-30 00 20 00 57 00 65 00  0.4. .1.0. .W.e.

조치 방법

안철수 연구소 확인결과 타고객사 유사건으로 확인한 내역이 있어 이에 따른 안정성을 위해 핫픽스를 제공

v3Net7.0 제품에서 메모리 관련 방어 코드 수정

[패치내용]
파일 path가 비 정상 적으로 입력되거나 해당 메모리가 깨져 있을 경우에 대한 방어 코드 추가

[변경사항]
파일 버퍼의 유효성 확인 코드 추가

[변경모듈]
v3flt2k.sys 7.1.0.15

Dump파일을 일반적인 파일 오픈 식으로 windbg와 연결하면 정상적으로 Dump 파일을 오픈 할수 없다.

windbg 옵션중 유용한 옵션이 있다, 바로, .dmp 확장자를 연결시켜주는 옵션으로 아래 명령을 실행창에 입력하여 보자

windbg -IA
(대소문자 구분함!)

이제 덤프파일을 더블클릭하면 windbg로 정상적으로 오픈되는것을 확인할수 있다.

오랫만에 메모리 덤프 분석한 내용이 있어 글을 올립니다.

현상 :
eip 포인터가 갑자기 참조할수 없는 주소를 참조하여 0xd1 오류와 함께 재부팅됨

분석 내용 :
0: kd> dps fffff80003a8f080-50 fffff80003a8f080+50
fffff800`03a8f030  fffffa80`0b895820
fffff800`03a8f038  fffffa60`0107fe3d tcpip! ?? ::FNODOBFM::`string'+0x6ff4
fffff800`03a8f040  00000000`00001310
fffff800`03a8f048  00000000`00000000
fffff800`03a8f050  fffff800`03a8f0e0
fffff800`03a8f058  fffff800`03a8f0f0
fffff800`03a8f060  fffffa80`094d1000
fffff800`03a8f068  fffffa80`096a8430
fffff800`03a8f070  00000000`00000000
fffff800`03a8f078  00000000`00000000
fffff800`03a8f080  fffffa80`1133a02a
fffff800`03a8f088  f80003a8`f1000130
fffff800`03a8f090  fffffa80`0c59ffff
fffff800`03a8f098  f80003a8`90700fff
fffff800`03a8f0a0  fffffa80`0b89ffff
fffff800`03a8f0a8  fffffa80`0b8958b8
fffff800`03a8f0b0  fffffa80`0c59bb40
fffff800`03a8f0b8  fffffa80`09514280
fffff800`03a8f0c0  fffffa80`0b8958b8
fffff800`03a8f0c8  fffffa60`0106e547 tcpip!TcpDeliverReceive+0x67
fffff800`03a8f0d0  00000000`00000001

장애시 진행되었던 CPU 동작 스레드
0: kd> u fffff80003a8f020
fffff800`03a8f020 0000            add     byte ptr [rax],al <-- 장애시 동작하던 위치 다음 위치로 이동하여야 하나, 다음위치를 지정하는 rip는 참조할수 없는 위치를 지정함.
fffff800`03a8f022 0000            add     byte ptr [rax],al
fffff800`03a8f024 0000            add     byte ptr [rax],al
fffff800`03a8f026 0000            add     byte ptr [rax],al
fffff800`03a8f028 c09b080a80faff  rcr     byte ptr [rbx-57FF5F8h],0FFh
fffff800`03a8f02f ff20            jmp     qword ptr [rax]
fffff800`03a8f031 58              pop     rax
fffff800`03a8f032 890b            mov     dword ptr [rbx],ecx

0: kd> dd fffffa80`1133b630 <- 참조할수 없는 메모리
Page 2ee93b not present in the dump file. Type ".hh dbgerr004" for details
fffffa80`1133b630  ???????? ???????? ???????? ????????
fffffa80`1133b640  ???????? ???????? ???????? ????????
fffffa80`1133b650  ???????? ???????? ???????? ????????
fffffa80`1133b660  ???????? ???????? ???????? ????????
fffffa80`1133b670  ???????? ???????? ???????? ????????
fffffa80`1133b680  ???????? ???????? ???????? ????????
fffffa80`1133b690  ???????? ???????? ???????? ????????
fffffa80`1133b6a0  ???????? ???????? ???????? ????????

0: kd> !thread
THREAD fffff80001787b80  Cid 0000.0000  Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 0
Not impersonating
DeviceMap                 fffff88000007390
Owning Process            fffff800017880c0       Image:         Idle
Attached Process          fffffa8008f3a3d0       Image:         System
Wait Start TickCount      131742600      Ticks: 166 (0:00:00:02.593)
Context Switch Count      719945911            
UserTime                  00:00:00.000
KernelTime                19 Days 19:29:38.046
Win32 Start Address nt!KiIdleLoop (0xfffff8000166ce10)
Stack Init fffff80003a90db0 Current fffff80003a90d40
Base fffff80003a91000 Limit fffff80003a8b000<- 제한 영역 Call 0
Priority 16 BasePriority 0 PriorityDecrement 0 IoPriority 0 PagePriority 0
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff800`03a8ed48 fffff800`0166246e : 00000000`0000000a 00000000`00000000 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff800`03a8ed50 fffff800`0166134b : 00000000`00000001 00000000`00000000 fffff800`03a8ee00 fffffa80`1133a02a : nt!KiBugCheckDispatch+0x6e
fffff800`03a8ee90 fffffa80`1133b630 : 00000000`00000000 fffffa80`0a089bc0 fffffa80`0b895820 fffffa60`0107fe3d : nt!KiPageFault+0x20b (TrapFrame @ fffff800`03a8ee90)
fffff800`03a8f020 00000000`00000000 : fffffa80`0a089bc0 fffffa80`0b895820 fffffa60`0107fe3d 00000000`00001310 : 0xfffffa80`1133b630

동작 중이던 작업
0: kd> dps fffff80003a8f080-50 fffff80003a8f080+50
fffff800`03a8f030  fffffa80`0b895820
fffff800`03a8f038  fffffa60`0107fe3d tcpip! ?? ::FNODOBFM::`string'+0x6ff4 <-TCP Traffic 전달 진행
fffff800`03a8f040  00000000`00001310
fffff800`03a8f048  00000000`00000000
fffff800`03a8f050  fffff800`03a8f0e0
fffff800`03a8f058  fffff800`03a8f0f0
fffff800`03a8f060  fffffa80`094d1000
fffff800`03a8f068  fffffa80`096a8430
fffff800`03a8f070  00000000`00000000
fffff800`03a8f078  00000000`00000000
fffff800`03a8f080  fffffa80`1133a02a
fffff800`03a8f088  f80003a8`f1000130
fffff800`03a8f090  fffffa80`0c59ffff
fffff800`03a8f098  f80003a8`90700fff
fffff800`03a8f0a0  fffffa80`0b89ffff
fffff800`03a8f0a8  fffffa80`0b8958b8
fffff800`03a8f0b0  fffffa80`0c59bb40
fffff800`03a8f0b8  fffffa80`09514280
fffff800`03a8f0c0  fffffa80`0b8958b8
fffff800`03a8f0c8  fffffa60`0106e547 tcpip!TcpDeliverReceive+0x67
fffff800`03a8f0d0  00000000`00000001

원인 :
EIP 포인터의 변경은 임의로 일어날수 없는것으로, 하드웨어의 문제로 발생했을 가능성이 큽니다.
MS에서는 Vmware의 x64 bit Windows 2003 및 2008에서 임의의 재부팅을 발생하는 현상에 대한 핫픽스를 제공하였습니다.

해결 방안 :
아래 문서의 핫픽스 적용으로 해결이 가능합니다.
해당 내용
http://support.microsoft.com/kb/950772

참고
Vmware 관련 내용
Windows 2003 R2 x64 virtual machine fails with STOP Error: 0x000000D1 or STOP Error: 0x0000001E
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004498

 

lkd> !handle

………………………….

………………………….

………………………….

0114: Object: 85324a48  GrantedAccess: 00120089 Entry: e7afb228

Object: 85324a48  Type: (8a527560) File

    ObjectHeader: 85324a30 (old version)

        HandleCount: 1  PointerCount: 2

        Directory Object: 00000000  Name: \symbols.pub\ntkrpamp.pdb\D8743252F83B4F59985D6E19F33BFCAF1\ntkrpamp.pdb {HarddiskVolume1}

 

0118: Object: 85933148  GrantedAccess: 00100003 Entry: e7afb230

Object: 85933148  Type: (8a53c490) Event

    ObjectHeader: 85933130 (old version)

        HandleCount: 1  PointerCount: 1

 

lkd> !fileobj 85324a48

 

\symbols.pub\ntkrpamp.pdb\D8743252F83B4F59985D6E19F33BFCAF1\ntkrpamp.pdb

 

Device Object: 0x89ac36c8   \Driver\Ftdisk

Vpb: 0x8a46d6a8

Event signalled

Access: Read SharedRead SharedDelete

 

Flags:  0x1c0042

Synchronous IO

Cache Supported

Handle Created

Fast IO Read

Random Access

 

FsContext: 0xe7bcad90        FsContext2: 0xe7bcaee8

Private Cache Map: 0x847eaab0

CurrentByteOffset: 19d838

Cache Data:

  Section Object Pointers: 848144c4

  Shared Cache Map: 847ea9d8         File Offset: 19d838 in VACB number 6

  Vacb: 8a52a4a8

  Your data is at: d1d1d838

lkd> dt _FILE_OBJECT 85324a48

nt!_FILE_OBJECT

   +0x000 Type             : 5

   +0x002 Size             : 112

   +0x004 DeviceObject     : 0x89ac36c8 _DEVICE_OBJECT

   +0x008 Vpb              : 0x8a46d6a8 _VPB

   +0x00c FsContext        : 0xe7bcad90

   +0x010 FsContext2       : 0xe7bcaee8

   +0x014 SectionObjectPointer : 0x848144c4 _SECTION_OBJECT_POINTERS

   +0x018 PrivateCacheMap  : 0x847eaab0

   +0x01c FinalStatus      : 0

   +0x020 RelatedFileObject : (null)

   +0x024 LockOperation    : 0 ''

   +0x025 DeletePending    : 0 ''

   +0x026 ReadAccess       : 0x1 ''

   +0x027 WriteAccess      : 0 ''

   +0x028 DeleteAccess     : 0 ''

   +0x029 SharedRead       : 0x1 ''

   +0x02a SharedWrite      : 0 ''

   +0x02b SharedDelete     : 0x1 ''

   +0x02c Flags            : 0x1c0042

   +0x030 FileName         : _UNICODE_STRING "\symbols.pub\ntkrpamp.pdb\D8743252F83B4F59985D6E19F33BFCAF1\ntkrpamp.pdb"

   +0x038 CurrentByteOffset : _LARGE_INTEGER 0x19d838

   +0x040 Waiters          : 0

   +0x044 Busy             : 0

   +0x048 LastLock         : (null)

   +0x04c Lock             : _KEVENT

   +0x05c Event            : _KEVENT

   +0x06c CompletionContext : (null)

lkd> dt _SECTION_OBJECT_POINTERS 0x848144c4

nt!_SECTION_OBJECT_POINTERS

   +0x000 DataSectionObject : 0x847cb0b0

   +0x004 SharedCacheMap   : 0x847ea9d8

   +0x008 ImageSectionObject : (null)

lkd> dt _SHARED_CACHE_MAP 0x847ea9d8

nt!_SHARED_CACHE_MAP

   +0x000 NodeTypeCode     : 767

   +0x002 NodeByteSize     : 304

   +0x004 OpenCount        : 1

   +0x008 FileSize         : _LARGE_INTEGER 0x1a4c00

   +0x010 BcbList          : _LIST_ENTRY [ 0x847ea9e8 - 0x847ea9e8 ]

   +0x018 SectionSize      : _LARGE_INTEGER 0x1c0000

   +0x020 ValidDataLength  : _LARGE_INTEGER 0x1a4c00

   +0x028 ValidDataGoal    : _LARGE_INTEGER 0x1a4c00

   +0x030 InitialVacbs     : [4] (null)

   +0x040 Vacbs            : 0x84f47338  -> 0x8a529068 _VACB

   +0x044 FileObject       : 0x85324a48 _FILE_OBJECT

   +0x048 ActiveVacb       : 0x8a52a4a8 _VACB

   +0x04c NeedToZero       : (null)

   +0x050 ActivePage       : 0x180

   +0x054 NeedToZeroPage   : 0

   +0x058 ActiveVacbSpinLock : 0

   +0x05c VacbActiveCount  : 1

   +0x060 DirtyPages       : 0

   +0x064 SharedCacheMapLinks : _LIST_ENTRY [ 0x84f7c06c - 0x844d78bc ]

   +0x06c Flags            : 0x1000

   +0x070 Status           : 0

   +0x074 Mbcb             : (null)

   +0x078 Section          : 0xeb326d50

   +0x07c CreateEvent      : (null)

   +0x080 WaitOnActiveCount : (null)

   +0x084 PagesToWrite     : 0

   +0x088 BeyondLastFlush  : 0

   +0x090 Callbacks        : 0xb9c2d22c _CACHE_MANAGER_CALLBACKS

   +0x094 LazyWriteContext : 0xe7bcad90

   +0x098 PrivateList      : _LIST_ENTRY [ 0x847eaafc - 0x847eaafc ]

   +0x0a0 LogHandle        : (null)

   +0x0a4 FlushToLsnRoutine : (null)

   +0x0a8 DirtyPageThreshold : 0

   +0x0ac LazyWritePassCount : 0

   +0x0b0 UninitializeEvent : (null)

   +0x0b4 NeedToZeroVacb   : (null)

   +0x0b8 BcbSpinLock      : 0

   +0x0bc Reserved         : (null)

   +0x0c0 Event            : _KEVENT

   +0x0d0 VacbPushLock     : _EX_PUSH_LOCK

   +0x0d8 PrivateCacheMap  : _PRIVATE_CACHE_MAP

만약 IIS에서 행증상이 발생하였는데, 서비스 때문에 어쩔수 없이 재시작하였다고 가정해 봅시다.

그럼 이 원인은 해결할수 없는 미스터리로 남겠지요.. 그리고 다시금 행증상이 찾아오게 될것입니다.

이때를 기다렸다가 ADPlus로 메모리 덤프를 생성하는 방법도 있습니다. 하지만 이건 사람이 수동으로 체크를 하고 있고, 장애시 수동 명령을 입력하여 실행하여야 하기 때문에 매우 느리게 됩니다. 다음 방법을 이용해 보시기 바랍니다. 그럼 URL을 체크하다가 해당 URL이 응답이 없을 때 행으로 간주하고 메모리 덤프를 자동으로 수집하게 됩니다.

 

그럼 그방법에 대해 알아봅시다.

   먼저 아래 다운로드 경로에서 IIS Diagnostics Toolkit를 다운로드 합니다.

http://www.microsoft.com/downloads/details.aspx?FamilyID=9bfa49bc-376b-4a54-95aa-73c9156706e7&DisplayLang=en

 

설치후 Debug Diagnostics Tool를 실행합니다.

여기에는 Crash Mode와 Hang Mode가 있는데 여기서는 Hang Mode만 설명하도록 하겠습니다.

 

1. DebugDiag를 시작합니다.

2. Select Rule Type 창에서 IIS Hang을 선택합니다.

이 창이 보이지 않으면 Add Rule… 버튼을 클릭합니다.

3. Select URLs to monitor창에서 Add URL 버튼을 클릭한 다음, 모니터링할 URL를 입력한다.

예) http://itka.kr/default.html 등입니다.

여러 개를 동시에 입력할수 있습니다.

4. Select Dump Targets 창에서 Add Dump를 클릭한 다음,

All active IIS related process를 선택해 합니다.

5. Select Dump Location And Rule Name 창에서 Rule이름과 Dump의 위치를 확인합니다.

6. Rule Completed 창에서 activate the rule now를 선택합니다.

 

* 만약 Hang이 발생하였는데, 덤프가 발생하지 않으면 Debug Diagnostics Tool의 Tools 메뉴에서 Create IIS Hang Dump를 클릭하시면 덤프가 강제로 생성됩니다. 3번 정도 실행해서 받아주사가 버럽나더,

 

문제가 발생시

DebugDiag는 자동으로 덤프를 받게되며, DebugDiag 창에서 Userdump Count 값이 증가하게 됩니다.

덤프가 받아 졌으면 DebugDiag가 설치된 경로의 Logs 폴더 전체를 압축후 분석 머신에서 분석하시면 됩니다.

여기서는 이벤트 뷰어라는 프로그램을 통해 프로세스 디버깅 할수 있는 방법을 알아보도록 하겠습니다.

• 실시간 디버깅도 가능하지만, 여기서는 프로세스 덤프 파일을 통해 진행하는 방법을 알아보겠습니다.

이벤트 뷰어 프로세스 디버깅 하기

   

먼저 MMC 프로세스 덤프를 해보죠

   

덤프한 파일을 탐색기에서 바로 실행 하기 위해서 windgb -IA를 실행합니다.

windgb -IA

   

Windbg -IA를 command에서 실행 시키면, 다음 메시지와 함께 레지스트리에 확장자를 등록시킵니다.

   

자세한 내용은 도움말을 참고 하세요 (비슷한 말입니다. -ㅅ-)

   

   

처음 사용하시는 분을 위해 명령어로 심볼 경로를 등록해 봅시다.

   

.sympath SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

 

   

그리고 symfix 명령을 통해 기본 심볼 서버의 경로를 지정할수 있습니다.

   

.symfix c:\websymbols

   

잘못된 데이터를 보는 시간을 줄이기 위해 !peb명령으로 메모리 덤프에서 빠르게 확인하는 방법은 다음과 같습니다.

   

!peb

   

peb명령을 스냅인을 생성한 덤프의 메모리 주소를 확인하고, 그 메모리 주소에서

실행한 커맨트 라인 명령을 확인합니다.

   

dt nt!_PEB ProcessParameters->CommandLine 7ffdf000

   

그리고 현재 덤프의 스레드를를 확인합니다.

   

~* kl

   

다음 마지막으로 에러가 발생한 시점을 확인합니다.

(에러가 없는 프로세스 덤프라 없다고 나올듯합니다.)

   

!gle

   

그런다음 windbg의 분석결과를 확인해 봅니다.

   

!analyze -v

   

이렇게 일반적인 프로세스 덤프 분석 상황 입니다.

Crash Dump 분석 체크 리스트

여기서는 덤프 분석 시 기본적인 확인할 사항을 정리 해본 것 입니다.

해당 상황에 아래 확인 사항들을 보시면 문제점 해결하시는데 도움이 되실 겁니다.

 

기본 사항

l  내부 자료 검색

l  Google 혹은 Microsoft Search에서 알려진 이슈가 있는지 검색 (가끔 답을 바로 찾을수도..)

l  툴을 이용해서 저장한 Dump (자동 혹은 수동으로 생성..)

l  OS/SP 버전 (서비스팩)

l  OS언어

l  Debug 시간

l  System 가동 시간

l  컴퓨터 이름

l  .kframes 100

Application Crash or hang 일때

l  기본 분석 (!analyze –v 또는 행이라면 !analyze –v –hang)

l  Crash 와 hang의 Critical Sections 확인 (!locks 그리고 !locks –v, !cs –s –l –o)

l  Component의 타임 스탭프, 중복, 경로, DLL 문제 확인

l  새로운 Components 가 실행 됐는지 확인

l  Process threads (~*kv 또는 !uniqstack)

l  Process 실행 시간

l  Component에 Full raw stack중 문제가 있는 thread

l  Component에 Full raw stack중 main application thread

l  Process 크기

l  Thread 번호

l  Gflags 값 (!gflag)

l  Thread로 소비한 시간 (!runaway)

l  Environment (!peb)

l  Import table (!dh)

l  Hooked function (!chkimg)

l  Exception handlers (!exchain)

l  컴퓨터 이름 (!enwar COMPUTERNAME)

System hang 일때

l  기본 분석 (!analyze –v –hang)

l  ERESOURCE contention 확인 (!locks)

l  Processes 와 가상 메모리를 포함한 Session space (!vm 4)

l  Pools (!poolused)

l  Waiting threads (!stacks)

l  Critical system queues (!exqueue f)

l  I/O (!irpfind)

l  모든 thread stack traces의 리스트 (!process)

l  미심적은 threads의 LPC chain (!lpc message)

l  미심적은 Processes의 Critical sections (!ntsdexts.locks)

l  Sessions, session processes (!session, !sprocess)

l  Processes (!Process 0 0 크기, dandle table 크기 확인)

l  실행중인 threads (!running)

l  Ready threads(!ready)

l  DPC queues (!dpcs)

l  APCs의 리스트 (!apc)

l  Internal queues spinlocks (!qlocks)

l  컴퓨터 이름 (dS srv!srvcomputername)

BSOD일 때

l  기본 분석 (!analyze –v)

l  Pool address (!pool)

l  Component 타임 스탬프

l  Processes 와 가상 메모리 (!vm 4)

l  다른 Processors의 현재 threads

l  Raw stack

l  Bugcheck description (잘렸거나 잘못된 dumps를 위해 ln exception address 포함)

l  Bugcheck callback data (!bugdump Windows XP SP1 전버전에 사용)

l  Bugcheck secondary callback data (.enumtag)

l  컴퓨터 이름 (dS srv!srvcomputername)

[원인]

운영체제가 지원하지 않는 고성능 CPU (대용량 L3 캐쉬를 포함한) 상에서 실행되어 발생한 문제점 같습니다.

[해결방법]

L3 캐시를 부팅 BIOS에서 Disable하거나 Windows 2003의 경우 SP1이상으로 업그레이드 하시기 바랍니다.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;924439

[참고]

DbgBreakPoint

Breakpoint는 Asynchronous Procedure Call (APC)가 발생하기 전에 Processor가 계속해서 code를 실행하는 경우에 발생하게 됩니다.

 

1: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

 

KMODE_EXCEPTION_NOT_HANDLED (1e)

This is a very common bugcheck. Usually the exception address pinpoints

the driver/function that caused the problem. Always note this address

as well as the link date of the driver/image that contains this address.

Arguments:

Arg1: 80000003, The exception code that was not handled

Arg2: 8045b2ec, The address that the exception occurred at

Arg3: 00000000, Parameter 0 of the exception

Arg4: bca17948, Parameter 1 of the exception

 

Debugging Details:

------------------

 

The call to LoadLibrary(kdextx86) failed, Win32 error 0n2

"지정된 파일을 찾을 수 없습니다."

Please check your debugger configuration and/or network access.

The call to LoadLibrary(kdextx86) failed, Win32 error 0n2

"지정된 파일을 찾을 수 없습니다."

Please check your debugger configuration and/or network access.

The call to LoadLibrary(kdextx86) failed, Win32 error 0n2

"지정된 파일을 찾을 수 없습니다."

Please check your debugger configuration and/or network access.

*************************************************************************

*** ***

*** ***

*** Your debugger is not using the correct symbols ***

*** ***

*** In order for this command to work properly, your symbol path ***

*** must point to .pdb files that have full type information. ***

*** ***

*** Certain .pdb files (such as the public OS symbols) do not ***

*** contain the required information. Contact the group that ***

*** provided you with these symbols if you need this command to ***

*** work. ***

*** ***

*** Type referenced: kernel32!pNlsUserInfo ***

*** ***

*************************************************************************

*************************************************************************

*** ***

*** ***

*** Your debugger is not using the correct symbols ***

*** ***

*** In order for this command to work properly, your symbol path ***

*** must point to .pdb files that have full type information. ***

*** ***

*** Certain .pdb files (such as the public OS symbols) do not ***

*** contain the required information. Contact the group that ***

*** provided you with these symbols if you need this command to ***

*** work. ***

*** ***

*** Type referenced: kernel32!pNlsUserInfo ***

*** ***

*************************************************************************

 

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - .

 

FAULTING_IP:

nt!DbgBreakPoint+0

8045b2ec cc int 3

 

EXCEPTION_PARAMETER1: 00000000

 

EXCEPTION_PARAMETER2: bca17948

 

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

 

BUGCHECK_STR: 0x1E

 

PROCESS_NAME: LSASS.EXE

 

EXCEPTION_RECORD: ba948924 -- (.exr 0xffffffffba948924)

ExceptionAddress: 8045b2ec (nt!DbgBreakPoint)

ExceptionCode: 80000003 (Break instruction exception)

ExceptionFlags: 00000000

NumberParameters: 3

Parameter[0]: 00000000

Parameter[1]: bca17948

Parameter[2]: 00000000

 

TRAP_FRAME: ba948978 -- (.trap 0xffffffffba948978)

ErrCode = 00000000

eax=00000001 ebx=8a52ca68 ecx=bca17948 edx=00000000 esi=00000000 edi=00000000

eip=8045b2ed esp=ba9489ec ebp=ba948a18 iopl=0 nv up ei pl nz ac po cy

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000213

nt!DbgBreakPoint+0x1:

8045b2ed c3 ret

Resetting default scope

 

LAST_CONTROL_TRANSFER: from 8046be55 to 80430a18

 

STACK_TEXT:

ba948908 8046be55 ba948924 00000000 ba948978 nt!KiDispatchException+0x30e

ba948970 8046c44c 00000000 8ac631a8 8a52ca68 nt!CommonDispatchException+0x4d

ba948970 8045b2ed 00000000 8ac631a8 8a52ca68 nt!KiTrap03+0x98

ba9489e8 bca178b2 892381e0 892381c8 00000000 nt!DbgBreakPoint+0x1

ba948a44 bca14474 88db3028 00000005 bca0f796 afd!AfdAddressListQuery+0xa2

ba948a78 ba948a50 8048953c ba948ad0 80465a40 afd!AfdGetGroup+0x16c

WARNING: Frame IP not in any known module. Following frames may be wrong.

ba948a84 80465a3f 804008c0 ffffffff ba948ae0 0xba948a50

ba948b90 8045a69a 8047c4c0 8a2d2a40 8aa65a80 nt!_except_handler2+0xb7

ba948c14 804b6990 fe9590e4 00000000 fe959008 nt!PsReturnPoolQuota+0xe2

ba948c78 804543c6 8aa66668 804543e0 ba948d64 nt!IopSynchronousServiceTail+0x60

ba948d34 8046b339 0000135c 000013a4 00000000 nt!ObReferenceObjectByHandle+0x1c2

ba948d34 77f88403 0000135c 000013a4 00000000 nt!KiSystemService+0xc9

00f9f680 74f44141 0000135c 000013a4 00000000 ntdll!ZwDeviceIoControlFile+0xb

00f9f6fc 74f44dfa 0000135c 0d7483f0 00000010 msafd!WSPBind+0x162

00f9f7b8 74f44c6a 0000135c 0fdd3118 00000010 msafd!SockDoConnect+0x243

00f9f7e8 74fac21d 0000135c 0fdd3118 00000010 msafd!WSPConnect+0xb8

00f9f834 779689c3 0000135c 0fdd3118 00000010 WS2_32!connect+0x64

00f9f854 779654d8 0fdd3108 0302cad3 00000001 DNSAPI!Dns_OpenTcpConnectionAndSend+0x4f

00f9f92c 7796570a 00f9f9c4 00002000 0dc92e90 DNSAPI!Dns_NegotiateTkeyWithServer+0x247

00f9f9c8 77965959 0fdcf0a8 0fddd008 00000000 DNSAPI!Dns_DoSecureUpdate+0xcb

00f9fa6c 7796b145 0fdcf0a8 0fddd008 00000000 DNSAPI!Dns_DoSecureUpdate+0x31a

00f9fac0 7796149d 0dc8d278 00002000 0dc93450 DNSAPI!Dns_UpdateLib+0x109

00f9faec 7795e4d5 0dc8d278 00002000 0dcbb2b8 DNSAPI!DnsUpdate+0x4c

00f9fb10 7795e433 00000000 0dc8d278 00002000 DNSAPI!DoQuickUpdateEx+0x1e

00f9fe5c 7795fb87 0dc8d278 00002000 00000000 DNSAPI!DoQuickUpdate+0x1ad

00f9fe88 7795fc02 00f9fed8 00000000 00002000 DNSAPI!modifyRecordsInSetPrivate+0xc3

00f9feac 7651f6ea 00f9fed8 00000000 00002000 DNSAPI!DnsModifyRecordsInSet_UTF8+0x1c

00f9ff24 7651f968 000f6620 00000001 000f6620 netlogon!NlDnsUpdate+0x11d

00f9ff3c 765203d9 00f9ff94 000f6620 00f9ff88 netlogon!NlDnsRegisterOne+0x62

00f9ff60 765204f4 00f9ff94 000f6620 00f9ff88 netlogon!NlDnsScavengeOne+0x58

00f9ff9c 7655bb91 00000000 00000000 00000038 netlogon!NlDnsScavengeWorker+0x111

00f9ffb4 77e5b3bc 00000000 00000000 00000038 netlogon!NlWorkerThread+0x94

00f9ffec 00000000 7655bafb 00000000 00000000 KERNEL32!BaseThreadStart+0x52

 

 

STACK_COMMAND: kb

 

FOLLOWUP_IP:

afd!AfdAddressListQuery+a2

bca178b2 e9e4b8ffff jmp afd!AfdJoinLeaf+0x47 (bca1319b)

 

SYMBOL_STACK_INDEX: 4

 

SYMBOL_NAME: afd!AfdAddressListQuery+a2

 

FOLLOWUP_NAME: MachineOwner

 

MODULE_NAME: afd

 

IMAGE_NAME: afd.sys

 

DEBUG_FLR_IMAGE_TIMESTAMP: 425aeca9

 

FAILURE_BUCKET_ID: 0x1E_afd!AfdAddressListQuery+a2

 

BUCKET_ID: 0x1E_afd!AfdAddressListQuery+a2

 

Followup: MachineOwner

---------

 

1: kd> .exr 0xffffffffba948924

ExceptionAddress: 8045b2ec (nt!DbgBreakPoint)

ExceptionCode: 80000003 (Break instruction exception)

ExceptionFlags: 00000000

NumberParameters: 3

Parameter[0]: 00000000

Parameter[1]: bca17948

Parameter[2]: 00000000

1: kd> .trap 0xffffffffba948978

ErrCode = 00000000

eax=00000001 ebx=8a52ca68 ecx=bca17948 edx=00000000 esi=00000000 edi=00000000

eip=8045b2ed esp=ba9489ec ebp=ba948a18 iopl=0 nv up ei pl nz ac po cy

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000213

nt!DbgBreakPoint+0x1:

8045b2ed c3 ret

1: kd> lmvm afd

start end module name

bca00000 bca1f140 afd (pdb symbols) DownstreamStore\afd.pdb\4247F9041\afd.pdb

Loaded symbol image file: DownstreamStore\afd.dbg\425AECA91f140\afd.dbg

Image path: \SystemRoot\System32\drivers\afd.sys

Image name: afd.sys

Timestamp: Tue Apr 12 06:31:21 2005 (425AECA9)

CheckSum: 000275B2

ImageSize: 0001F140

Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0

1: kd> dd bca00000

bca00000 00905a4d 00000003 00000004 0000ffff

bca00010 000000b8 00000000 00000040 00000000

bca00020 00000000 00000000 00000000 00000000

bca00030 00000000 00000000 00000000 000000c0

bca00040 0eba1f0e cd09b400 4c01b821 685421cd

bca00050 70207369 72676f72 63206d61 6f6e6e61

bca00060 65622074 6e757220 206e6920 20534f44

bca00070 65646f6d 0a0d0d2e 00000024 00000000

빠르게 디버그 해보겠습니다.
솔직히 느낌으로 알수있는 에러라 생각이 드네요..

미리 말씀드리면 아래 문제점의 해결방법은 해당 제조사의 드라이버 업데이트 입니다.

먼저 windbg를 실행합니다.
Microsoft (R) Windows Debugger Version 6.10.0003.233 X86
Copyright (c) Microsoft Corporation. All rights reserved.

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

Symbol search path is: SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols

Executable search path is:
Windows Server 2008/Windows Vista SP1 Kernel Version 6001 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 6001.18145.x86fre.vistasp1_gdr.080917-1612
Machine Name:
Kernel base = 0x81e03000 PsLoadedModuleList = 0x81f1ac70
Debug session time: Fri Nov 14 08:45:26.873 2008 (GMT+9)
System Uptime: 1 days 19:19:13.347
Loading Kernel Symbols
...............................................................
................................................................
........................................
Loading User Symbols

Loading unloaded module list
..................................................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 9F, {3, 8794d6f0, 87768b80, 876e2ce0}

*** ERROR: Module load completed but symbols could not be loaded for ATSwpDrv.sys
Probably caused by : ATSwpDrv.sys

Followup: MachineOwner
---------

오류코드는 BugCheck 9F라고 하네요. 그리고 ATSwpDrv.sys가 문제가 있는데 해당 드라이버의 심볼이 없어 내용을 알수 없다고 합니다.

그럼 windbg에서 추측하는 진단 내용을 확인합니다.

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 00000003, A device object has been blocking an Irp for too long a time
Arg2: 8794d6f0, Physical Device Object of the stack
Arg3: 87768b80, Functional Device Object of the stack
Arg4: 876e2ce0, The blocked IRP

요약하면, IRP를 장기간 대기하고 있다(전원관리), 일치하지 않아 발생한 에러로 보입니다.

그럼 세부 정보를 확인해 보죠.

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

OVERLAPPED_MODULE: Address regions for 'btwavdt' and 'hidusb.sys' overlap

DRVPOWERSTATE_SUBCODE:  3

IRP_ADDRESS:  876e2ce0

DEVICE_OBJECT: 87768b80

DRIVER_OBJECT: 866017c0

IMAGE_NAME:  ATSwpDrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  46603ac0

MODULE_NAME: ATSwpDrv

FAULTING_MODULE: ba000000 ATSwpDrv

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x9F

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from 81e36b5c to 81ed00e3

STACK_TEXT: 
81ef8acc 81e36b5c 0000009f 00000003 8794d6f0 nt!KeBugCheckEx+0x1e
81ef8b28 81e366ac 81ef8b94 805d3078 805d3000 nt!PopCheckIrpWatchdog+0x1ad
81ef8b68 81eb9c40 81f114e0 00000000 e766ac60 nt!PopCheckForIdleness+0x343
81ef8c88 81eb9800 81ef8cd0 885d5b02 81ef8cd8 nt!KiTimerListExpire+0x367
81ef8ce8 81eb93c3 00000000 00000000 00988a90 nt!KiTimerExpiration+0x22a
81ef8d50 81eb7edd 00000000 0000000e 00000000 nt!KiRetireDpcList+0xba
81ef8d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x49

STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

FAILURE_BUCKET_ID:  0x9F_IMAGE_ATSwpDrv.sys

BUCKET_ID:  0x9F_IMAGE_ATSwpDrv.sys

Followup: MachineOwner
---------

ATSwpDrv.sys라는 드라이버가 원인인데, 해당 문제되는 object를 명령으로 확인해 보도록 하겠습니다.

0: kd> !devobj ffffffff87768b80 f
Device object (87768b80) is for:
 FLUSB-0 DriverATSWPDRV DriverObject 866017c0
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00002050
Dacl 88e752c0 DevExt 87768c38 DevObjExt 87768f18
ExtensionFlags (0x00000800) 
                             Unknown flags 0x00000800
AttachedDevice (Upper) 865fbc08*** ERROR: Module load completed but symbols could not be loaded for sptd.sys
 DriverACPI
AttachedTo (Lower) 8794d6f0 Driverusbhub
Device queue is not busy.
0: kd> !drvobj ffffffff866017c0 f
Driver object (866017c0) is for:
 DriverATSWPDRV
Driver Extension List: (id , addr)

저도 자세히는 모르겠지만 ACPI가 관리하는 usb와 ATSWPDRV의 I/O에서 문제가 발생으로 한것으로 보입니다.

Device Object list:
87768b80 

DriverEntry:   ba01f985 ATSwpDrv
DriverStartIo: 00000000 
DriverUnload:  ba0007be ATSwpDrv
AddDevice:     ba00eb60 ATSwpDrv

Dispatch routines:
[00] IRP_MJ_CREATE                      ba0005f4 ATSwpDrv+0x5f4
[01] IRP_MJ_CREATE_NAMED_PIPE           81e28fdf nt!IopInvalidDeviceRequest
[02] IRP_MJ_CLOSE                       ba001072 ATSwpDrv+0x1072
[03] IRP_MJ_READ                        81e28fdf nt!IopInvalidDeviceRequest
[04] IRP_MJ_WRITE                       81e28fdf nt!IopInvalidDeviceRequest
[05] IRP_MJ_QUERY_INFORMATION           81e28fdf nt!IopInvalidDeviceRequest
[06] IRP_MJ_SET_INFORMATION             81e28fdf nt!IopInvalidDeviceRequest
[07] IRP_MJ_QUERY_EA                    81e28fdf nt!IopInvalidDeviceRequest
[08] IRP_MJ_SET_EA                      81e28fdf nt!IopInvalidDeviceRequest
[09] IRP_MJ_FLUSH_BUFFERS               81e28fdf nt!IopInvalidDeviceRequest
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION    81e28fdf nt!IopInvalidDeviceRequest
[0b] IRP_MJ_SET_VOLUME_INFORMATION      81e28fdf nt!IopInvalidDeviceRequest
[0c] IRP_MJ_DIRECTORY_CONTROL           81e28fdf nt!IopInvalidDeviceRequest
[0d] IRP_MJ_FILE_SYSTEM_CONTROL         81e28fdf nt!IopInvalidDeviceRequest
[0e] IRP_MJ_DEVICE_CONTROL              ba001352 ATSwpDrv+0x1352
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL     81e28fdf nt!IopInvalidDeviceRequest
[10] IRP_MJ_SHUTDOWN                    81e28fdf nt!IopInvalidDeviceRequest
[11] IRP_MJ_LOCK_CONTROL                81e28fdf nt!IopInvalidDeviceRequest
[12] IRP_MJ_CLEANUP                     81e28fdf nt!IopInvalidDeviceRequest
[13] IRP_MJ_CREATE_MAILSLOT             81e28fdf nt!IopInvalidDeviceRequest
[14] IRP_MJ_QUERY_SECURITY              81e28fdf nt!IopInvalidDeviceRequest
[15] IRP_MJ_SET_SECURITY                81e28fdf nt!IopInvalidDeviceRequest
[16] IRP_MJ_POWER                       ba012570 ATSwpDrv+0x12570
[17] IRP_MJ_SYSTEM_CONTROL              ba00fc36 ATSwpDrv+0xfc36
[18] IRP_MJ_DEVICE_CHANGE               81e28fdf nt!IopInvalidDeviceRequest
[19] IRP_MJ_QUERY_QUOTA                 81e28fdf nt!IopInvalidDeviceRequest
[1a] IRP_MJ_SET_QUOTA                   81e28fdf nt!IopInvalidDeviceRequest
[1b] IRP_MJ_PNP                         ba0120c2 ATSwpDrv+0x120c2

0: kd> lmvm ATSwpDrv
start    end        module name
ba000000 ba021c80   ATSwpDrv   (no symbols)          
    Loaded symbol image file: ATSwpDrv.sys
    Image path: SystemRootsystem32DRIVERSATSwpDrv.sys
    Image name: ATSwpDrv.sys
    Timestamp:        Sat Jun 02 00:26:56 2007 (46603AC0)
    CheckSum:         00024287
    ImageSize:        00021C80
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

그래서 드라이버의 버전을 확인하니 7.7.1.7 버전 이였고, 해당 제조사 AuthenTec, Inc.의 홈페이지에서 확인하여 보니 비스타에서 전원관리 문제가 있다며, 업데이트를 권고 하고 있었습니다.
위 문제점이 있었던 모델이 HP이며 아래 드라이버 설치로 해결이 가능합니다.
http://h10025.www1.hp.com/ewfrf/wc/softwareDownloadIndex?softwareitem=ob-56164-1&lc=en&cc=us&lang=en&os=2100&product=3554086&dlc=en

보통 장애 해결을 위해 디버깅을 할때는 파일로 할때가 많습니다.

하지만 메모리 용량은 커서 네트워크 복사가 힘들고, 더욱이 엔지니어가 직접 찾아가서 한다는건 시간과 비용이 많이 들지요.

여기서 문제가 있는 시스템에 원격으로 들어가 직접 디버깅하는 방법에 대해 알아보겠습니다.

 

1. 문제가 있는 시스템에서 windbg를 실행합니다.

2. 커맨드 창에 ".server tcp:port=XXXX"를 입력후 입력합니다.

3. 원격 서버 모드가 정상 시작된것을 확인하고, 엔지니어에게 서버의 이름(IP)와 접근 가능 포트번호를 알립니다.

4. 엔지니어는 시작->실행을 누른후 "windbg -remote tcp:port=XXXX,server=서버이름(IP)"를 입력하여 문제가 있는 시스템에 원격 디버그 세션으로 접근 하면 됩니다..

 

동시에 여러 엔지니어가 접근이 가능하며, 원격 서버 모드를 시작할시 C:\mydebuggersession.log에 디버그 세션 로그 정보를 저장하게 됩니다.

커널 디버깅 하기

 디버깅을 당하는 PC를 타겟 PC 또는 디버기(debuggee)라고 하고 디버깅을 행하는 PC를 호스트 PC 또는 디버거(debugger)라고 합니다

 

TARGET컴퓨터 구성하기

먼저 TARGET가 디버그 모드로 부팅할수 있도록 C:\에 위치한 boot.ini파일에 아래 내용을 추가 하도록하지요

multi(0)disk(0)rdisk(0)partition(1)₩WINDOWS="Windows Server 2003 (COM1)" /fastdetect /debug /debugport=COM1 /baudrate=115200
커널 디버깅을 위해 COM1 포트를 사용하고, 속도는 115200 을 사용한다는 것을 나타냄 한줄임

boot.ini 파일의 속성을 지정해 주도록하자 (시스템 파일이기 때문에 읽기 전용이고 시스템 속성이 설정되어 있다.보통 저장하면 기존 설정을 유지하고 있다, 않해줘도 문제는 없음)

c:₩>attrib +s +h +r boot.ini

이제 부팅시 TARGET 컴퓨터가 디버그 모드로 부팅할 수 있도록 설정을 완료

 

HOST컴퓨터 준비하기

먼저 WinDbg를 설치하여야 겠지요?

다운로드 경로 Windbg 32Bit

http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.8.4.0.msi

다운로드 경로 Windbg 64Bit

http://msdl.microsoft.com/download/symbols/debuggers/dbg_ia64_6.8.4.0.msi

 

그리고 File->Symbol Path(심볼 경로)를 경로를 지정하도록 합시다~

Symbol Search Path에 심볼 경로를 아래와 같이 입력해 주세요

심볼 경로

srv*c:\symbols.pub*http://msdl.microsoft.com/download/symbols

 

이렇게 설정을 하면 WinDbg는 먼저 c:\symbols.pub 에 타겟 PC의 운영 체제에 맞는 심볼 파일이 있는지 검사하고 없으면 심볼 서버에서 다운받아 c:\symbols.pub 에 보관해 놓습니다.

 

※ 주의 : c:\symbols.pub 디렉토리는 WinDbg가 만들어 주지 않습니다.

 

이제 File -> Kernel Debug를 선택합니다.

 

TARGET과 연결된 Null Modem Cable의 COM Port와 설정한 속도를 확인후 아래 확인을 누릅니다.

그럼 아래와 같이 대기 상태가 되며, 이제 HOST 컴퓨터의 준비 단계는 끝입니다.

주의 : HOST 컴퓨터를 먼저 대기 시키고 TARGET컴퓨터을 디버그 모드로 부팅하셔야 합니다.

TARGET컴퓨터를 재부팅하고 boot.ini에 만들어둔 Windows Server 2003 (COM1)모드로 TARGET컴퓨터를 부팅하면 커널 디버깅 화면을 보실수 있습니다. 수고하셨습니다 ^^

 

VM (Virtual Machine)으로 구성 하기

커널 모드 디버깅을 실제 머신으로 한다면 얼마나 불편할지 귀차니즘이 하늘을 찌르네요

다행이 VM 머신으로 구성할수 있는 방법이 존재합니다.

 

TEST할 하나의 Virtual Machine을 선택 후 마우스 오른쪽을 눌려 구성(setting) 선택합니다.

 

그리고 COM1을 Named pipe로 설정후 원하시는 이름을 지정하여 줍니다.
여기서는 "\\.\pipe\vm_com"으로 하였어요

 

다음 TARGET 컴퓨터도 boot.ini 파일을 수정후 재부팅하여 아래와 같은 부팅 메뉴에서 엔터를 누르지말고 그대로 두고, 이제 HOST 컴퓨터를 설정합니다.

 

 

파이프로 연결되기 위해서는 WinDbg에 단축아이콘을 하나 만들어 실행시 아래 옵션을 붙여 주도록 합시다.

-k com:pipe,port=\\.\pipe\vm_com

 

 

위와 같이 단축아이콘을 설정후 실행하면 아래와 같은 화면이 나오며 대기하게 됩니다.

이제 VM머신을 디버그 모드로 부팅을 해보도록 합시다. (모드 선택에서 [디버거 사용 가능] 확인)

 

부팅을 하게 되면 아래와 같은 메시지가 나오며 TARGET 컴퓨터에 연결이 됩니다.

 

Ctrl+Break 키를 누르면 TARGET 컴퓨터가 정지하며 TARGET 컴퓨터를 커널 디버깅을 할수 있습니다.

몇가지 명령을 실행해 보로록 하겠습니다.

 

.sympath를 설정된 심볼경로를 보여주는데, 로컬경로인 C:\symbols.pub 디렉토리는 수동으로 만들어 주서야 합니다. 만들어 주지 않으시면 아래와 같은 메시지를 확인할수 있습니다.

WARNING: Whitespace at end of path element

 

lm명령을 통해 로드된 심볼이 무언인지 확인해 보도록 하죠, 여기서 다른 모듈들이 (deferred)라고 나오는데요, 이것은 모듈은 로드되었지만 그에 해당하는 심볼은 로드되지 않았다는 것을 뜻합니다. 사용자가 필요한 심볼이 있다면 ld 명령을 통해 로드 시킬수 있습니다.

 

 

Srv를 로드해 봅시다

 

정상적으로 잘 로드가 되었네요

 

어떤 심볼이 들어있는지 x 명령을 통해 확인해 보도록 하죠

이정도로 여기서는 마치도록 하겠습니다.

Dr. Watson을 통해 Process에서 나타나는 크래쉬 오류의 디버그 정보를 수집할수 있습니다.

 

1. 시작->실행->"drwtsn32.exe"를 실행합니다.
2. 기존 응용 프로그램 오류 가 있다면 "지우기"버튼을 통해 모두 지워주신후 옵션의 그림과 같이 체크하시기 바랍니다.
3. 시작->실행->"drwtsn32.exe –i"를 입력하여 기본 디버거를 Dr. Watson으로 지정합니다.
4. 시스템을 다시 시작하고 정상 부팅후 오류보고가 있다면 Dr. Watson을 실행하여 응용 프로그램 오류에 로깅되었는지 확인합니다.