Microsoft MVP성태의 닷넷 이야기
디버깅 기술: 5.8. WinDBG를 이용한 미니덤프 파일 분석 [링크 복사], [링크+제목 복사],
조회: 27053
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
부모글 보이기/감추기
(연관된 글이 2개 있습니다.)
6. WinDBG를 이용한 미니덤프 파일 분석
- WinDBG 버전 6.6.0007.5를 기준으로 설명

지난 3.5. VS.NET 2005를 이용한 미니덤프 파일 분석 (1), (2)에서는 VS.NET 2005에서 덤프 파일을 로드해서 문제를 분석하는 방법을 알아보았습니다. VS.NET 2005를 이용해서 덤프 파일을 이용하는 경우 문제가 되었던 부분을 상기시켜 드리면, Managed DLL에 대한 PDB 파일이 정상적으로 되지 않았다는 것입니다. (이 문제는, 향후에는 수정될 수도 있을 것입니다. 아니면, 제가 지금 모르고 있거나.)
이러한 PDB 심벌 파일 로딩 문제가 WinDBG로 하게 되면 없어지게 됩니다.

WinDBG에 대한 설치 및 기본적인 환경 설정에 대해서는 다음의 토픽을 참조하십시오.
; 커널 구조체 살펴보기

다음 화면은, WinDBG의 "lm" 명령어를 통해서 Symbol 파일이 로드된 상황을 보여주고 있습니다.
(일단, 아래에서는 WinForm.pdb 및 BaseLibrary.pdb는 별도의 Symbol Server를 구축해서 로딩된 경로를 보여주고 있습니다. Symbol Server에 대해서는 나중에 다시 설명할 테니, 지금은 단지 Managed 모듈과 관계된 PDB 파일이 WinDBG에서 정상적으로 로드가 되었다는 것만 알아주십시오.)

0:000> lm
start    end        module name
00400000 00408000   WinForm  C (private pdb symbols)  D:\Symbol\TestSymbols\WinForm.pdb\AAF501BEC049442E8EA56913665DDA4B1\WinForm.pdb
03c70000 03c78000   BaseLibrary C (private pdb symbols)  D:\Symbol\TestSymbols\BaseLibrary.pdb\142ECFFE8FA24A7998E950CA0C04D2DB1\BaseLibrary.pdb
4dd60000 4df07000   GdiPlus    (pdb symbols)          D:\Symbol\OSSymbols\gdiplus.pdb\6D3AD58BC0154FCA9B4BC247AB07E2181\gdiplus.pdb
62d80000 62d89000   lpk        (pdb symbols)          D:\Symbol\OSSymbols\lpk.pdb\7CAB59CDCE524C268CBEE5546512A8651\lpk.pdb
;
[중간 생략]
;
7ade0000 7af74000   System_Drawing_ni C (pdb symbols)          D:\Symbol\OSSymbols\System.Drawing.pdb\9147054F53754810BB8127644DB29A261\System.Drawing.pdb
7afd0000 7bc56000   System_Windows_Forms_ni C (pdb symbols)          D:\Symbol\OSSymbols\System.Windows.Forms.pdb\E21DC295FED44CFBA120055BD8FB4F3F1\System.Windows.Forms.pdb
7c800000 7c8c0000   ntdll      (pdb symbols)          D:\Symbol\OSSymbols\ntdll.pdb\DCE823FCF71A4BF5AA489994520EA18F2\ntdll.pdb
7c8d0000 7d0d3000   shell32    (pdb symbols)          D:\Symbol\OSSymbols\shell32.pdb\FDE63B721108438DB2B434DB444B06512\shell32.pdb

보시는 것처럼, WinForm과 BaseLibrary에 대해서 관련 PDB 파일들이 로드된 것을 확인할 수 있습니다.

이렇게 심벌 파일이 로드되었으면, 이제 sos를 로드함으로써 managed 응용 프로그램에 대한 준비를 마칠 수 있는데요.
여기서 한 가지 주의해야 할 것이 .NET Framework 버전에 맞게 sos를 로드해야 한다는 것입니다. 우선, sos는 다음과 같이 3가지 버전이 있습니다.

