Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

Windbg - Visual Studio 디버그 상태에서 종료해 버리는 응용 프로그램

개인적으로 Windbg는 여전히 낯설기만 합니다. 그만큼 Visual Studio의 편리한 디버깅에 익숙해져 있다는 것인데요. ^^ 그래도, 가끔은 어쩔 수 없이 사용하는 경우가 있는데, 이번 사례가 바로 그에 해당합니다.

오늘은 소스 코드 리팩토링과 함께 DLL 이름도 좀 정리를 했는데, 불행히도 Visual Studio IDE에서 'F5 디버깅'을 시작하고 aspx 웹 페이지가 실행되려는 부분 즈음, 곧바로 WebDev 프로세스가 다운되고 Visual Studio의 디버깅 상태가 해제되었습니다.

"Output" 창에는 아래와 같이 WebDev 종료만 기록될 뿐 이외의 도움이 될만한 아무런 정보를 찾을 수가 없었습니다.

...[생략: DLL 로딩]...
'WebDev.WebServer20.EXE' (Managed (v2.0.50727)): Loaded 'C:\Windows\assembly\GAC_MSIL\MyTest\1.0.1.0__rhaasdf44088eb\MyTest.dll'
The program '[5240] WebDev.WebServer20.EXE: Managed (v2.0.50727)' has exited with code -532459699 (0xe0434f4d).

어디, 이벤트 로그를 한번 볼까요?

Fault bucket , type 0
Event Name: CLR20r3
Response: Not available
Cab Id: 0

Problem signature:
P1: webdev.webserver20.exe
P2: 10.0.0.0
P3: 4ba204ca
P4: WebDev.WebHost20
P5: 10.0.0.0
P6: 4ba204c2
P7: 56
P8: 51
P9: Exception
P10: 

Attached files:
...[생략]...

위의 Watson bucket들에 대한 해석은 다음을 참고하십시오.

Watson Bucket 정보를 이용한 CLR 응용 프로그램 예외 분석
; https://www.sysnet.pe.kr/2/0/595

예전에도 소개해 드렸던 아래의 글처럼, Watson bucket 정보가 도움이 안 되는 경우들이 있는데요.

System.MissingMethodException
; https://www.sysnet.pe.kr/2/0/909

이번에도 마찬가지입니다. "P1: webdev.webserver20.exe" 값만 보아도 우리가 만든 코드가 아닌 webdev 안에서 예외가 있다고 하니 그다지 도움되는 사항은 아닙니다.

이쯤 되면, Windbg는 더 이상 피하고 싶은 상대가 아니라, 이나마도 기댈 곳이 있다는 사실에 저절로 감사의 마음마저 생깁니다. ^^ 문제 해결의 난이도는 그 원인에 의존적인데, 다행히 제 경우에는 어렵지 않은 쪽이었습니다. 어디, 같이 한번 해볼까요? ^^

우선, WebDev 프로세스를 Windbg에서 디버깅하려면, "File" / "Open Executable" 메뉴에서 다음과 같이 실행 파일 환경 값을 입력해 주어야 합니다.

File name: "C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\10.0\WebDev.WebServer20.exe"
Arguments: /port:[포트명] /path:[웹 사이트 폴더 경로] /vpath:"[프로젝트에 설정된 웹 루트 경로]" 

제 경우에는 다음과 같이 설정되었습니다.

File name: "C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\10.0\WebDev.WebServer20.exe"
Arguments: /port:19448 /path:"D:\...[생략]...\WebSiteTest" /vpath:"/" 

확인하고 나면, 프로세스가 시작되자마자 멈추게 되고, "g" 키를 눌러서 예외가 발생할 때까지 실행되도록 진행시킵니다. 잠시 후, 다음과 같이 예외가 발생하게 되고 Windbg 환경이므로 디버기(WebDev)는 Visual Studio에서 그랬던 것과는 다르게, 종료 수순까지 가지 못하고 멈추게 됩니다. 바로 이 능력 때문에 Windbg를 사용해서 문제 해결이 가능하지요. ^^ (물론, Visual Studio 내에서도 'F10' 키를 이용해서 시작부터 디버깅을 건 다음 단계별로 추적해 나갈 수 있지만, 역시나 이런 상황에서는 'F5'와 동일한 'g' 키를 이용할 수 있다는 것이 Windbg의 장점이겠지요. ^^)

