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

windbg - k 명령어와 !clrstack을 조합한 호출 스택을 얻는 방법

SOS 확장의 !clrstack 명령어는 관리 호출 스택을 얻을 수 있습니다.

0:000> !clrstack
OS Thread Id: 0x6164 (0)
        Child SP               IP Call Site
000000f26fb6eb28 00007ff97e4c5ef4 [HelperMethodFrame_1OBJ: 000000f26fb6eb28] System.Threading.Thread.JoinInternal(Int32)
000000f26fb6ec30 00007ff904090778 ConsoleApp1.Program.WaitForThreadExit(System.Threading.Thread)
000000f26fb6ec60 00007ff904090634 ConsoleApp1.Program.Main(System.String[])
000000f26fb6ef40 00007ff9636b6793 [GCFrame: 000000f26fb6ef40] 

또한 windbg의 내장 명령어인 k 명령어로는 네이티브 호출 스택을 얻을 수 있습니다.

0:000> k
 # Child-SP          RetAddr           Call Site
00 000000f2`6fb6e4a8 00007ff9`7b29dd20 ntdll!NtWaitForMultipleObjects+0x14
01 000000f2`6fb6e4b0 00007ff9`638569ca KERNELBASE!WaitForMultipleObjectsEx+0xf0
02 000000f2`6fb6e7b0 00007ff9`63856864 clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x62
03 000000f2`6fb6e810 00007ff9`6385665d clr!Thread::DoAppropriateWaitWorker+0x1e4
04 000000f2`6fb6e910 00007ff9`637e37da clr!Thread::DoAppropriateWait+0x7d
05 000000f2`6fb6e990 00007ff9`637e3a68 clr!Thread::JoinEx+0xa2
06 000000f2`6fb6ea30 00007ff9`637e38ec clr!ThreadNative::DoJoin+0xfe
07 000000f2`6fb6eac0 00007ff9`04090778 clr!ThreadNative::Join+0xec
08 000000f2`6fb6ec30 00007ff9`04090634 0x00007ff9`04090778
09 000000f2`6fb6ec60 00007ff9`636b6793 0x00007ff9`04090634
0a 000000f2`6fb6ed10 00007ff9`636b6665 clr!CallDescrWorkerInternal+0x83
0b 000000f2`6fb6ed50 00007ff9`636b736d clr!CallDescrWorkerWithHandler+0x4e
0c 000000f2`6fb6ed90 00007ff9`637b38b0 clr!MethodDescCallSite::CallTargetWorker+0xf8
0d 000000f2`6fb6ee90 00007ff9`637b40fa clr!RunMain+0x1e7
0e 000000f2`6fb6f070 00007ff9`637b3fb7 clr!Assembly::ExecuteMainMethod+0xb6
0f 000000f2`6fb6f360 00007ff9`637b394d clr!SystemDomain::ExecuteMainMethod+0x639
10 000000f2`6fb6f980 00007ff9`637b3732 clr!ExecuteEXE+0x3f
11 000000f2`6fb6f9f0 00007ff9`637b46a4 clr!_CorExeMainInternal+0xb2
12 000000f2`6fb6fa80 00007ff9`6337a56d clr!CorExeMain+0x14
13 000000f2`6fb6fac0 00007ff9`6351a44c mscoreei!CorExeMain+0x112
14 000000f2`6fb6fb20 00007ff9`7df12774 mscoree!CorExeMain_Exported+0x6c
15 000000f2`6fb6fb50 00007ff9`7e490d51 kernel32!BaseThreadInitThunk+0x14
16 000000f2`6fb6fb80 00000000`00000000 ntdll!RtlUserThreadStart+0x21

위의 출력 결과를 보면 중간에 "Call Site"가 주소로만 나오는 영역의 "Child-SP"를 !clrstack과 연결해 보면 실은 관리 메서드 호출임을 알 수 있습니다. 그렇다면 이 2개의 조합된 출력 결과를 얻으려면 어떻게 해야 할까요?

참고로, SOS 확장의 !dumpstack 메서드가 이런 용도로 제공이 되고는 있습니다. 하지만, 아래의 출력 결과에서 볼 수 있는 것처럼 그 내용이 너무 많아 가독성이 많이 떨어집니다.

