(연관된 글이 3개 있습니다.)
3.4.1 VS.NET 2005 디버그 모드에서의 PDB 파일 사용 차이 (1)
이제까지 읽은 것으로 여러분들은 응용 프로그램이 예외가 발생했을 때 PDB 파일이 있음으로 해서 직접적인 오류 추적이 가능하다는 것을 보셨을 것입니다. 물론, 이벤트 로그 등을 통해서 사용자가 스택 트레이스 내용을 보내줄 수도 있지만 역시 뭐니 뭐니 해도 VS.NET 2005에서의 통합 환경에서 디버깅하는 것을 빼놓을 수 없습니다.
그럼, PDB 유무에 따라서 실제로 VS.NET 2005에서는 어떤 차이가 있는지 체험해 보도록 하겠습니다.
우선, BaseClassLibrary.dll과 BaseClassLibrary.pdb 파일을 3rd party에서 제공되는 라이브러리라고 여기고 이야기를 진행해 보겠습니다.
WinForm Application을 하나 만들고 다음과 같이 코딩을 합니다. ("1. PDB 파일에 따른 Debug 정보 - WinForm + Library 유형의 프로젝트"에서 설명한 것과 동일한 상황이지만, 단지 BaseClassLibrary를 프로젝트 참조가 아닌 DLL 참조로 합니다.)
1: private void Form1_Load(object sender, EventArgs e)
2: {
3: BaseLibrary.ThrowClass throwClass = new BaseLibrary.ThrowClass();
4: throwClass.TestMethod();
5: }
우선, PDB 파일이 없는 경우를 먼저 예를 들어 보겠습니다. 즉, 현재 테스트 하는 WinForm\bin\Debug 폴더에는 다음과 같은 파일들이 있어야 합니다.
BaseLibrary.dll
WinForm.exe
WinForm.pdb
WinForm.vshost.exe
WinForm은 우리가 제 3자가 만들어놓은 BaseLibrary를 이용해서 프로그램을 만드는 것입니다. 그러니 당연히(!) PDB 파일 및 소스 파일은 없고 Release 빌드된 BaseLibrary.dll만 있을 것입니다. 즉, 여기서는 throwClass.TestMethod()만 실행하면 예외가 발생하는 시나리오를 가정해 보는 것입니다.
디버그 정지점(Debug Break-point)을 4번째 줄인 "throwClass.TestMethod()"에 설정해 놓고 "F5" 키를 눌러서 디버깅을 시작할 것입니다. 그다음 "F11 (Step Into)" 키를 눌러 봅니다. 그렇게 되면 바로 다음 화면과 같이 오류 창이 뜨고는 더 이상 디버그는 진전이 되지 않습니다.
[그림 1: PDB 파일이 없는 경우의 F11 디버깅]
지금 단계에서, 여러분들이 할 수 있는 것은 더 이상 없습니다. 단지 BaseLibrary 라이브러리를 제작한 업체에게 오류 보고를 하는 수 밖에는 없습니다. ( VC++ 및 WinDBG에 능숙하다면 얘기가 달라지지만, 적어도 여러분이 현재는 .NET 개발자라는 가정하에 얘기를 진행합니다. )
하지만, 여러분들은 지금까지 이 토픽들에서 얻은 정보를 통해 PDB 파일이 있다면 원인 파악을 좀 더 자세하게 할 수 있음을 알고 있습니다. 따라서, 이젠 더 이상 업체의 늦은 대응을 기다릴 필요없이 능동적으로 PDB 파일을 요청할 수 있습니다. 다행히, 운이 좋아서 해당 모듈의 PDB 파일을 구할 수 있다고 가정하고 다음 얘기를 계속해서 진행해 보겠습니다. 이제, 여러분들은 업체로부터 받은 BaseLibrary.pdb 파일을 WinForm.exe가 있는 폴더에 복사해 넣습니다.
이제 새로운 기분으로 "F5" 키를 누르고 throwClass.TestMethod에서 "F11 (Step Into)" 키를 눌러 봅니다. 그럼 다음과 같이 Disassembly 창이 뜨고 함수의 Prologue 부분을 건너 뛰고 실제 코드 부분에 실행 화살표가 멈춰져 있는 것을 확인할 수 있습니다.
부담 갖지 말고, ^^ 이 부분을 찬찬히 한번 살펴볼까요?
우선, 그 이전의 라인들은 별로 살펴볼 필요가 없습니다. 말씀드렸듯이 함수의 Prologue 부분이므로 컴파일러에 의해서 자동으로 삽입되는 부분이어서 .NET JIT 컴파일러를 신뢰하는 것으로 그 부분은 넘어갈 수 있습니다.
중요한 것은 다음의 3라인인데요.
BP => 00000016 8B 0D 9C 6B 2E 02 mov ecx,dword ptr ds:[022E6B9Ch]
0000001c BA 03 00 00 00 mov edx,3
00000021 E8 86 CD 22 78 call 7822CDAC
이 부분이 정확히 어떤 역할을 하는지 더 파고 싶다면, sos(son of strike) 확장 디버깅 도구를 사용해야 합니다. 일단 이번 주제가 "PDB"이기 때문에 구체적인 sos 사용법은 넘어가고 대략 다음과 같은 방법을 통해서 인자값을 구할 수 있다는 것 정도만 알고 넘어가겠습니다.
1. ^^ 그동안 별로 쓰지 않았던 "Immediate Window"를 열고, 그 안에 다음과 같은 명령어를 통해 SOS 확장 DLL을 로드합니다.
.load sos
extension C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll loaded
2. 디버그 하고 있는 코드의 실제 주소를 얻어내기 위해서 "View" / "Registers" 메뉴를 선택해서 "Registers" 창을 띄웁니다. (이 메뉴가 보이지 않는다면, "Tools" / "Customize" 메뉴를 선택해서 "Debug" 범주에서 "Registers"를 선택합니다.)
다음은, 제 컴퓨터에서의 "Registers" 창의 내용입니다.
EAX = 00956690 EBX = 012E37C0 ECX = 012E8EB8 EDX = 012E8EC4 ESI = 012E8EB8
EDI = 00000000 EIP = 012402D6 ESP = 0012EBE0 EBP = 0012EC34 EFL = 00000246
CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 003B GS = 0000
OV = 0 UP = 0 EI = 1 PL = 0 ZR = 1 AC = 0 PE = 1 CY = 0
022E6B9C = 012E8EC4
위에서 강조되어 있는 EIP 레지스터의 내용이 현재 Instruction Pointer의 내용입니다. 따라서, 현재의 코드 실행 메모리 위치는 0x012402D6입니다.
3. 다시 "Immediate Window"로 돌아가서, 현재 명령어 위치의 IL 코드를 알아냅니다. 이를 위해 sos에서 제공하는 "u" 명령어에 IP 레지스터가 가리키는 값을 인자로 줍니다.
!u 0x012402D6
PDB symbol for mscorwks.dll not loaded
Normal JIT generated code
BaseLibrary.ThrowClass.TestMethod()
Begin 012402c0, size 36
012402C0 57 push edi
012402C1 56 push esi
012402C2 50 push eax
012402C3 890C24 mov dword ptr [esp],ecx
012402C6 833D7C64950000 cmp dword ptr ds:[0095647Ch],0
012402CD 7405 je 012402D4
012402CF E82A20E578 call 7A0922FE (JitHelp: CORINFO_HELP_DBG_IS_JUST_MY_CODE)
012402D4 33FF xor edi,edi
>>> 012402D6 8B0D9C6B2E02 mov ecx,dword ptr ds:[022E6B9Ch]
012402DC BA03000000 mov edx,3
012402E1 E886CD2278 call 7946D06C (System.IO.File.Open(System.String, System.IO.FileMode), mdToken: 060033db)
012402E6 8BF0 mov esi,eax
012402E8 8BFE mov edi,esi
012402EA 8BCF mov ecx,edi
012402EC 8B01 mov eax,dword ptr [ecx]
012402EE FF5070 call dword ptr [eax+70h]
012402F1 90 nop
012402F2 59 pop ecx
012402F3 5E pop esi
012402F4 5F pop edi
012402F5 C3 ret
4. 아하, call 명령어로 호출되는 함수는 System.IO.File.Open( string, FileMode );인 것을 알 수 있습니다. 그렇다면 ecx와 edx에 있는 값이 해당 메서드의 인자값이라는 것을 알 수 있습니다.
edx의 3 값은 FileMode의 Enum 값인 Open에 해당하는 군요. 그럼, 이제 ecx에 전달하는 값을 알아내야 하는데요. 간단하게 "F10" 키를 한번 눌러서 ecx에 대입하는 값을 알아내든가 아니면 [022e6b9c] 번지의 값을 Memory 창을 이용해서 알아낼 수도 있습니다.
이번 예제에서 제 컴퓨터에서는, ecx에 들어간 값은 "0x012E8EC4"입니다. 이 값은 System.String에 해당하는 값이므로 참조형의 개체 값임을 알 수 있습니다. 따라서, sos에서 제공하는 DumpObj 명령어를 통해서 해당 개체를 덤프해 볼 수 있습니다.
!dumpobj 0x012e8ec4
Name: System.String
MethodTable: 790fa3e0
EEClass: 790fa340
Size: 58(0x3a) bytes
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: C:\\test_nothing.txt
Fields:
MT Field Offset Type VT Attr Value Name
790fed1c 4000096 4 System.Int32 0 instance 21 m_arrayLength
790fed1c 4000097 8 System.Int32 0 instance 20 m_stringLength
790fbefc 4000098 c System.Char 0 instance 43 m_firstChar
790fa3e0 4000099 10 System.String 0 shared static Empty
>> Domain:Value 0014ceb0:790d6584 <<
79124670 400009a 14 System.Char[] 0 shared static WhitespaceChars
>> Domain:Value 0014ceb0:012e16dc <<
친절하게도 String 형인 경우에는 위와 같이 그 값까지 문자열로 덤프해 주고 있습니다. (이 예제에서는 예외 메시지에서 해당 문자열을 보여주고 있기는 하지만, 예외에서 인자 값을 보여주는 경우는 많지 않으므로 여기서는 그 값이 예외에서 나오지 않는다고 가정합니다.)
자, 이 정도면 훌륭하게 트레이스가 된 것 같습니다. 이제 여러분들은 BaseLibrary를 만든 업체에게 여러분들의 트레이스 결과를 알려줄 수 있습니다. 이쯤 되면, 해당 업체는 더 이상 트레이스 관련해서 시간을 지체하지 않고 바로 버그가 패치된 버전을 내놓게 될 것입니다.
이번 예제는 WinForm에서 예를 들었지만 Web Application에서도 동일하게 적용해 볼 수 있습니다.
[연관 글]