WinDbg 분석 사례 - IISreset 시점에 w3wp.exe의 crash 발생
이번 사례는 매우 쉽게 해결된 것으로 Full Memory Dump 분석을 너무 어려운 대상이라고 생각하는 분들을 위해서 올려봅니다. ^^
이상하게도, 웹 애플리케이션이 평소에는 아무런 문제가 없는데 iisreset을 하는 시점만 되면 꼭 비정상 종료가 발생합니다. 다행히 테스트 서버에서 발생한 현상이라
원격 디버깅 도구를 연결해 봤는데요, 웬일인지 (iisreset의 영향 때문인 듯) 원인 파악을 위한 단계까지 못 들어가고 그전에 디버깅 세션이 종료해 버립니다.
어쩔 수 없군요, 그렇다면 덤프가 나서야 합니다. ^^
// 참고: 시작하자마자 비정상 종료하는 프로세스의 메모리 덤프 - procdump
// 관리자 권한으로 실행
C:\temp> procdump -ma -i c:\temp
이후 iisreset을 하면 덤프가 생성되고,
Debug Analysis에 맡겨 자동 분석했더니 이런 결과가 나왔습니다.
...[생략]...
Analysis Summary
Error
Description Recommendation
In w3wp.exe_...103043.dmp the assembly instruction at coreclr!ProcessCLRException+101a13 in C:\TestWebApp\coreclr.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to read from memory location 0x00000000 on thread 22
Please follow up with the vendor Microsoft Corporation for C:\TestWebApp\coreclr.dll
Notification
Description Recommendation
DebugDiag determined that this dump file (w3wp.exe_...103043.dmp) is a crash dump and did not perform any hang analysis. To run both hang rules and crash rules on crash dumps, select the following option in the 'Preferences' tab of the 'Settings' page in DebugDiag.Analysis.exe:
'For crash dumps, run hang rules and crash rules'
Analysis Details
CrashHangAnalysis
Report for w3wp.exe_...103043.dmp
Type of Analysis Performed Crash Analysis
Machine Name WIN2019
Operating System Windows Server - 17763
Number Of Processors 4
Process ID 2320
Process Image c:\Windows\System32\inetsrv\w3wp.exe
Command Line c:\windows\system32\inetsrv\w3wp.exe -ap "TestWebApp" -v "v4.0" -l "webengine4.dll" -a \\.\pipe\iisipm24f866b3-407d-42cc-a459-31564ff6c55a -h "C:\inetpub\temp\apppools\TestWebApp\TestWebApp.config" -w "" -m 0 -t 20 -ta 0
System Up-Time 02:08:35
Process Up-Time 00:03:46
Processor Type X64
Process Bitness 64-Bit
Faulting Thread
Entry point coreclr!Thread::intermediateThreadProc
Create time 2025-06-29 오전 10:27:01
Time spent in user mode 0 Days 0:0:0.250
Time spent in kernel mode 0 Days 0:0:0.15
.NET Call Stack
TestWebApp.MyClass.GetWindowInfo(Int32)+be
[[InlinedCallFrame] (TestWebApp.MyClass.GetInfo)] TestWebApp.MyClass.GetInfo(Int32)
TestWebApp.ThreadProc.Run(System.Object)+261
System.Threading.ThreadHelper.ThreadStart_Context(System.Object)+c1
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+fffffffffed32eb4
System.Threading.ThreadHelper.ThreadStart(System.Object)+5e
[[GCFrame]]
[[DebuggerU2MCatchHandlerFrame]]
Full Call Stack
Arg 1 Arg 2 Arg 3 Arg 4 Source
coreclr!EEPolicy::HandleFatalError+8b [f:\workspace\_work\1\s\src\vm\eepolicy.cpp @ 1177] 0000000`00000000 0000000`00000000 0000000`00000000 00002d2`b1a73ab0 f:\workspace\_work\1\s\src\vm\eepolicy.cpp @ 1177
coreclr!ProcessCLRException+101a2e [f:\workspace\_work\1\s\src\vm\exceptionhandling.cpp @ 1043 + 30] 00000eb`4f28e970 00000eb`4f28ebc0 00053d0`00000000 00000eb`4f28e300 f:\workspace\_work\1\s\src\vm\exceptionhandling.cpp @ 1043 + 30
ntdll!RtlpExecuteHandlerForException+f 00000eb`4f28e290 0000000`00000000 0007ff8`4ce960ac 0007ff8`4cae0000
ntdll!RtlDispatchException+40f 0000000`00000000 0000000`00000104 0000000`00000001 0007ff8`39aaa3d9
ntdll!KiUserExceptionDispatch+2e 0000000`00000025 0000000`00000000 00000eb`4f28ebd0 0007ff7`db81f9e7
TestWebApp.MyClass.GetWindowInfo(Int32)+be 0000000`00000001 00002ce`660985b0 0007ff7`db4d1a8e 00048cd`4aa75421
TestWebApp.MyClass.GetInfo()+21 0000000`00000000 0000000`00000000 0000000`00000000 0000000`00000000
TestWebApp.ThreadProc.Run(System.Object)+261 0000000`00000000 0000000`00000000 0000000`00000000 0000000`00000000
System.Threading.ThreadHelper.ThreadStart_Context(System.Object)+c1 0000000`00000000 0000000`00000000 0000000`00000000 0000000`00000000
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+fffffffffed32eb4 0000000`00000000 0000000`00000000 0000000`00000000 0000000`00000000
System.Threading.ThreadHelper.ThreadStart(System.Object)+5e 0000000`00000000 0000000`00000000 0000000`00000000 0000000`00000000
CLR Information
There are multiple CLR Runtimes loaded in this process:
CLR version = 4.700.20.6603 (this runtime was selected for analysis)
CLR version = 4.8.4785.0
Microsoft.Diagnostics.Runtime version = 0.9.2.0
Exception Information
CORECLR!PROCESSCLREXCEPTION+101A13In w3wp.exe_...103043.dmp the assembly instruction at coreclr!ProcessCLRException+101a13 in C:\TestWebApp\coreclr.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to read from memory location 0x00000000 on thread 22
Module Information
Image Name: C:\TestWebApp\coreclr.dll Symbol Type: PDB
Base address: 0x00000003`00905a4d Time Stamp: Fri Jan 17 11:44:10 2020
Checksum: 0x00000000`00000000 Comments: Flavor=Retail
COM DLL: False Company Name: Microsoft Corporation
ISAPIExtension: False File Description: Microsoft .NET Runtime
ISAPIFilter: False File Version: 4,700,20,6603 @Commit: 259ce7d4619478cfefe7b0c0f6fa765f765f7e37
Managed DLL: False Internal Name: CoreCLR.dll
VB DLL: False Legal Copyright:
Loaded Image Name: coreclr.dll Legal Trademarks:
Mapped Image Name: Original filename: CoreCLR.dll
Module name: coreclr Private Build:
Single Threaded: False Product Name:
Module Size: 5.41 MBytes Product Version: 4,700,20,6603 @Commit: 259ce7d4619478cfefe7b0c0f6fa765f765f7e37
Symbol File Name: e:\symbols\coreclr.pdb\60646608BDB040698AF8C9430E7E480E1\coreclr.pdb Special Build: &
Analysis Rule Summary
Rule Name Status Details
CrashHangAnalysis - v (2.3.2.11) Completed
Table of Contents
CrashHangAnalysis
Report for w3wp.exe_...103043.dmp
Faulting Thread
오호~~~ 아주 정확하게 원인이 나왔군요, ^^ 자신이 만든 어떤 메서드에서 오류가 발생했다는 것과 재현이 가능하다는 사실에 기반해 어느 부분에서 문제가 발생했는지 유추할 수 있을 것입니다.
회사에서 개발한 제품이 고객사에 설치돼 문제가 발생하는 경우, 대개 원격으로 접속하거나 출장 가야 하는 수밖에 없습니다. (그나마 코로나 시기를 지나면서 원격을 열어주는 고객사가 많아져서 좋군요. ^^) 그런데 문제는, 출장이든 원격이든 결국 문제는 고객사 측의 서버에서 발생한 경우이고, 운이 나쁘다면 테스트 서버가 아닌 실제 운영 서버에서 발생한 경우도 있다는 점입니다. 그런 상황에서 업무 서버에 Visual Studio를 설치하고 디버깅을 하는 것은 현실적으로 불가능하고, 대안으로
Remote Tools를 설치해 원격 디버깅을 고려할 수도 있지만 이것도 쉽지 않을 수 있습니다.
바로 그럴 때 "
Full Memory Dump"가 해결책이 될 수 있습니다. 즉, 전반적인 환경과 문제점만 파악하고 메모리 덤프만 확보한 후 나오는 것입니다. 그 후, (고객사에서는 부릴 수 없었던) 여유를 가지고 느긋하게 자신의 익숙한 PC에서 덤프를 분석하면 되는 것입니다.
실제로 최근 사례의 경우, 캄보디아에서
제니퍼가 설치됐는데 모니터링이 동작하지 않는다는 이슈가 올라온 적이 있었는데요, 금융 업무라서 원격도 열어주지 못하는 상황이었습니다. 하지만 다행히 메모리 덤프는 가능하다고 해 파일 전송으로 받아 제 자리에서 분석 후 패치를 했었습니다. 만약, 메모리 덤프가 없었다면... 아마도 캄보디아까지 직접 가야만 했을 지도 모를 일입니다. ^^;
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]