[WinDbg] 14. 덤프 파일 열기

http://cafe.naver.com/totallab/560

참고 : 'WinDbg로 쉽게 배우는 Windows Debugging' 에이콘 출판사

 

=============================================================================================================

 

크래시 덤프를 확보하면 WinDbg의 [File] 메뉴에서 [Open Crash Dump…]를 선택해(단축키 : Ctrl+D) 덤프 파일을 열수 있습니다.

 

<?xml:namespace prefix = v /><?xml:namespace prefix = v /><?xml:namespace prefix = o /><?xml:namespace prefix = o />

 

파일 대화상자가 나타나면 덤프 파일이 있는 경로로 찾아가서 파일을 열거나 WinDbg UI에 드래그 앤 드롭으로 파일을 끌어다 놓아 열 수도 있습니다.

 

덤프 파일을 열면 다음과 같은 메시지가 나타납니다.

 

 

 

보통 사람들은 덤프를 열고 이 메시지를 본 후에 더 이상 무엇을 해야 할지 몰라서 WinDbg를 종료해 버립니다. 덤프를 분석하는 방법을 조금만 알면 손쉽게 문제의 원인을 찾아서 수정할 수 있습니다.

메시지에서 주의 깊게 봐야 하는 부분은 첫 번째 덤프 파일 경로와 어떤 유형의 덤프인지 표시하는 부분입니다. ‘User Mini Dump File with Full Memory’라고 나오는데, 전체 메모리 미니 덤프 파일은 응용프로그램이 사용하던 모든 메모리가 유효하다고 알려줍니다. 일반적으로 이것을 전체 덤프라고 합니다. 미니덤프는 레지스터와 스택, 메모리 포인터만 유효한데, 전체 덤프와 같이 프로세스가 사용하면 메모리가 모두 파일로 만들어지지 않으므로 미니 덤프에 포함된 메모리의 일부만 확인할 수 있습니다.덤프 종류에 따른 메시지를 정리하면 다음과 같습니다.

 

-       전체 덤프 : User Mini Dump File with Full Memory : Only application data is available.

-       미니 덤프 : User Mini Dump File : Only Registers, stack and portions of memory are available.

 

분석을 시작할 때 미니 덤프인지 전체 덤프인지 확인을 해야 어느 부분까지 분석할 수 있는지 알 수 있기 때문에 잘 봐두는게 좋습니다.

 

두 번째로는 덤프가 발생한 운영체제 종류를 표시합니다. 제 운영체제는 윈도우 7이지만 용량관계상 전체 덤프가 생성되지 않아 예제로 제공하는 덤프 파일을 열었는데, 예제 파일을 만든 컴퓨터는 윈도우 XP이며, 서비스 팩 2환경에서 작업했다는 것을 알 수 있습니다.

그 다음은 덤프가 발생한 시간을 표시합니다. 문제가 발생한 시간은 문제를 분석할 때 중요한 단서가 되는 경우가 많습니다.

 

그 다음에 나오는 Process Uptime은 프로세스 실행 후 얼마나 오랫동안 동작하고 있었는지 알 수 있는 정보입니다. 이것을 통해 예제 같은 경우에는 1분 29초만에 문제가 발생했다는 것을 알 수 있습니다.

 

다섯 번째는 .ecxr 명령을 통해 저장된 예외 정보에 접근할 수 있다는 메시지 입니다. 어떤 프로세스에 예기치 않은 오류가 발행하면 덤프 파일에는 예외에 대한 정보가 저장되는데, WinDbg를 이용하여 예외 정보를 읽고 예외가 발생한 당시의 상태로 돌려놓고 분석을 할 수 있게 합니다. 이와 같이 WinDbg가 보여주는 메시지에 분석을 어떻게 해야 하는지 제시하는 내용들이 자주 나옵니다. 따라서 WinDbg의 메시지를 주의 깊게 읽어보고 WinDbg에서 하라는 대로 하는 것이 좋습니다. WinDbg가 하라는 대로 따라 하도록 합니다.

 

즉, .ecxr 명령을 내리면서 디버깅을 시작합니다. .ecxr을 잘 모른다면 WinDbg의 Help메뉴를 열고 찾아 보는 것이 가장 좋습니다. 사실 WinDbg 도움말은 디버거 사용법뿐만 아니라 디버깅 스킬에 대한 최고의 안내서 입니다. 내용도 자세하고 광범위해 도움말만 모두 이해한다면 WinDbg와 디버깅의 달인이 될 수 있다고 하니, WinDbg 도움말을 옆에 끼고 살아야겠습니다.

 

.ecxr 명령을 조금만 설명하면 예외가 발생한 상황에 저장된 컨텍스트 레코드를 보여주고 디버거가 해당 내용을 참조하게 하는 명령입니다.

 

컨텍스트 레코드란? 단순하게 설명하면 CPU 레지스터 셋을 의미합니다. 다시 말해서 예외가 발생했을 당시에 저장된 레지스터 셋을 보여주고 이 상태로 되돌려 줍니다.

 

 

이제 콜 스택을 보면 문제가 발생한 흐름을 알 수 있습니다. k 명령을 수행해 콜 스택을 살펴 보도록 하겠습니다.

 

 

윗부분이 마지막에 호출된 부분이므로 MyApp 내부에서 문제가 발생했을을 알 수 있었지만, 어느 함수에서 문제가 발생했는지 알 수 없습니다. 이 상태에서 MyApp에 대한 심볼만 맞추면 어떤 함수이고, 어느 소스코드의 몇 번째 라인이 문제인지 찾을 수 있습니다.

 

다음 강좌에서는 모듈 정보 보기와 심볼 맞추기에 대해서 설명하도록 하겠습니다.