Microsoft MVP성태의 닷넷 이야기
디버깅 기술: 5.8. WinDBG를 이용한 미니덤프 파일 분석 [링크 복사], [링크+제목 복사]
조회: 27044
글쓴 사람
정성태 (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)
13560정성태2/19/20242081디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20242943오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20242167닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241920Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241962Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20242116닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20241861VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241942닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241893닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242089닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20242206Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20242503개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20242332개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242085개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20241942Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20241859닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20241883오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20241881Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20241913오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20241955VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20242076Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20242365개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20242418닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20242501닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/20242592닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
13535정성태1/22/20242451닷넷: 2208. C# - GCHandle 구조체의 메모리 분석
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...