Microsoft MVP성태의 닷넷 이야기
디버깅 기술: 5.8. WinDBG를 이용한 미니덤프 파일 분석 [링크 복사], [링크+제목 복사],
조회: 32017
글쓴 사람
정성태 (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

... 121  122  123  124  125  126  127  128  129  130  [131]  132  133  134  135  ...
NoWriterDateCnt.TitleFile(s)
1780정성태10/15/201424164오류 유형: 249. The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
1779정성태10/15/201419678오류 유형: 248. Active Directory에서 OU가 지워지지 않는 경우
1778정성태10/10/201418129오류 유형: 247. The Netlogon service could not create server share C:\Windows\SYSVOL\sysvol\[도메인명]\SCRIPTS.
1777정성태10/10/201421216오류 유형: 246. The processing of Group Policy failed. Windows attempted to read the file \\[도메인]\sysvol\[도메인]\Policies\{...GUID...}\gpt.ini
1776정성태10/10/201418271오류 유형: 245. 이벤트 로그 - Name resolution for the name _ldap._tcp.dc._msdcs.[도메인명]. timed out after none of the configured DNS servers responded.
1775정성태10/9/201419392오류 유형: 244. Visual Studio 디버깅 (2) - Unable to break execution. This process is not currently executing the type of code that you selected to debug.
1774정성태10/9/201426595개발 환경 구성: 246. IIS 작업자 프로세스의 20분 자동 재생(Recycle)을 끄는 방법
1773정성태10/8/201429765.NET Framework: 471. 웹 브라우저로 다운로드가 되는 파일을 왜 C# 코드로 하면 안되는 걸까요? [1]
1772정성태10/3/201418547.NET Framework: 470. C# 3.0의 기본 인자(default parameter)가 .NET 1.1/2.0에서도 실행될까? [3]
1771정성태10/2/201428056개발 환경 구성: 245. 실행된 프로세스(EXE)의 명령행 인자를 확인하고 싶다면 - Sysmon [4]
1770정성태10/2/201421678개발 환경 구성: 244. 매크로 정의를 이용해 파일 하나로 C++과 C#에서 공유하는 방법 [1]파일 다운로드1
1769정성태10/1/201424099개발 환경 구성: 243. Scala 개발 환경 구성(JVM, 닷넷) [1]
1768정성태10/1/201419521개발 환경 구성: 242. 배치 파일에서 Thread.Sleep 효과를 주는 방법 [5]
1767정성태10/1/201424624VS.NET IDE: 94. Visual Studio 2012/2013에서의 매크로 구현 - Visual Commander [2]
1766정성태10/1/201422442개발 환경 구성: 241. 책 "프로그래밍 클로저: Lisp"을 읽고 나서. [1]
1765정성태9/30/201426040.NET Framework: 469. Unity3d에서 transform을 변수에 할당해 사용하는 특별한 이유가 있을까요?
1764정성태9/30/201422268오류 유형: 243. 파일 삭제가 안 되는 경우 - The action can't be comleted because the file is open in System
1763정성태9/30/201423845.NET Framework: 468. PDB 파일을 연동해 소스 코드 라인 정보를 알아내는 방법파일 다운로드1
1762정성태9/30/201424545.NET Framework: 467. 닷넷에서 EIP/RIP 레지스터 값을 구하는 방법 [1]파일 다운로드1
1761정성태9/29/201421556.NET Framework: 466. 윈도우 운영체제의 보안 그룹 이름 및 설명 문자열을 바꾸는 방법파일 다운로드1
1760정성태9/28/201419821.NET Framework: 465. ICorProfilerInfo::GetILToNativeMapping 메서드가 0x80131358을 반환하는 경우
1759정성태9/27/201430968개발 환경 구성: 240. Visual C++ / x64 환경에서 inline-assembly를 매크로 어셈블리로 대체하는 방법파일 다운로드1
1758정성태9/23/201437852개발 환경 구성: 239. 원격 데스크톱 접속(RDP)을 기존의 콘솔 모드처럼 사용하는 방법 [1]
1757정성태9/23/201418390오류 유형: 242. Lync로 모임 참여 시 소리만 들리지 않는 경우 - 두 번째 이야기
1756정성태9/23/201427391기타: 48. NVidia 제품의 과다한 디스크 사용 [2]
1755정성태9/22/201434189오류 유형: 241. Unity Web Player를 설치해도 여전히 설치하라는 화면이 나오는 경우 [4]
... 121  122  123  124  125  126  127  128  129  130  [131]  132  133  134  135  ...