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"과 같은 식으로 명령을 주면 아쉬운 대로 닷넷 모듈 목록을 확인할 수 있습니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]