- WinDBG 제공 버전 : C:\Program Files\Debugging Tools for Windows\clr10\sos.dll
- .NET 1.1 버전 : C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\sos.dll
- .NET 2.0 버전 : C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll

제가 테스트해본 바에 의하면, .NET 2.0 응용 프로그램은 C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll 경로에 있는 SOS Extension을 로드해야 합니다. (여기서는 2.0 기준으로만 설명을 해나가겠습니다.) 그런데, 이 확장 dll들은 한꺼번에 WinDBG에 의해서 로딩이 되기도 하기 때문에, 우선 자신의 WinDBG에서 로드하고 있는 sos.dll을 다음과 같이 ".chain" 명령어를 통해서 알아봐야 합니다.

0:000> .chain
Extension DLL search Path:
    C:\Program Files\Debugging Tools for Windows\winext;
    C:\Program Files\Debugging Tools for Windows\winext\arcade;
    C:\Program Files\Debugging Tools for Windows\WINXP;
    C:\Program Files\Debugging Tools for Windows\pri;
    C:\Program Files\Debugging Tools for Windows;
    C:\Program Files\Debugging Tools for Windows\winext\arcade;%PATH%

Extension DLL chain:
    C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\sos: API 1.0.0, built Sat Feb 19 05:35:47 2005
        [path: C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\sos.dll]
    C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll: image 2.0.50727.42, API 1.0.0, built Fri Sep 23 16:27:26 2005
        [path: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll]
    c:\program files\debugging tools for windows\clr10\sos.dll: image 6.6.0007.5, API 1.0.0, built Sun Jul 09 05:11:04 2006
        [path: c:\program files\debugging tools for windows\clr10\sos.dll]
    c:\program files\debugging tools for windows\clr10\sos: image 6.6.0007.5, API 1.0.0, built Sun Jul 09 05:11:04 2006
        [path: c:\program files\debugging tools for windows\clr10\sos.dll]
    dbghelp: image 6.6.0007.5, API 6.0.6, built Sun Jul 09 05:11:32 2006
        [path: C:\Program Files\Debugging Tools for Windows\dbghelp.dll]
    ext: image 6.6.0007.5, API 1.0.0, built Sun Jul 09 05:10:52 2006
        [path: C:\Program Files\Debugging Tools for Windows\winext\ext.dll]
    exts: image 6.6.0007.5, API 1.0.0, built Sun Jul 09 05:10:48 2006
        [path: C:\Program Files\Debugging Tools for Windows\WINXP\exts.dll]
    uext: image 6.6.0007.5, API 1.0.0, built Sun Jul 09 05:11:02 2006
        [path: C:\Program Files\Debugging Tools for Windows\winext\uext.dll]
    ntsdexts: image 6.0.5457.0, API 1.0.0, built Sun Jul 09 05:29:38 2006
        [path: C:\Program Files\Debugging Tools for Windows\WINXP\ntsdexts.dll]

보시는 것처럼, 위의 화면에서는 clr10\sos.dll, .NET 1.1 sos.dll 그리고 .NET 2.0 sos.dll 이렇게 3가지 확장 DLL 모두를 로드하고 있는 것을 볼 수 있습니다.
제 경험에 의하면, 이런 경우 확장 명령어를 입력하게 되면 가장 상위에 있는 확장 DLL이 그것을 우선적으로 처리하도록 되어 있습니다. 따라서, 위와 같이 .NET 1.1 sos.dll이 가장 상위에 있는 상태에서 .NET 2.0 응용 프로그램에 대해 다음과 같이 "!clrstack" 같은 명령어를 입력하게 되면 적절하게 해석을 못하는 경우가 발생합니다.

0:000> !clrstack
PDB symbol for mscorwks.dll not loaded
failed to load from resource.Failed to load SOS data.
No valid SOS data table found.

