예외 발생 시 Minidump 생성 - WinDBG
제 개인적으로, 버그는 "내 컴퓨터에서 재현이 된다는 것만으로도 이미 99%는 해결된 것이나 다름없다."라는 주의를 가지고 있지만, 애석하게도 그것이 (내가 접근할 수 없는 네트워크의) "다른 컴퓨터"로 바뀐다면 그 확률은 현저하게 낮아지게 됩니다. 이렇게 낮아진 확률을 그나마 높여줄 수 있는 것이 바로, "WinDBG + 미니덤프 파일"입니다. (물론, 미니 덤프를 가지고도 디버깅이 어렵다면 직접 찾아가는 서비스를 ^^ 제공해야겠지만.)
자, 그래서 역시나 이번에도 관련 토픽을 먼저 소개해 드리는 것으로 시작하겠습니다.
BUGSLAYER - Minidumps for Specific Exceptions
; https://learn.microsoft.com/en-us/archive/msdn-magazine/2006/november/bugslayer-minidumps-for-specific-exceptions
Managed Custome Exception을 adplus.vbs로 잡는 방법
; http://byung.egloos.com/2864284
Managed Exception을 잡자!!
; http://byung.egloos.com/2263286
당연히! 읽기만 해서는 안되죠! ^^ 내 것으로 만들어야지. 그런 의미에서 ... 정리를 해볼까요!
adplus와 같은 (VB 스크립트로 만들어진) 툴도 있긴 하지만, 여기서는 순수하게 windbg.exe만을 이용해서, 특정 CLR 예외가 발생했을 때 그 시점의 미니덤프를 뜨는 방법을 설명해 보겠습니다. 이젠 뭐... 지난 토픽들에서 기초적인 것은 많이 설명했기 때문에 "sxe ld mscorwks", ".loadby sos mscorwks" 같은 것은 건너뛰겠습니다.
CLR 예외를 잡는 방법은, 예상할 수 있듯이 sos.dll에서 제공이 됩니다. 이미 앞에서 bpmd, clrstack, dumpobj와 같은 명령어들을 익혀봤는데요. 이번에 우리에게 필요한 것은 바로 "soe" 확장 명령어입니다. (참고로, soe는 원래 "StopOnException" 함수와 동일한 기능을 하는, 그저 이름만 축약된 함수입니다.)
"soe" 확장 명령어의 실습을 위해 다음과 같은 간단한 예제를 작성해 보겠습니다.
======= ConsoleApplication1.exe =======
using System;
using System.Collections.Generic;
using System.Text;
using ClassLibrary1;
using System.Diagnostics;
namespace ConsoleApplication1
{
class Program
{
static void Main()
{
try
{
new Class1().MyMethod("test", 5);
} catch ( Exception )
{
// TODO: 이벤트 로그에 오류 기록
throw;
}
}
}
}
======= ClassLibrary1.dll =======
using System;
using System.Collections.Generic;
using System.Text;
namespace ClassLibrary1
{
public class Class1
{
string str;
public void MyMethod(string arg)
{
throw new ApplicationException(arg);
}
}
}
자, 여기서 우리가 원하는 것은 ApplicationException 예외가 발생하는 시점에 실행을 멈추는 것입니다. 즉, 최초 "throw new ApplicationException" 코드에서 스택이 풀리지 않은 상태로 디버깅을 하기를 원하는 것이지, 그 이후의 try/catch에서 다시 throw 되는 시점에서 디버깅을 하고 싶은 것은 아닙니다.
이런 경우, "throw new ApplicationException"과 (catch 내부의) throw로 인해 2번의 "first-chance exception"이 발생하게 됩니다. 그중에서 "throw new ApplicationException"은 예외 처리기가 있기 때문에 그냥 넘어가게 되지만, (catch 내부의) throw 같은 경우에는 적절한 예외 처리기가 없어서 다시 "second-chance exception"이 발생하게 됩니다. 대부분의 디버거는 특별한 예외 설정을 제외하고는, "first-chance exception"은 통지만 받고서는 그냥 넘긴 후, "second-chance exception"이 발생했을 때에야 "debug-mode"로 진입하게 됩니다. 즉, 위의 코드에서는 디버거가 (catch 내부의) throw에 대해서만 정지하게 되고, 처음의 "throw new ApplicationException"에서는 정지하지 않습니다.
물론, 이렇게 되면 문제가 있습니다. 왜냐하면, catch 내부에서 디버그 모드로 진입하는 경우에는 이미 예외가 발생한 시점의 호출 스택이 전부 풀려버린 상태이기 때문에 직접적으로 예외를 해결할 수 있는 단서가 날아가게 됩니다.
우리는 명백히, 특정한 예외가 처음 발생하는 그 곳, 바로 "first-chance exception" 통지를 받는 그 시점에 디버거로 하여금 "디버그 모드"로 진입하기를 원합니다. 그리고, 그러한 목적을 달성해 줄 수 있도록 "soe" 확장 명령어가 제공되는 것입니다.
soe 확장 명령어는 보통 다음과 같은 식으로 사용합니다.
!soe [option] [예외 클래스 명] [0~19]
일례로, 위의 예제를 기준으로 "ApplicationException" 발생 시점에 디버그 모드로 진입하기를 원한다면 다음과 같이 명령을 내려줄 수 있습니다.
!soe -create System.ApplicationException 3
마지막 인자인 숫자 "3"은 "User-Defined Pseudo-Registers"에 대한 번호이며, 가용한 번호는 $t0 ~ $t19까지 총 20개가 마련되어 있습니다.
실제로, 이 명령을 내린 후 어떻게 windbg에 설정되어 있는지 알고 싶다면 "sx" 명령으로 확인할 수 있습니다. 위와 같은 명령의 경우에는 다음과 같이 출력됩니다.
...[중간생략]...
clr - CLR exception - break - not handled
Command: "!soe System.InvalidOperationException 3;
.if(@$t3==0) {g} .else {.echo 'System.InvalidOperationException hit'}"
...[중간생략]...
이걸로 soe 명령어가 하는 일이 확실해 졌습니다. 엄밀히, soe 명령어는 첫 번째 인자로 들어오는 "예외" 상황이 발생하게 되면 가상 레지스터의 값을 1로 바꿔줍니다. 위의 "if" 문에서 보이듯이 $t3 == 0인 경우에는 그대로 실행이 진행되어지고({g} 명령), $t3 == 1인 경우에는 echo 문자열을 찍고 실행이 멈추게 됩니다.
그럼, 거의 다 해결이 되었군요. ^^ 우리가 하려는 것은 해당 예외가 발생했을 때 미니 덤프 파일을 남기는 것이므로, 위의 명령어중에서 ".echo" 부분을 미니 덤프를 남기는 명령어로 바꿔주면 그만입니다.
이를 위해, windbg.exe의 "Debug" / "Event Filters..." 메뉴를 선택한 후 나오는 대화창에서 "CLR exception" 항목을 선택합니다. 그럼, 우측의 "Command" 버튼이 활성화되어지고, 그것을 누르면 아래와 같은 명령어 편집 대화 상자가 나오게 됩니다.
다 되었습니다. ".echo" 출력 부분을 다음과 같이 미니 덤프를 출력하는 문으로 대체해 주시면 됩니다.
!soe System.ApplicationException 3;.if(@$t3==0) {g} .else {.dump /ma /u c:\\temp\\ConsoleApp.dmp;}
[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]