아래 글과 연결된 내용입니다.
Crash가 발생했을 때 자동으로 파일로그에 CallStack을 기록하게 하는 클래스를 소개합니다.
위의 파일 두개를 그냥 프로젝트에 포함시켜서 빌드하기만 하면 됩니다. (기존 소스코드를 전혀 수정하지 않아도 됩니다.!!!)
msjexhnd.h 내에서는 MSJExceptionHandler 라는 클래스를 선언하는데, 함께 들어있는 msjexhnd.cpp 파일 내에서 그 클래스의 인스턴스를 전역으로 선언합니다. 그리고 그 MSJExceptionHandler 클래스의 생성자에서 SetUnhandledExceptionFilter 함수를 호출하여 Exception Hadler를 등록하도록 되어 있습니다. 그래서 기존소스코드를 전혀 수정하지 않아도 Exception Handler가 자동으로 등록되는 거죠. (훌륭한 소스코드입니다. ㅎㅎㅎ)
다시 빌드한 프로세스가 Crash나게 되면 아래와 같은 파일로그(프로세스명.rpt)가 생성됩니다.
크래쉬가 발생했다는 보고가 들어오면 해당 경로의 저 파일을 가져다가 map파일과 cod파일로 분석하면 되는거죠.
Dr.Watcon 처럼 덤프를 뜨는 방법도 있지만, 언제 발생할지 모르고 재현불가능한 크래쉬를 미리 대비할 수 있다는 장점이 있죠. ^^
map파일과 cod파일 분석하는 방법은 여기를 참고하세요.
msjexhnd.h와 msjexhnd.cpp의 출처는 아래의 MSDN Webzine 입니다.
MSJExceptionHandler 클래스는 내부적으로 CallStack을 추적하기 위해서 EBP 추적을 통한 CallStack 추적방법 외에도 DbgHelp.dll의 Callstack Tracing API를 사용하는데, 아래의 Article에는 이러한 내용에 대해서도 자세히 나와 있으니 읽어보면 좋습니다. ^^
http://kuaaan.tistory.com/115
Crash가 발생했을 때 자동으로 파일로그에 CallStack을 기록하게 하는 클래스를 소개합니다.
위의 파일 두개를 그냥 프로젝트에 포함시켜서 빌드하기만 하면 됩니다. (기존 소스코드를 전혀 수정하지 않아도 됩니다.!!!)
msjexhnd.h 내에서는 MSJExceptionHandler 라는 클래스를 선언하는데, 함께 들어있는 msjexhnd.cpp 파일 내에서 그 클래스의 인스턴스를 전역으로 선언합니다. 그리고 그 MSJExceptionHandler 클래스의 생성자에서 SetUnhandledExceptionFilter 함수를 호출하여 Exception Hadler를 등록하도록 되어 있습니다. 그래서 기존소스코드를 전혀 수정하지 않아도 Exception Handler가 자동으로 등록되는 거죠. (훌륭한 소스코드입니다. ㅎㅎㅎ)
다시 빌드한 프로세스가 Crash나게 되면 아래와 같은 파일로그(프로세스명.rpt)가 생성됩니다.
//=====================================================
Exceptioncode:C0000005 ACCESS_VIOLATION
Faultaddress: 1002D75F 02:0000275F d:\MyDocuments\1.TESTCODE\DllTest\Debug\DllTest.dll
Registers:
EAX:000008D0
EBX:7FFD3000
ECX:9AD5353F
EDX:10094808
ESI:0012FD5C
EDI:0012FE58
CS:EIP:001B:1002D75F
SS:ESP:0023:0012FD5C EBP:0012FE58
DS:0023 ES:0023 FS:003B GS:0000
Flags:00010246
Callstack:
Address Frame
1002D75F 0012FE58 fnDllTest+8F
77E4EB79 0012FF6C main+C9
77E51337 0012FFB8 __tmainCRTStartup+117
77E5120F 0012FFC0 mainCRTStartup+F
7C7E7077 0012FFF0 RegisterWaitForInputIdle+49
Exceptioncode:C0000005 ACCESS_VIOLATION
Faultaddress: 1002D75F 02:0000275F d:\MyDocuments\1.TESTCODE\DllTest\Debug\DllTest.dll
Registers:
EAX:000008D0
EBX:7FFD3000
ECX:9AD5353F
EDX:10094808
ESI:0012FD5C
EDI:0012FE58
CS:EIP:001B:1002D75F
SS:ESP:0023:0012FD5C EBP:0012FE58
DS:0023 ES:0023 FS:003B GS:0000
Flags:00010246
Callstack:
Address Frame
1002D75F 0012FE58 fnDllTest+8F
77E4EB79 0012FF6C main+C9
77E51337 0012FFB8 __tmainCRTStartup+117
77E5120F 0012FFC0 mainCRTStartup+F
7C7E7077 0012FFF0 RegisterWaitForInputIdle+49
크래쉬가 발생했다는 보고가 들어오면 해당 경로의 저 파일을 가져다가 map파일과 cod파일로 분석하면 되는거죠.
Dr.Watcon 처럼 덤프를 뜨는 방법도 있지만, 언제 발생할지 모르고 재현불가능한 크래쉬를 미리 대비할 수 있다는 장점이 있죠. ^^
map파일과 cod파일 분석하는 방법은 여기를 참고하세요.
msjexhnd.h와 msjexhnd.cpp의 출처는 아래의 MSDN Webzine 입니다.
MSJExceptionHandler 클래스는 내부적으로 CallStack을 추적하기 위해서 EBP 추적을 통한 CallStack 추적방법 외에도 DbgHelp.dll의 Callstack Tracing API를 사용하는데, 아래의 Article에는 이러한 내용에 대해서도 자세히 나와 있으니 읽어보면 좋습니다. ^^
http://www.microsoft.com/msj/0497/hood/hood0497.aspx
'C++ > Debug' 카테고리의 다른 글
IDA에 Debug Symbol 경로 설정하기 (2) | 2009.12.04 |
---|---|
VS2005 코드 분석기능 (0) | 2009.11.09 |
Leak Debugging(2) - LeakDiag로 메모리 누수 디버깅하기 (Debugging Memory Leak with LeakDiag) (13) | 2009.10.12 |
Leak Debugging(1) - CRT 디버그함수를 이용한 메모리 누수(Memory Leak) 탐지하기 (0) | 2009.07.30 |
Process Explorer와 디버그 심볼(PDB 파일)을 이용해 실행중인 프로세스 분석하기 (0) | 2009.06.04 |