Microsoft MVP성태의 닷넷 이야기
디버깅 기술: 5.8. WinDBG를 이용한 미니덤프 파일 분석 [링크 복사], [링크+제목 복사],
조회: 31897
글쓴 사람
정성태 (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)
13718정성태8/27/20247455오류 유형: 921. Visual C++ - error C1083: Cannot open include file: 'float.h': No such file or directory [2]
13717정성태8/26/20247057VS.NET IDE: 192. Visual Studio 2022 - Windows XP / 2003용 C/C++ 프로젝트 빌드
13716정성태8/21/20246770C/C++: 167. Visual C++ - 윈도우 환경에서 _execv 동작 [1]
13715정성태8/19/20247404Linux: 78. 리눅스 C/C++ - 특정 버전의 glibc 빌드 (docker-glibc-builder)
13714정성태8/19/20246773닷넷: 2295. C# 12 - 기본 생성자(Primary constructors) (책 오타 수정) [3]
13713정성태8/16/20247516개발 환경 구성: 721. WSL 2에서의 Hyper-V Socket 연동
13712정성태8/14/20247233개발 환경 구성: 720. Synology NAS - docker 원격 제어를 위한 TCP 바인딩 추가
13711정성태8/13/20248088Linux: 77. C# / Linux - zombie process (defunct process) [1]파일 다운로드1
13710정성태8/8/20248018닷넷: 2294. C# 13 - (6) iterator 또는 비동기 메서드에서 ref와 unsafe 사용을 부분적으로 허용파일 다운로드1
13709정성태8/7/20247770닷넷: 2293. C# - safe/unsafe 문맥에 대한 C# 13의 (하위 호환을 깨는) 변화파일 다운로드1
13708정성태8/7/20247567개발 환경 구성: 719. ffmpeg / YoutubeExplode - mp4 동영상 파일로부터 Audio 파일 추출
13707정성태8/6/20247797닷넷: 2292. C# - 자식 프로세스의 출력이 4,096보다 많은 경우 Process.WaitForExit 호출 시 hang 현상파일 다운로드1
13706정성태8/5/20247923개발 환경 구성: 718. Hyper-V - 리눅스 VM에 새로운 디스크 추가
13705정성태8/4/20248175닷넷: 2291. C# 13 - (5) params 인자 타입으로 컬렉션 허용 [2]파일 다운로드1
13704정성태8/2/20248137닷넷: 2290. C# - 간이 dotnet-dump 프로그램 만들기파일 다운로드1
13703정성태8/1/20247466닷넷: 2289. "dotnet-dump ps" 명령어가 닷넷 프로세스를 찾는 방법
13702정성태7/31/20247886닷넷: 2288. Collection 식을 지원하는 사용자 정의 타입을 CollectionBuilder 특성으로 성능 보완파일 다운로드1
13701정성태7/30/20248146닷넷: 2287. C# 13 - (4) Indexer를 이용한 개체 초기화 구문에서 System.Index 연산자 허용파일 다운로드1
13700정성태7/29/20247771디버깅 기술: 200. DLL Export/Import의 Hint 의미
13699정성태7/27/20248273닷넷: 2286. C# 13 - (3) Monitor를 대체할 Lock 타입파일 다운로드1
13698정성태7/27/20248225닷넷: 2285. C# - async 메서드에서의 System.Threading.Lock 잠금 처리파일 다운로드1
13697정성태7/26/20247934닷넷: 2284. C# - async 메서드에서의 lock/Monitor.Enter/Exit 잠금 처리파일 다운로드1
13696정성태7/26/20247471오류 유형: 920. dotnet publish - error NETSDK1047: Assets file '...\obj\project.assets.json' doesn't have a target for '...'
13695정성태7/25/20247462닷넷: 2283. C# - Lock / Wait 상태에서도 STA COM 메서드 호출 처리파일 다운로드1
13694정성태7/25/20247923닷넷: 2282. C# - ASP.NET Core Web App의 Request 용량 상한값 (Kestrel, IIS)
13693정성태7/24/20247249개발 환경 구성: 717. Visual Studio - C# 프로젝트에서 레지스트리에 등록하지 않은 COM 개체 참조 및 사용 방법파일 다운로드1
1  2  3  4  5  6  7  8  [9]  10  11  12  13  14  15  ...