0:000> !dumpstack
OS Thread Id: 0x6164 (0)
Current frame: ntdll!NtWaitForMultipleObjects+0x14
Child-SP         RetAddr          Caller, Callee
000000f26fb6e4a0 00007ff97b29dd20 KERNELBASE!WaitForMultipleObjectsEx+0xf0, calling ntdll!NtWaitForMultipleObjects
000000f26fb6e4b0 00007ff97e450f20 ntdll!RtlFreeHeap+0x150, calling ntdll!RtlGetCurrentServiceSessionId
000000f26fb6e540 00007ff97b29de1f KERNELBASE!WaitForMultipleObjectsEx+0x1ef, calling ntdll!RtlActivateActivationContextUnsafeFast
000000f26fb6e560 00007ff9636c2471 clr!ListLockEntry::`scalar deleting destructor'+0xe1
000000f26fb6e5a0 00007ff9636b5f7c clr!CrstBase::Leave+0x30, calling ntdll!RtlLeaveCriticalSection
000000f26fb6e5d0 00007ff9636c51dd clr!MethodDesc::MakeJitWorker+0x862, calling clr!CrstBase::Leave
000000f26fb6e660 00007ff9636b6071 clr!ClrFlsIncrementValue+0x29
000000f26fb6e690 00007ff9636c1936 clr!LoaderHeap::RealAllocMemUnsafe+0x236, calling clr!ClrFlsIncrementValue
000000f26fb6e720 00007ff9636b5f7c clr!CrstBase::Leave+0x30, calling ntdll!RtlLeaveCriticalSection
000000f26fb6e740 00007ff963735f08 clr!MethodDesc::IsTightlyBoundToMethodTable+0x21, calling clr!MethodDesc::IsInstantiatingStub
000000f26fb6e750 00007ff9636c1d26 clr!ECall::GetFCallImpl+0x152, calling clr!CrstBase::Leave
000000f26fb6e770 00007ff9636bef85 clr!Precode::SetTargetInterlocked+0x414, calling kernel32!FlushInstructionCacheStub
000000f26fb6e7a0 00007ff9638569ca clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x62, calling kernel32!WaitForMultipleObjectsEx
000000f26fb6e7d0 00007ff9636bba42 clr!Thread::GetFinalApartment+0x1a, calling clr!Thread::GetApartment
000000f26fb6e800 00007ff963856864 clr!Thread::DoAppropriateWaitWorker+0x1e4, calling clr!WaitForMultipleObjectsEx_SO_TOLERANT
000000f26fb6e830 00007ff96379c5f6 clr!ThreadNative::StartInner+0x3ac, calling clr!ObjHeader::LeaveObjMonitor
000000f26fb6e900 00007ff96385665d clr!Thread::DoAppropriateWait+0x7d, calling clr!Thread::DoAppropriateWaitWorker
000000f26fb6e980 00007ff9637e37da clr!Thread::JoinEx+0xa2, calling clr!Thread::DoAppropriateWait
000000f26fb6e9d0 00007ff9637f03eb clr!Thread::IncExternalCount+0x1c, calling clr!GetThread
000000f26fb6ea20 00007ff9637e3a68 clr!ThreadNative::DoJoin+0xfe, calling clr!Thread::JoinEx
000000f26fb6eab0 00007ff9637e38ec clr!ThreadNative::Join+0xec, calling clr!ThreadNative::DoJoin
000000f26fb6ebe8 00007ff9637e3876 clr!ThreadNative::Join+0x76, calling clr!LazyMachStateCaptureState
000000f26fb6ec20 00007ff904090778 (MethodDesc 00007ff903f859c0 +0x28 ConsoleApp1.Program.WaitForThreadExit(System.Threading.Thread)), calling (MethodDesc 00007ff961ee3980 +0 System.Threading.Thread.Join())
000000f26fb6ec50 00007ff904090634 (MethodDesc 00007ff903f859b0 +0x1b4 ConsoleApp1.Program.Main(System.String[])), calling 00007ff904090080 (stub for ConsoleApp1.Program.WaitForThreadExit(System.Threading.Thread))
000000f26fb6ed00 00007ff9636b6793 clr!CallDescrWorkerInternal+0x83
000000f26fb6ed40 00007ff9636b6665 clr!CallDescrWorkerWithHandler+0x4e, calling clr!CallDescrWorkerInternal
000000f26fb6ed50 00007ff9638138af clr!ArgIteratorTemplate<ArgIteratorBase>::GetNextOffset+0xda, calling clr!MetaSig::GetElemSize
000000f26fb6ed80 00007ff9636b736d clr!MethodDescCallSite::CallTargetWorker+0xf8, calling clr!CallDescrWorkerWithHandler
000000f26fb6edd0 00007ff9637b4c69 clr!MethodDesc::IsVoid+0x21, calling clr!MetaSig::IsReturnTypeVoid
000000f26fb6ee80 00007ff9637b38b0 clr!RunMain+0x1e7, calling clr!MethodDescCallSite::CallTargetWorker
000000f26fb6eef0 00007ff97b2b76b3 KERNELBASE!QuirkIsEnabled3+0x23, calling kernel32!QuirkIsEnabled3Worker
000000f26fb6f020 00007ff963823f70 clr!Thread::SetBackground+0x9f, calling clr!ThreadSuspend::UnlockThreadStore
000000f26fb6f060 00007ff9637b40fa clr!Assembly::ExecuteMainMethod+0xb6, calling clr!RunMain
000000f26fb6f090 00007ff97e44af7e ntdll!RtlpAllocateHeapInternal+0xfe, calling ntdll!RtlpLowFragHeapAllocFromContext
000000f26fb6f0e0 00007ff9637fe874 clr!SString::GetUnicode+0x4d, calling clr!_security_check_cookie
000000f26fb6f120 00007ff9638138fe clr!MetaSig::SkipArg+0x2e, calling clr!SigParser::SkipExactlyOne
000000f26fb6f130 00007ff97e451208 ntdll!RtlFreeHeap+0x438, calling ntdll!RtlpIsSubSegmentReuseable
000000f26fb6f170 00007ff9636b6969 clr!EEHeapFreeInProcessHeap+0x45, calling kernel32!HeapFreeStub
000000f26fb6f1a0 00007ff9636ee473 clr!SString::~SString+0x3e
000000f26fb6f1b0 00007ff97e450f20 ntdll!RtlFreeHeap+0x150, calling ntdll!RtlGetCurrentServiceSessionId
000000f26fb6f1e0 00007ff97b28988f KERNELBASE!WaitForSingleObjectEx+0x9f, calling ntdll!NtWaitForSingleObject
000000f26fb6f1f0 00007ff97e450f20 ntdll!RtlFreeHeap+0x150, calling ntdll!RtlGetCurrentServiceSessionId
000000f26fb6f210 00007ff9637643dc clr!AppDomain::GetFriendlyNameForDebugger+0x48, calling clr!SString::GetUnicode
000000f26fb6f270 00007ff9636b6969 clr!EEHeapFreeInProcessHeap+0x45, calling kernel32!HeapFreeStub
000000f26fb6f2c0 00007ff96374bb90 clr!CLRConfig::GetConfigValue+0x14, calling clr!CLRConfig::GetConfigValue
000000f26fb6f2e0 00007ff9636b69b9 clr!operator delete+0x29
000000f26fb6f2f0 00007ff963768b47 clr!MulticoreJitManager::AutoStartProfile+0x60, calling clr!Wrapper<unsigned short * __ptr64,&DoNothing<unsigned short * __ptr64>,&CLRConfig::FreeConfigString,0,&CompareDefault<unsigned short * __ptr64>,2,1>::~Wrapper<unsigned short * __ptr64,&DoNothing<unsigned short * __ptr64>,&CLRConfig::FreeConfigString,0,&CompareDefault<unsigned short * __ptr64>,2,1>
000000f26fb6f310 00007ff9636ee27a clr!Wrapper<IAssemblyName * __ptr64,&DoNothing<IAssemblyName * __ptr64>,&DoTheRelease<IAssemblyName>,0,&CompareDefault<IAssemblyName * __ptr64>,2,1>::~Wrapper<IAssemblyName * __ptr64,&DoNothing<IAssemblyName * __ptr64>,&DoTheRelease<IAssemblyName>,0,&CompareDefault<IAssemblyName * __ptr64>,2,1>+0x52
000000f26fb6f320 00007ff9636b6131 clr!Frame::Pop+0xe, calling clr!GetThread
000000f26fb6f350 00007ff9637b3fb7 clr!SystemDomain::ExecuteMainMethod+0x639, calling clr!Assembly::ExecuteMainMethod
000000f26fb6f380 00007ff9636b4f65 clr!REGUTIL::RegCacheValueNameSeenPerhaps+0x29, calling clr!HashiStringKnownLower80
000000f26fb6f5f0 00007ff9636bd29c clr!AllocateObject+0xbc
000000f26fb6f620 00007ff9636bc7f4 clr!HndCreateHandle+0xe0, calling clr!StressLog::LogOn
000000f26fb6f670 00007ff9638247ad clr!CreateGlobalHandle+0xe, calling clr!GetCurrentThreadHomeHeapNumber
000000f26fb6f6a0 00007ff96377a593 clr!AppDomain::SetupSharedStatics+0xf0, calling clr!ErectWriteBarrier
000000f26fb6f6c0 00007ff9637a55d5 clr!SafeHandle::Init+0x41, calling clr!MethodDesc::GetSlot
000000f26fb6f6f0 00007ff9637ac915 clr!EEStartupHelper+0x795, calling clr!ConfigDWORD::val
000000f26fb6f910 00007ff9637ac155 clr!EEStartup+0x15, calling clr!EEStartupHelper
000000f26fb6f970 00007ff9637b394d clr!ExecuteEXE+0x3f, calling clr!SystemDomain::ExecuteMainMethod
000000f26fb6f9e0 00007ff9637b3732 clr!_CorExeMainInternal+0xb2, calling clr!ExecuteEXE
000000f26fb6fa40 00007ff97e47a670 ntdll!RtlSetLastWin32Error+0x40, calling ntdll!_security_check_cookie
000000f26fb6fa70 00007ff9637b46a4 clr!CorExeMain+0x14, calling clr!_CorExeMainInternal
000000f26fb6fab0 00007ff96337a56d mscoreei!CorExeMain+0x112
000000f26fb6fae0 00007ff963511504 mscoree!GetShimImpl+0x18, calling mscoree!InitShimImpl
000000f26fb6faf0 00007ff96351a4cf mscoree!CorExeMain_Exported+0xef, calling kernel32!GetProcAddressStub
000000f26fb6fb10 00007ff96351a44c mscoree!CorExeMain_Exported+0x6c, calling mscoree!guard_dispatch_icall_nop
000000f26fb6fb40 00007ff97df12774 kernel32!BaseThreadInitThunk+0x14, calling kernel32!guard_dispatch_icall_nop
000000f26fb6fb70 00007ff97e490d51 ntdll!RtlUserThreadStart+0x21, calling ntdll!guard_dispatch_icall_nop

그래서 개인적으로 사용하는 방법이 "DebugDiag Analysis" 도구입니다.

Debug Diagnostic Tool v2 Update 2 
; https://www.microsoft.com/en-us/download/details.aspx?id=49924

이것을 사용하면 분석 결과로 개별 스레드에 대해 ".NET Call Stack"과 "Full Call Stack"을 각각 다음과 같은 식으로 보여줍니다.

.NET Call Stack

[[HelperMethodFrame_1OBJ] (System.Threading.Thread.JoinInternal)] System.Threading.Thread.JoinInternal(Int32) 
ConsoleApp1.Program.WaitForThreadExit(System.Threading.Thread)+28 
ConsoleApp1.Program.Main(System.String[])+1b4 

Full Call Stack

ntdll!NtWaitForMultipleObjects+14 
KERNELBASE!WaitForMultipleObjectsEx+f0 
clr!WaitForMultipleObjectsEx_SO_TOLERANT+62 
clr!Thread::DoAppropriateWaitWorker+1e4 
clr!Thread::DoAppropriateWait+7d 
clr!Thread::JoinEx+a2 
clr!ThreadNative::DoJoin+fe 
clr!ThreadNative::Join+ec 
[[HelperMethodFrame_1OBJ] (System.Threading.Thread.JoinInternal)] System.Threading.Thread.JoinInternal(Int32) 
ConsoleApp1.Program.WaitForThreadExit(System.Threading.Thread)+28 
ConsoleApp1.Program.Main(System.String[])+1b4 
clr!CallDescrWorkerInternal+83 
clr!CallDescrWorkerWithHandler+4e 
clr!MethodDescCallSite::CallTargetWorker+f8 
clr!RunMain+1e7 
[[GCFrame]] 
clr!Assembly::ExecuteMainMethod+b6 
clr!SystemDomain::ExecuteMainMethod+639 
clr!ExecuteEXE+3f 
clr!_CorExeMainInternal+b2 
clr!CorExeMain+14 
mscoreei!CorExeMain+112 
mscoree!CorExeMain_Exported+6c 
kernel32!BaseThreadInitThunk+14 
ntdll!RtlUserThreadStart+21 

즉, 다듬어진 내용으로 k 명령어와 !clrstack의 출력 결과가 합쳐져서 보이는 것입니다.

이런저런 이유와 함께 저는 메모리 덤프 파일을 분석할 때면 무조건 "DebugDiag Analysis" 도구로 분석 결과를 생성한 후 같이 참조하면서 windbg로 분석합니다. ^^




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







[최초 등록일: ]
[최종 수정일: 10/18/2017]

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

비밀번호

댓글 작성자
 




... 121  122  123  124  125  126  127  [128]  129  130  131  132  133  134  135  ...
NoWriterDateCnt.TitleFile(s)
1856정성태2/15/201521277.NET Framework: 493. TypeRef 메타테이블에 등록되는 타입의 조건파일 다운로드1
1855정성태2/10/201520805개발 환경 구성: 256. WebDAV Redirector - Sysinternals 폴더 연결 시 "The network path was not found" 오류 해결 방법
1854정성태2/10/201521803Windows: 104. 폴더는 삭제할 수 없지만, 그 하위 폴더/파일은 생성/삭제/변경하는 보안 설정
1853정성태2/6/201552069웹: 29. 여신금융협회 웹 사이트의 "Netscape 6.0은 지원하지 않습니다." 오류 메시지 [5]
1852정성태2/5/201522488.NET Framework: 492. .NET CLR Memory 성능 카운터의 의미파일 다운로드1
1851정성태2/5/201523409VC++: 88. 하룻밤의 꿈 - 인텔 하스웰의 TSX Instruction 지원 [2]
1850정성태2/4/201544309Windows: 103. 작업 관리자에서의 "Commit size"가 가리키는 메모리의 의미 [4]
1849정성태2/4/201524194기타: 51. DropBox의 CPU 100% 현상 [1]파일 다운로드1
1848정성태2/4/201519461.NET Framework: 491. 닷넷 Generic 타입의 메타 데이터 토큰 값 알아내는 방법 [2]
1847정성태2/3/201522813기타: 50. C# - 윈도우에서 dropbox 동기화 폴더 경로 및 종료하는 방법
1846정성태2/2/201532028Windows: 102. 제어판의 프로그램 추가/삭제 항목을 수동으로 실행하고 싶다면? [1]
1845정성태1/26/201532908Windows: 101. 제어판의 "Windows 자격 증명 관리(Manage your credentials)"를 금지시키는 방법
1844정성태1/26/201530863오류 유형: 269. USB 메모리의 용량이 비정상적으로 보여진다면? [7]
1843정성태1/24/201521927VC++: 87. 무시할 수 없는 Visual C++ 런타임 함수 성능
1842정성태1/23/201544463개발 환경 구성: 255. 노트북 키보드에 없는 BREAK 키를 다른 키로 대체하는 방법
1841정성태1/21/201519414오류 유형: 268. Win32 핸들 관련 CLR4 보안 오류 사례
1840정성태1/8/201527628오류 유형: 267. Visual Studio - CodeLens 사용 시 CPU 100% 현상
1839정성태1/5/201520535디버깅 기술: 69. windbg 분석 사례 - cpu 100% 현상 (2)
1838정성태1/4/201540240기타: 49. 윈도우 내레이터(Narrator) 기능 끄는 방법(윈도우에 파란색의 굵은 테두리 선이 나타난다면?) [4]
1837정성태1/4/201526361디버깅 기술: 68. windbg 분석 사례 - 메모리 부족 [1]
1836정성태1/4/201526373디버깅 기술: 67. windbg - 덤프 파일과 handle 정보
1835정성태1/3/201526859개발 환경 구성: 254. SQL 서버 역시 SSL 3.0/TLS 1.0만을 지원하는 듯!
1834정성태1/3/201551497개발 환경 구성: 253. TLS 1.2를 적용한 IIS 웹 사이트 구성
1833정성태1/3/201527583.NET Framework: 490. System.Data.SqlClient는 SSL 3.0/TLS 1.0만 지원하는 듯! [3]
1832정성태1/2/201520654오류 유형: 266. Azure에 응용 프로그램 게시 중 로그인 오류
1831정성태1/1/201528535디버깅 기술: 66. windbg 분석 사례 - cpu 100% 현상 (1) [1]
... 121  122  123  124  125  126  127  [128]  129  130  131  132  133  134  135  ...