Microsoft MVP성태의 닷넷 이야기
글쓴 사람
홈페이지
첨부 파일
 

windbg의 lm 명령으로 보이지 않는 .NET 4.0 ClassLibrary를 명시적으로 로드하는 방법

재현을 간단하게 해볼 수 있습니다. 우선 다음과 같은 코드를 가진 라이브러리를 생성하고,

// ClassLibrary1.dll 프로젝트
using System;

namespace ClassLibrary1
{
    public class Class1
    {
        public void Do()
        {
            Console.WriteLine("TEST IS GOOD");
        }
    }
}

콘솔 EXE에서 이렇게 사용한 후,

// .NET 4.0 이상의 ConsoleApp1.exe 프로젝트
using System;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            ClassLibrary1.Class1 cl = new ClassLibrary1.Class1();
            cl.Do();

            Console.WriteLine("Press...");
            Console.ReadLine();
        }
    }
}

실행해서 Full Dump 파일을 받습니다. 이를 windbg에서 열어 lm 명령으로 확인하면,

0:000> lm
start    end        module name
00a60000 00a68000   ConsoleApp1   (deferred)             
601d0000 6155d000   mscorlib_ni   (deferred)             
72290000 722bf000   rsaenh     (deferred)             
...[생략]...
77270000 77363000   ole32      (deferred)             
77370000 77430000   rpcrt4     (deferred)             
774c0000 7764e000   ntdll      (pdb symbols)          C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\sym\wntdll.pdb\3E6B95F10656482A735FBE90515F548E1\wntdll.pdb

Unloaded modules:
75530000 75536000   psapi.dll

EXE 파일이었던 ConsoleApp1은 목록에 있는 반면, ClassLibrary1.dll은 보이질 않습니다. 찾아 보니 다음의 Q&A에 답이 나옵니다.

WinDbg lm command does not show all loaded modules.
; https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/263a3d84-8256-4f03-a70e-47d482a24cfb/windbg-lm-command-does-not-show-all-loaded-modules?forum=windbg

Solving .net source code lines problem in windbg with SOSEX
; https://debugandconquer.blogspot.kr/2016/08/solving-net-source-code-lines-problem.html

위의 글에서는 Process Explorer를 이용해 ClassLibrary1.dll의 실제 로딩 주소를 파악하는 방법이 나오는데요. 대개의 경우 full dump 파일을 얻는 상황은 실제 프로세스가 살아있지 않은 다른 PC에서 사용되는 것이 보통이므로 다른 방법이 있어야 합니다.

이를 위해 sos의 도움이 필요한데요, 다음과 같이 원하는 DLL에 포함된 심벌을 조회해 보면,

0:000> .loadby sos clr

0:000> !name2ee *!ClassLibrary1.Class1
Module:      601d1000
Assembly:    mscorlib.dll
--------------------------------------
Module:      00fe3ffc
Assembly:    ConsoleApp1.exe
--------------------------------------
Module:      00fe4e04
Assembly:    ClassLibrary1.dll
Token:       02000002
MethodTable: 00fe51f0
EEClass:     00fe295c
Name:        ClassLibrary1.Class1

ClassLibrary1.dll의 Module 주소를 구할 수 있고 이를 다음과 같이 .reload 명령어의 이미지 주소로 사용할 수 있습니다.

// 형식: .reload /f image_name=image_base_address

0:000> .reload /f ClassLibrary1.dll=00fe4e04

이후 다시 lm 명령을 내리면 다음과 같이 해당 DLL이 목록에 나타납니다.

0:000> lm
start    end        module name
00a60000 00a68000   ConsoleApp1   (deferred)             
00fe4e04 00fe4e04   ClassLibrary1   (no symbols)           
601d0000 6155d000   mscorlib_ni   (deferred)             
72290000 722bf000   rsaenh     (deferred)             
722c0000 722d3000   cryptsp    (deferred)             
722e0000 72360000   clrjit     (deferred)             
...[생략]...
77030000 77268000   combase    (deferred)             
77270000 77363000   ole32      (deferred)             
77370000 77430000   rpcrt4     (deferred)             
774c0000 7764e000   ntdll      (pdb symbols)          C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\sym\wntdll.pdb\3E6B95F10656482A735FBE90515F548E1\wntdll.pdb

Unloaded modules:
75530000 75536000   psapi.dll

그런데, 가만 보면 ConsoleApp1.exe의 Name2EE로 출력된 Module 주소가 00fe3ffc로 나오는 반면 lm의 ConsoleApp1.exe start 주소는 00a60000입니다. 이렇게 다른데도 정상적으로 이미지 로딩이 된 걸까요?

확인을 위해 각각의 모듈을 lm 출력 결과로 보이는 start 주소를 이용해 파일로 저장해 봤습니다.

0:000> !savemodule 00a60000 c:\temp\ConsoleApp1.exe
3 sections in file
section 0 - VA=2000, VASize=87c, FileAddr=200, FileSize=a00
section 1 - VA=4000, VASize=5bc, FileAddr=c00, FileSize=600
section 2 - VA=6000, VASize=c, FileAddr=1200, FileSize=200

0:000> !savemodule 00fe4e04 c:\temp\ClassLibrary1.dll
3 sections in file
section 0 - VA=2000, VASize=8dc, FileAddr=200, FileSize=a00
section 1 - VA=4000, VASize=398, FileAddr=c00, FileSize=400
section 2 - VA=6000, VASize=c, FileAddr=1000, FileSize=200