ModLoad: 53510000 53528000   MyTest.dll
ModLoad: 0cd00000 0cd18000   MyTest.dll
ModLoad: 53510000 53528000   C:\Windows\assembly\GAC_MSIL\MyTest\1.0.1.0__rhaasdf44088eb\MyTest.dll
(1b04.195c): C++ EH exception - code e06d7363 (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): C++ EH exception - code e06d7363 (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): C++ EH exception - code e06d7363 (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): C++ EH exception - code e06d7363 (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): CLR exception - code e0434f4d (first chance)
(1b04.195c): CLR exception - code e0434f4d (!!! second chance !!!)
eax=0807de48 ebx=e0434f4d ecx=00000001 edx=00000000 esi=0807ded0 edi=06c68a38
eip=7638b727 esp=0807de48 ebp=0807de98 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
KERNELBASE!RaiseException+0x58:
7638b727 c9              leave

닷넷 환경이므로, 다음의 명령어를 통해 SOS.dll을 로드시킵니다.

.loadby sos mscorwks

현재, 예외가 발생해서 멈춘 것이므로 "!printexception" 명령문으로 어떤 예외가 발생했는지 확인해 봅니다.

0:006> !printexception
Exception object: 02cc80ec
Exception type: System.TypeInitializationException
Message: The type initializer for 'MyTest.TestApp' threw an exception.
InnerException: System.IO.FileNotFoundException, use !PrintException 02cc83a4 to see more
StackTrace (generated):
    SP       IP       Function
    0807F6B0 08E61F2D WebDev_WebHost20!Microsoft.VisualStudio.WebHost.Server.OnSocketAccept(System.Object)+0x7d
    0807F6C4 077D2F0F mscorlib!System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(System.Object)+0x2f
    0807F6CC 077D2DCA mscorlib!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+0x5a
    0807F6E4 077D2D59 mscorlib!System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(System.Threading._ThreadPoolWaitCallback)+0x51
    0807F6F8 077D2BF5 mscorlib!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(System.Object)+0x5d

StackTraceString: <none>
HResult: 80131534

그렇군요. .cctor에서 예외가 발생했는데, 간혹 이런 경우 강제 종료로까지 이어지기도 합니다. 개인적인 경험상, .cctor에 기능을 집어넣는 것이 여간 조심스럽지 않습니다. 왜냐하면, 문제가 발생했을 때 일반 메서드의 상황과 비교해서 추적이 어려워지기 때문입니다.

아무튼, 현재 보고 있는 예외 개체 타입은 "System.TypeInitializationException"이고, 그 인스턴스는 "02cc80ec" 값입니다. 다행히 InnerException을 가지고 있는데 그 값은 "02cc83a4"이고 친절하게도 Windbg에서 "use !PrintException 02cc83a4 to see more"라고 까지 메시지를 출력해 주고 있습니다. 이번 경우처럼 cctor에서 발생한 예외에서 InnerException은 실질적인 오류 상황을 보여주므로 파고들어가봐야 합니다.

0:006> !PrintException 02cc83a4
Exception object: 02cc83a4
Exception type: System.IO.FileNotFoundException
Message: Could not load file or assembly 'SecondLib, Version=1.0.1.0, Culture=neutral, PublicKeyToken=rhaasdf44088eb' or one of its dependencies. The system cannot find the file specified.
InnerException: <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80070002

아하, 답이 나왔군요. 리팩터링 과정에서 파일명을 바꿨는데, 참조한 측에서는 이름이 바뀐 것을 프로젝트 참조해서 빌드 시 오류가 발생하지 않았던 반면 실행 시에 GAC에 등록되어 있지 않아서 예외가 발생한 것이었습니다. SecondLib.dll 등록을 잊었던 것이지요. 하지만, Visual Studio의 디버거 창에서는 이와 관련된 어떠한 정보도 얻을 수 없었지만, Windbg로 하는 경우에는 이렇게 정상적으로 디버깅을 할 수 있어서 문제 해결이 쉬웠던 것입니다.

음... 디바이스 드라이버 개발자가 아니더라도, Windbg는 분명 닷넷 개발자에게도 친해져야 할 대상입니다. ^^



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







[최초 등록일: ]
[최종 수정일: 6/27/2021]

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

비밀번호

댓글 작성자
 



2010-12-06 11시59분
[땡초] 친해지고 시퍼영~~~~~~~~~~~~~~~~
[guest]
2019-01-24 04시25분
정성태
2020-06-25 09시32분
Time Travel Debugging을 사용한 윈도우즈 리버스 엔지니어링 1
; https://learn.darungrim.com/contents/time-travel-debugging-01.html#disqus_thread
정성태

1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13560정성태2/19/20242056디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20242937오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20242161닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241913Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241956Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20242112닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20241856VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241938닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241887닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242084닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20242198Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20242500개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20242330개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242084개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20241941Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20241858닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20241882오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20241880Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20241912오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20241954VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20242075Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20242364개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20242415닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20242500닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/20242587닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
13535정성태1/22/20242430닷넷: 2208. C# - GCHandle 구조체의 메모리 분석
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...