DebugDiag 1.1을 사용한 덤프 분석
.NET Profiler의 코드를 변경하고, w3wp.exe를 프로파일링하는데 aspx 페이지를 방문하자마자 예외가 발생하면서 프로세스가 죽었습니다. 이벤트 로그에 보니 다음과 같은 오류를 확인할 수 있었는데요.
Log Name: Application
Source: Application Error
Date: 4/21/2011 11:53:44 PM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: MYPC.testad.com
Description:
Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7afa2
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x0000000000000000
Faulting process id: 0x2d4
Faulting application start time: 0x01cc0033e50aebde
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: unknown
Report Id: 26e854a3-6c27-11e0-9940-00155d00c22a
Log Name: Application
Source: Windows Error Reporting
Date: 4/21/2011 11:53:47 PM
Event ID: 1001
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: MYPC.testad.com
Description:
Fault bucket , type 0
Event Name: BEX64
Response: Not available
Cab Id: 0
Problem signature:
P1: w3wp.exe
P2: 7.5.7601.17514
P3: 4ce7afa2
P4: StackHash_57bc
P5: 0.0.0.0
P6: 00000000
P7: 0000000000000000
P8: c0000005
P9: 0000000000000008
P10:
Attached files:
C:\Windows\Temp\WER9269.tmp.appcompat.txt
C:\Windows\Temp\WER92C8.tmp.WERInternalMetadata.xml
C:\Windows\Temp\WER92E8.tmp.hdmp
C:\Windows\Temp\WER9B08.tmp.mdmp
...[생략]...
Watson Bucket 정보를 분석해 봐도, 모듈명이 "StackHash_57bc"라니... ^^; 뭔가 단단히 잘못된 모양입니다.
P1(AppName): w3wp.exe
P2(AppVer): 7.5.7601.17514
P3(AppStamp): 4ce7afa2
P4(AsmAndModName): StackHash_57bc
P5(AsmVer): 0.0.0.0
P6(ModStamp): 00000000
P7(MethodDef): 0000000000000000
P8(Offset): c0000005
P9(ExceptionType): 0000000000000008
P10:
프로세스 덤프를 남길까 하다가, 이번에는 이벤트 로그에 기록되어 있던 C:\Windows\Temp\WER9B08.tmp.mdmp를 분석해 보기로 했습니다. (안 해보던 것을 해봐야죠! ^^)
분석도 windbg로 해볼까 하다가, 역시 예전부터 봐두기만 했던 DebugDiag의 자동 분석 도구를 이용하기로 마음먹었습니다.
우선,
Debug Diagnostic Tool v1.1 을 설치하고,
Debug Diagnostic Tool v1.1
; http://www.microsoft.com/downloads/en/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en
"시작" / "Debug Diagnostics Tool 1.1" / "DebugDiag-AnalysisOnly 1.1" 도구를 실행합니다.
분석을 시작하기 전에, 2가지 설정을 해줍니다.
- 마이크로소프트 공용 심벌 서버 설정 (여러분들의 제품에 대한 심벌 서버 설정 포함)
- DebugDiag-AnalysisOnly 설정
일단 1번은 DebugDiag-AnalysisOnly도구에서도 설정할 수 있지만 _NT_SYMBOL_PATH를 해두는 것이 편리하기 때문에 아예 환경 변수로 설정해 두는 것이 좋습니다.
Microsoft의 PDB 파일 관리
; https://www.sysnet.pe.kr/2/0/321
2번은, DebugDiag-AnalysisOnly 도구의 "Tools" / "Options & Settings" 메뉴를 선택한 후 "Preferences"에서 다음과 같이 "Include source and line information in analysis reports."를 선택해 줍니다.
이렇게 설정을 마무리 지은 후에 분석 단계로 넘어가면!
방법은 매우 간단합니다. 다음과 같이 "Crash/Hang Analyzers"를 선택하고, "Add Data Files" 버튼으로 덤프 파일을 지정한 후 "Start Anaylsis" 버튼을 선택해 주면 끝입니다.
아래는 제 경우에 분석된 결과입니다.
와~~~ PDB 파일의 도움으로 크래쉬가 발생한 소스 코드 라인 번호까지 보여줍니다. (실제로 제 경우에, 저 위치의 분석으로 문제를 해결할 수 있었습니다.)
아쉬운 점이 하나 있다면, 아직 .NET 응용 프로그램에 대한 분석은 지원되지 않는다는 점입니다. 아래의 글에서도 나오지만,
Debugging a .NET crash with rules in Debug Diag
; http://blogs.msdn.com/b/tess/archive/2009/03/20/debugging-a-net-crash-with-rules-in-debug-diag.aspx
; https://www.tessferrandez.com/blog/2009/03/20/debugging-a-net-crash-with-rules-in-debug-diag.html
.NET 응용 프로그램의 경우에는 대강의 원인 파악만 DebugDiag-AnalysisOnly에서 할 수 있을 뿐, 결국 windbg + sos.dll을 이용하는 것을 볼 수 있습니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]