잘 저장이 되는 군요. ^^ 게다가 .NET Reflector 등의 디컴파일러 도구를 이용해 ClassLibrary1.dll을 조사해 보면 정상적으로 코드가 나오는 것을 확인할 수 있습니다.




참고로, .NET 3.5 대상으로 이 글의 예제를 빌드하면 lm 명령어의 출력에 정상적으로 나옵니다.

또한, !Name2EE로 심벌을 조사하는데 이때 원하는 DLL에 구현된 클래스를 알지 못해도 상관없습니다. 그냥 다음과 같이 아무 이름이나 넣으면,

!name2ee *!NOT_CARE

모든 닷넷 어셈블리들의 목록이 출력되고 그중 원하는 DLL의 Module 주소만 이용하면 됩니다. 그러니까, 한 가지 팁일 수 있는데요. 해당 프로세스에 로드된 모듈 목록은 lm 명령어로 확인할 수 있지만, 그 프로세스에 로드된 닷넷 모듈을 확인하는 명시적인 명령어는 없습니다. 하지만, "!name2ee *!ANYTHING"과 같은 식으로 명령을 주면 아쉬운 대로 닷넷 모듈 목록을 확인할 수 있습니다.




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 7/26/2017 ]

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

비밀번호

댓글 쓴 사람
 



2017-10-17 01시08분
windbg - .NET 4.0 이상의 환경에서 DLL의 심벌 파일 로드 방법
; http://www.sysnet.pe.kr/2/0/11330

windbg - .NET 4.0 이상의 환경에서 모든 DLL에 대한 심벌 파일을 로드하는 파이썬 스크립트
; http://www.sysnet.pe.kr/2/0/11331
정성태

... 31  32  33  34  35  36  37  [38]  39  40  41  42  43  44  45  ...
NoWriterDateCnt.TitleFile(s)
11282정성태9/11/20174437Math: 22. 행렬로 바라보는 피보나치 수열
11281정성태8/26/20174441.NET Framework: 677. Visual Studio 2017 - NuGet 패키지를 직접 참조하는 PackageReference 지원
11280정성태8/24/20173222디버깅 기술: 94. windbg - 풀 덤프에 포함된 모든 모듈을 파일로 저장하는 방법
11279정성태8/23/20177989.NET Framework: 676. C# Thread가 Running 상태인지 아는 방법
11278정성태8/23/20173666오류 유형: 417. TFS - Warning - Unable to refresh ... because you have a pending edit. [1]
11277정성태8/23/20174520오류 유형: 416. msbuild - error MSB4062: The "TransformXml" task could not be loaded from the assembly
11276정성태8/23/20176134.NET Framework: 675. C# - 확장자와 연결된 실행 파일 경로 찾기 [2]파일 다운로드1
11275정성태8/23/20179537개발 환경 구성: 323. Visual Studio 설치 없이 빌드 환경 구성 - Visual Studio 2017용 Build Tools
11274정성태8/22/20173891.NET Framework: 674. Thread 타입의 Suspend/Resume/Join 사용 관련 예외 처리
11273정성태8/22/20175989오류 유형: 415. 윈도우 업데이트 에러 Error 0x80070643
11272정성태8/21/20176654VS.NET IDE: 120. 비주얼 스튜디오 2017 버전 15.3.1 - C# 7.1 공개 [2]
11271정성태8/19/20173478VS.NET IDE: 119. Visual Studio 2017에서 .NET Core 2.0 프로젝트 환경 구성하는 방법
11270정성태4/20/201810125.NET Framework: 673. C#에서 enum을 boxing 없이 int로 변환하기 [2]
11269정성태8/17/20174073디버깅 기술: 93. windbg - 풀 덤프에서 .NET 스레드의 상태를 알아내는 방법
11268정성태8/14/20173993디버깅 기술: 92. windbg - C# Monitor Lock을 획득하고 있는 스레드 찾는 방법
11267정성태8/10/20175173.NET Framework: 672. 모노 개발 환경
11266정성태8/10/20174462.NET Framework: 671. C# 6.0 이상의 소스 코드를 Visual Studio 설치 없이 명령행에서 컴파일하는 방법
11265정성태2/25/201920988기타: 66. 도서: 시작하세요! C# 7.1 프로그래밍: 기본 문법부터 실전 예제까지 [11]
11264정성태8/9/20174367오류 유형: 414. UWP app을 signtool.exe로 서명 시 0x8007000b 오류 발생
11263정성태8/9/20174183오류 유형: 413. The C# project "..." is targeting ".NETFramework, Version=v4.0", which is not installed on this machine. [3]
11262정성태8/5/20174036오류 유형: 412. windbg - SOS does not support the current target architecture. [3]
11261정성태8/1/20183902디버깅 기술: 91. windbg - 풀 덤프 파일로부터 강력한 이름의 어셈블리 추출 후 사용하는 방법
11260정성태8/3/20173872.NET Framework: 670. C# - 실행 파일로부터 공개키를 추출하는 방법
11259정성태8/2/20173534.NET Framework: 669. 지연 서명된 어셈블리를 sn.exe -Vr 등록 없이 사용하는 방법
11258정성태8/1/20174186.NET Framework: 668. 지연 서명된 DLL과 서명된 DLL의 차이점파일 다운로드1
11257정성태7/31/20174225.NET Framework: 667. bypassTrustedAppStrongNames 옵션 설명파일 다운로드1
... 31  32  33  34  35  36  37  [38]  39  40  41  42  43  44  45  ...