!analyze -v

제 컴퓨터에서 잠자고 있는 덤프 파일을 하나 열어보도록 하겠습니다.

덤프 파일을 열어보면 가장 먼저 보이는 화면은 아래와 유사합니다.

- 덤프 파일의 위치, 덤프 종류 (위 예제에서는 커널덤프 입니다.)

- 덤프가 발생한 OS

- 덤프 발생 시점의 시간 (4월 19일 13시 24분 41초)

- 부팅 이후 동작시간 (2시간 32분)

- 버그체크 번호 (BugCheck 3B, BSOD의 종류)

위 화면을 보면, !analyze -v 가 하늘색으로 써져있음을 확인할 수 있습니다.

BSOD에 대한 자세한 정보를 확인할 수 있는 명령어입니다. 눌러보죠

내용들이 길기 때문에 우선 여기까지만 자르고

요런 내용들이 나오게 됩니다.

가장 먼저 나타나는 부분은 버그체크 번호에 대한 설명입니다.

- 시스템 서비스 루틴이 실행 중에 예외가 발생했다고 하네요

그리고 그 뒤에 나오는 인자들은

- Arg1 : 예외 코드가 발생했다는 메시지

- Arg2 : 예외가 발생한 주소

- Arg3 : 트랩 프레임 주소 (예외가 발생했을 때 예외가 발생한 주소와 레지스터의 값을 저장하는 주소, 예외 발생 당시의 상황이 그대로 들어있습니다.)

- Arg4 : zero

FAULTING_IP는 어떤 부분에서 문제가 일어났는지를 표시합니다.

- SetShape 함수에서 예외가 발생했네요

CONTEXT는 예외가 발생한 상태의 레지스터 상태를 보여줍니다.

- 레지스터의 자세한 내용은 다른 포스트에서 설명하도록 하겠습니다.

DEFAULT_BUCKET_ID는 예외 발생한 버킷 ID입니다.

- 드라이버 오류라고 명시되어있습니다.

그리고 버그체크 문자열, 예외를 발생시킨 프로세스 이름, 문제 발생 시점의 IRQL, 예외 발생 시점의 마지막 동작들을 보여줍니다.

이어서 이후의 내용들을 보면..

문제가 일어난 시점의 콜스택

- SetShape가 예외를 일으켰기 때문에 콜스택의 가장 위에 있습니다.

FOLLOWUP_IP는 예외를 일으킨 범인이 SetShape이기 때문에 요놈을 잘 보아라 라는 뜻입니다.

콜스택 상의 심볼 스택의 인덱스는 0이고 (스택상 가장 위(마지막)라는 것을 표시합니다.)

심볼의 이름

예외를 일으킨 모듈의 이름

모듈 파일 이름

디버그 타임스탬프

스택 커맨드

버킷 아이디를 보여줍니다.

스택 커맨드를 빨간색으로 강조한 이유는 여기서 더 자세한 원인을 볼 수 있기 때문입니다.

스택 커맨드를 이용해서 해당 스택에서 무슨 일이 일어났는지 추가 정보를 확인할 수 있죠

.cxr 0xfffff880033cdfa0 를 먼저 입력하면

현재 실행 중인 windbg의 컨텍스트가 BSOD가 발생했을 당시 가장 마지막 호출되었던 스택에 맞춰지게 됩니다.

컨텍스트가 BSOD가 발생했던 SetShape 스택에 맞춰지게 되고

그때 당시 레지스터들의 상태를 보여줍니다.

 - 위에서 언급했었던대로 레지스터에 대한 자세한 설명은 다른 포스팅에서 하도록 하겠습니다.

- 너무 가로로 길어서 한번 잘랐습니다.

kb : 현재 스레드의 스택 내용을 출력하는 커맨드입니다.

컨텍스트가 SetShape에 맞춰졌기 때문에 SetShape를 기준으로 스택에 대한 정보들이 출력됩니다.

RetAddr : 리턴 값

Args to Child : 함수 호출 시 인자들

Call Site : 호출 함수명

오류 내용에 대한 코드의 변수 내용을 확인하면서 원인을 찾아볼 수 있지만,

현재 덤프파일에서 발생한 BSOD는 OS모듈인 win32k 이기 때문에 더 깊은 분석은 할 수 없습니다ㅠㅠ

- OS 모듈은 코드내의 로컬 변수 할당 정보를 볼 수 없습니다.

- 직접 구현한 프로그램과 .pdb 심볼을 가지고 있다면 로컬 변수 할당과 관련된 정보를 볼 수 있습니다.

때문에 BSOD 원인 분석은 못했지만, !analyze -v에 대한 설명은 이만 줄이고

다음 포스팅에서는 windbg에서 코드와 함께 로컬 변수 정보들을 보는 방법을 포스팅하도록 하겠습니다.