따라서, 이런 경우에는 불필요한 sos 확장 DLL을 unload 시켜야 하는데요. ".chain" 결과로 얻은 다음과 같은 텍스트에서 굵은 글씨체로 표현된 부분을 인자값으로 ".unload" 명령어에 전달해 주시면 됩니다.

    C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\sos: API 1.0.0, built Sat Feb 19 05:35:47 2005
        [path: C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\sos.dll]
    C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll: image 2.0.50727.42, API 1.0.0, built Fri Sep 23 16:27:26 2005
        [path: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll]
    c:\program files\debugging tools for windows\clr10\sos.dll: image 6.6.0007.5, API 1.0.0, built Sun Jul 09 05:11:04 2006
        [path: c:\program files\debugging tools for windows\clr10\sos.dll]
    c:\program files\debugging tools for windows\clr10\sos: image 6.6.0007.5, API 1.0.0, built Sun Jul 09 05:11:04 2006
        [path: c:\program files\debugging tools for windows\clr10\sos.dll]

즉, 아래와 같이 해주시면 .NET 2.0 SOS.dll만 남게 됩니다.

0:000> .unload C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\sos
Unloading 'C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\sos' extension DLL

0:000> .unload c:\program files\debugging tools for windows\clr10\sos.dll
Unloading c:\program files\debugging tools for windows\clr10\sos.dll extension DLL

0:000> .unload c:\program files\debugging tools for windows\clr10\sos
Unloading c:\program files\debugging tools for windows\clr10\sos extension DLL

자... 이제 모든 준비는 마쳤습니다. PDB 파일도 로드되었고, .NET 버전에 맞는 sos.dll도 로드된 상태입니다. 자신있게 다음과 같이 현재 발생한 예외를 출력하도록 합니다.

0:000> !printexception
PDB symbol for mscorwks.dll not loaded
Exception object: 013175dc
Exception type: System.IO.FileNotFoundException
Message: Could not find file 'C:\test_nothing.txt'.
InnerException: <none>
StackTrace (generated):
    SP       IP       Function
    0012EA20 796538B2 System.IO.__Error.WinIOError(Int32, System.String)
    0012EA80 7936F43B System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, 
                                System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean)
    0012EB74 793723BF System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare)
    0012EB98 7946D097 System.IO.File.Open(System.String, System.IO.FileMode)
    0012EBA8 0124030F BaseLibrary.ThrowClass.TestMethod()
    0012EBF0 01240270 WinForm.Form1.Form1_Load(System.Object, System.EventArgs)
    0012EC40 7B065B27 System.Windows.Forms.Form.OnLoad(System.EventArgs)
;
[중간 생략]
;
    0012ED08 7B072E3B System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
    0012F438 7B0C69FE System.Windows.Forms.Application.Run(System.Windows.Forms.Form)
    0012F448 012400BA WinForm.Program.Main()

StackTraceString: <none>
HResult: 80070002

그런데, 이게 웬일입니까? ^^; PDB 파일을 로드시켰건만 소스 파일 및 라인 정보는 출력되지 않고 있습니다. 그렇습니다. 애석하게도 ^^; .NET 2.0에 포함된 sos.dll은 그 부분을 처리하지 못한다고 합니다. (.NET 1.1은 됩니다.)
다음은 이 문제와 관련한 Q&A입니다.

Debugging with dumps
; http://www.eggheadcafe.com/aspnet_answers/vsnetdebugging/Jul2006/post27444351.asp

I finally got confirmation from our CLR SOS owner that the source line  
information is not currently supported by SOS.  There's a work item for the  
next version of the CLR to include this information.  Thank you for  
reporting this!  
If you still have any concern or comment, please feel free to tell me.  
Thanks!  

Best regards,    
Jeffrey Tan  
Microsoft Online Community Support  

원래는 제가 이번 WinDBG와 PDB에 대한 토픽을 준비하기 전에, 먼저 PDB 파일 관리를 위한 Symbol Server 부분을 설명한 후에 이번 내용을 진행해 보려 했지만, 위와 같은 문제로 인해 순서를 뒤로 미루게 되었습니다.
결과가 이렇게 되고 보니, 결국 WinDBG에서의 디버깅 방법이나 VS.NET 2005에서의 디버깅 방법이나 똑같이 되어 버렸기 때문입니다. 이후의 WinDBG에서의 문제 분석은 지난 토픽에서 설명한 VS.NET 2005에서와 방법이 같으므로 생략합니다.





[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]
[연관 글]






[최초 등록일: ]
[최종 수정일: 6/28/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2009-02-02 09시50분
[.NET DBG] Loading Extension
; (broken) http://blogs.msdn.com/kikiwaka/archive/2009/02/02/net-dbg-loading-extension.aspx
kevin25

1  2  3  4  5  6  7  8  9  10  11  12  13  [14]  15  ...
NoWriterDateCnt.TitleFile(s)
13282정성태3/12/20233951Linux: 58. WSL - nohup 옵션이 필요한 경우
13281정성태3/12/20233889Windows: 225. 윈도우 바탕화면의 아이콘들이 넓게 퍼지는 경우 [2]
13280정성태3/9/20234642개발 환경 구성: 670. WSL 2에서 호스팅 중인 TCP 서버를 외부에서 접근하는 방법
13279정성태3/9/20234168오류 유형: 851. 파이썬 ModuleNotFoundError: No module named '_cffi_backend'
13278정성태3/8/20234178개발 환경 구성: 669. WSL 2의 (init이 아닌) systemd 지원 [1]
13277정성태3/6/20234818개발 환경 구성: 668. 코드 사인용 인증서 신청 및 적용 방법(예: Digicert)
13276정성태3/5/20234490.NET Framework: 2102. C# 11 - ref struct/ref field를 위해 새롭게 도입된 scoped 예약어
13275정성태3/3/20234797.NET Framework: 2101. C# 11의 ref 필드 설명
13274정성태3/2/20234360.NET Framework: 2100. C# - ref 필드로 ref struct 타입을 허용하지 않는 이유
13273정성태2/28/20234103.NET Framework: 2099. C# - 관리 포인터로서의 ref 예약어 의미
13272정성태2/27/20234362오류 유형: 850. SSMS - mdf 파일을 Attach 시킬 때 Operating system error 5: "5(Access is denied.)" 에러
13271정성태2/25/20234282오류 유형: 849. Sql Server Configuration Manager가 시작 메뉴에 없는 경우
13270정성태2/24/20233876.NET Framework: 2098. dotnet build에 /p 옵션을 적용 시 유의점
13269정성태2/23/20234443스크립트: 46. 파이썬 - uvicorn의 콘솔 출력을 UDP로 전송
13268정성태2/22/20234999개발 환경 구성: 667. WSL 2 내부에서 열고 있는 UDP 서버를 호스트 측에서 접속하는 방법
13267정성태2/21/20234913.NET Framework: 2097. C# - 비동기 소켓 사용 시 메모리 해제가 finalizer 단계에서 발생하는 사례파일 다운로드1
13266정성태2/20/20234525오류 유형: 848. .NET Core/5+ - Process terminated. Couldn't find a valid ICU package installed on the system
13265정성태2/18/20234437.NET Framework: 2096. .NET Core/5+ - PublishSingleFile 유형에 대한 runtimeconfig.json 설정
13264정성태2/17/20235965스크립트: 45. 파이썬 - uvicorn 사용자 정의 Logger 작성
13263정성태2/16/20234106개발 환경 구성: 666. 최신 버전의 ilasm.exe/ildasm.exe 사용하는 방법
13262정성태2/15/20235185디버깅 기술: 191. dnSpy를 이용한 (소스 코드가 없는) 닷넷 응용 프로그램 디버깅 방법 [1]
13261정성태2/15/20234428Windows: 224. Visual Studio - 영문 폰트가 Fullwidth Latin Character로 바뀌는 문제
13260정성태2/14/20234235오류 유형: 847. ilasm.exe 컴파일 오류 - error : syntax error at token '-' in ... -inf
13259정성태2/14/20234396.NET Framework: 2095. C# - .NET5부터 도입된 CollectionsMarshal
13258정성태2/13/20234267오류 유형: 846. .NET Framework 4.8 Developer Pack 설치 실패 - 0x81f40001
13257정성태2/13/20234359.NET Framework: 2094. C# - Job에 Process 포함하는 방법 [1]파일 다운로드1
1  2  3  4  5  6  7  8  9  10  11  12  13  [14]  15  ...