Microsoft MVP성태의 닷넷 이야기
글쓴 사람
홈페이지
첨부 파일
 

windbg - (x64에서의 인자 값 추적을 이용한) Thread.Abort 시 대상이 되는 스레드를 식별하는 방법

예전 글이 생각나는군요. ^^

Thread.Abort 호출의 hang 현상
; https://www.sysnet.pe.kr/2/0/1617

최근에 저 현상을 또다시 겪었습니다. 메모리 덤프를 떠서 확인한 결과 Thread.Abort 호출이 반환되지 않는 경우였습니다. 이 글에서는 해당 메모리 덤프를 분석한 결과를 공유합니다. ^^

그나저나, Thread.Abort로 종료시키려고 했던 대상 스레드가 궁금했습니다. 우선 Thread.Abort를 호출한 코드의 콜 스택은 이랬습니다.

0:045> !clrstack
OS Thread Id: 0x18b4 (45)
Child SP         IP               Call Site
0000000020dad5d8 000000007725c2ea [HelperMethodFrame_1OBJ: 0000000020dad5d8] System.Threading.Thread.AbortInternal()
0000000020dad6f0 000007ff0326a26a System.Threading.Thread.Abort()
0000000020dad730 000007ff0326a196 WebApp.Library.CallStack.CancelThread()
0000000020dad790 000007ff027c7c7b WebApp.Library.CallStack.CheckThread(WebApp.Library.State, System.Action, Int32)
0000000020dad7e0 000007ff027c7b6f WebApp.Library.CallStack.CheckValue(Int32)
0000000020dad850 000007ff027bb59c WebApp.BaseLib.Dumper.monitorFunc()
0000000020dad8b0 000007ff025fa678 System.Threading.ExecutionContext.runTryCode(System.Object)
0000000020dadfd8 000007fef885c9e4 [HelperMethodFrame_PROTECTOBJ: 0000000020dadfd8] System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object)
0000000020dae100 000007ff007de3f6 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
0000000020dae160 000007ff025f8fab System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
0000000020dae1b0 000007ff026bbb3d System.Threading.ThreadHelper.ThreadStart()
0000000020dae608 000007fef885c9e4 [GCFrame: 0000000020dae608] 
0000000020dae9f0 000007fef885c9e4 [DebuggerU2MCatchHandlerFrame: 0000000020dae9f0] 
0000000020daebc8 000007fef885c9e4 [ContextTransitionFrame: 0000000020daebc8] 
0000000020daedb0 000007fef885c9e4 [DebuggerU2MCatchHandlerFrame: 0000000020daedb0] 

Abort 메서드 호출이 다음과 같은 식이기 때문에,

Thread t1 = new Thread(threadFunc);
// ...[생략]...
t1.Abort();

(C# 코드 상으로는 안 보이는) Abort 메서드의 첫 번째 인자, 즉 x64의 경우 rcx에 들어온 인자가 t1 스레드를 가리키게 되지만, 아쉽게도 위의 호출 스택은 .NET Managed 호출 스택만 보여주기 때문에 rcx 인자 값을 살펴봐서는 안됩니다. 왜냐하면 실제로 다음과 같이 Native 함수까지 포함한 호출 스택을 보면 현재 CPU의 rcx 레지스터 값은 Abort 메서드를 호출한 시점의 rcx 값과는 전혀 무관한 값으로 채워져 있을 가능성이 크기 때문입니다.

0:045> kv
 # Child-SP          RetAddr           : Args to Child                                                           : Call Site
00 00000000`20dacfa8 000007fe`fd1d1430 : 00000000`00000000 00000000`00000001 00000000`1aefe390 00000000`ffffffff : ntdll!NtWaitForMultipleObjects+0xa
01 00000000`20dacfb0 00000000`770116e3 : 00000000`20dad0e8 00000000`20dad0e0 00000000`00000000 00000000`00077bd0 : KERNELBASE!WaitForMultipleObjectsEx+0xe8
02 00000000`20dad0b0 000007fe`f89ef8e1 : 00000000`00000000 00000000`00000000 00000000`1aefd570 00000000`00000001 : kernel32!WaitForMultipleObjectsExImplementation+0xb3
03 00000000`20dad140 000007fe`f89ef6ba : 00000000`00000001 00000000`20dad448 00000000`00000001 00000000`20dad448 : clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x91
04 00000000`20dad1d0 000007fe`f89ef545 : 00000000`00000000 00000000`20dad2b9 00000000`1aefd570 00000000`2027c040 : clr!Thread::DoAppropriateAptStateWait+0x56
05 00000000`20dad210 000007fe`f89ef63b : 00000000`1aefd570 00000000`00000001 00000000`20dad448 00000000`00000000 : clr!Thread::DoAppropriateWaitWorker+0x1b1
06 00000000`20dad310 000007fe`f896ff6a : 00000000`00000001 000007fe`00000001 00000000`00b3bf50 000007fe`f8978031 : clr!Thread::DoAppropriateWait+0x73
07 00000000`20dad390 000007fe`f8c1bae6 : 00000000`00000000 00000000`1aefe390 00000000`1aefe390 00000000`00000d14 : clr!Thread::JoinEx+0xa6
08 00000000`20dad430 000007fe`f8a29cc3 : 00000001`1fab1220 000007fe`00000000 00000000`00000001 00000000`00000000 : clr! ?? ::FNODOBFM::`string'+0xa2d89
09 00000000`20dad540 000007ff`0326a26a : 00000000`20dadae8 00000001`5fb259d8 00000000`00000000 00000000`00000000 : clr!ThreadNative::Abort+0x14b
0a 00000000`20dad6f0 000007ff`0326a196 : 00000001`1fab1220 00000001`1fab0ca8 00000001`605cfa88 00000000`00000fa0 : 0x000007ff`0326a26a
0b 00000000`20dad730 000007ff`027c7c7b : 00000001`1fab0c68 00000001`1fab0ca8 00000001`605cfa88 00000000`00000fa0 : 0x000007ff`0326a196
0c 00000000`20dad790 000007ff`027c7b6f : 00000001`1fab0c68 00000001`1fab0ca8 00000001`605cfa88 00000001`00000fa0 : 0x000007ff`027c7c7b
0d 00000000`20dad7e0 000007ff`027bb59c : 00000001`1fab0c68 00000000`00000fa0 00000000`20dad1d0 00000000`00000001 : 0x000007ff`027c7b6f
0e 00000000`20dad850 000007ff`025fa678 : 00000001`1fab07c8 00000001`1fab0960 00000000`00000000 00000000`00000000 : 0x000007ff`027bb59c
0f 00000000`20dad8b0 000007fe`f885c9e4 : 00000001`2fc130d0 00000001`5fb259d8 00000000`00000000 00000000`00000000 : 0x000007ff`025fa678
..[생략]...
28 00000000`20dafa00 00000000`7723a561 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
29 00000000`20dafa30 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

어쨌든 중요한 것은 System.Threading.Thread.Abort가 호출된 시점의 rcx 값을 알아내야 한다는 것입니다.

가만 보니, clr!ThreadNative::Abort 아래에 있는 항목(Call Site: 0x000007ff`0326a26a)을 보면 Child-SP 값이 00000000`20dad6f0라고 나오고 이 값은 !clrstack의 System.Threading.Thread.Abort와 일치합니다. 그럼, 일단 Abort 메서드부터 시작해 보겠습니다.

0:048> !U /d 000007ff01c5d7fa
Normal JIT generated code
System.Threading.Thread.Abort()
Begin 000007ff01c5d7d0, size 31
000007ff`01c5d7d0 53              push    rbx
000007ff`01c5d7d1 4883ec30        sub     rsp,30h
000007ff`01c5d7d5 488bd9          mov     rbx,rcx
000007ff`01c5d7d8 48c744242000000000 mov   qword ptr [rsp+20h],0
000007ff`01c5d7e1 488d542420      lea     rdx,[rsp+20h]
000007ff`01c5d7e6 488d0db33559fe  lea     rcx,[000007ff`001f0da0]
000007ff`01c5d7ed e8de8105f8      call    clr!JIT_Security_Prolog (000007fe`f9cb59d0)
000007ff`01c5d7f2 488bcb          mov     rcx,rbx
000007ff`01c5d7f5 e87ec321f8      call    clr!ThreadNative::Abort (000007fe`f9e79b78)
>>> 000007ff`01c5d7fa 90              nop
000007ff`01c5d7fb 4883c430        add     rsp,30h
000007ff`01c5d7ff 5b              pop     rbx
000007ff`01c5d800 c3              ret

System.Threading.Thread.Abort의 부모 메서드가 전달한 첫 번째 인자(rcx)를 잠시 rbx에 보관 후 다시 rcx를 이용해 clr!ThreadNative::Abort에 전달하고 있습니다. 즉, 위의 머신 코드에서는 첫 번째 인자에 대한 값이 Thread Stack에 전혀 남아 있지 않습니다. 그렇다면 이쯤에서 우리는 선택을 해야 합니다. 이후의 분석을 rcx를 전달한 부모 쪽으로 가야 할지, rcx를 넘기며 호출한 자식 쪽으로 가야 할지에 대해서입니다.

달리 말하면, 부모 호출 쪽으로 가게 되면 managed 코드이고, 자식 호출 쪽으로 가게 되면 native가 되니 당연히 분석의 난이도를 봤을 때 선택은 부모 쪽이 낫습니다.

0:048> !U /d 000007ff01c5d726
Normal JIT generated code
WebApp.Library.CallStack.CancelThread()
Begin 000007ff01c5d6e0, size bd
000007ff`01c5d6e0 48894c2408      mov     qword ptr [rsp+8],rcx
000007ff`01c5d6e5 55              push    rbp
000007ff`01c5d6e6 4883ec50        sub     rsp,50h
000007ff`01c5d6ea 488d6c2420      lea     rbp,[rsp+20h]
000007ff`01c5d6ef 48896500        mov     qword ptr [rbp],rsp
000007ff`01c5d6f3 48b830597600ff070000 mov rax,7FF00765930h
000007ff`01c5d6fd 8b00            mov     eax,dword ptr [rax]
000007ff`01c5d6ff 85c0            test    eax,eax
000007ff`01c5d701 7405            je      000007ff`01c5d708
000007ff`01c5d703 e858ce47f8      call    clr!JIT_DbgIsJustMyCode (000007fe`fa0da560)
000007ff`01c5d708 90              nop
000007ff`01c5d709 90              nop
000007ff`01c5d70a 488b4540        mov     rax,qword ptr [rbp+40h]
000007ff`01c5d70e 488b4028        mov     rax,qword ptr [rax+28h]
000007ff`01c5d712 48894508        mov     qword ptr [rbp+8],rax
000007ff`01c5d716 488b4508        mov     rax,qword ptr [rbp+8]
000007ff`01c5d71a 803800          cmp     byte ptr [rax],0
000007ff`01c5d71d 488b4d08        mov     rcx,qword ptr [rbp+8]
000007ff`01c5d721 e8224658fe      call    000007ff`001e1d48 (System.Threading.Thread.Abort(), mdToken: 0000004BCC77C220)
>>> 000007ff`01c5d726 90              nop
000007ff`01c5d727 90              nop
000007ff`01c5d728 eb00            jmp     000007ff`01c5d72a
000007ff`01c5d72a 488b4540        mov     rax,qword ptr [rbp+40h]
000007ff`01c5d72e 488b4030        mov     rax,qword ptr [rax+30h]

오~~~ 보는 바와 같이 부모 쪽 닷넷 메서드의 JIT 컴파일 결과에서는 rcx에 전달한 스레드 인스턴스를 스레드 스택(rbp + 8)에 보관하고 있습니다. 그럼 게임 끝났군요. ^^

windbg - x64 SOS 확장의 !clrstack 명령어가 출력하는 Child SP 값의 의미
; https://www.sysnet.pe.kr/2/0/11349

위의 글에 따라 clrstack 명령에서 구했던 부모 메서드의 Child SP 값에서 시작할 수 있습니다.

Child SP         IP               Call Site
0000000020dad730 000007ff0326a196 WebApp.Library.CallStack.CancelThread()

0000000020dad730 값은 프롤로그 코드를 지난, 즉 sub rsp, 50h가 반영된 값입니다. 그렇다면 "lea rbp, rsp + 20h"의 값을 금방 계산할 수 있습니다.

rbp = 0000000020dad730 + 20h = 0000000020dad750h

그리고 그 rbp 위치의 +8에 위치한 값을 !do 명령어로 덤프하면 그것이 바로 Thread.Abort가 종료하려는 스레드가 됩니다.

0:045> dq 0000000020dad750 + 8 L1
00000000`20dad758  00000001`1fab1220

0:045> !do 00000001`1fab1220
Name:        System.Threading.Thread
MethodTable: 000007ff001e1780
EEClass:     000007ff001c9cc8
Size:        88(0x58) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007ff00252860  400079b        8 ....Contexts.Context  0 instance 000000015fa91238 m_Context
000007ff003f0930  400079c       10 ....ExecutionContext  0 instance 000000011fab1518 m_ExecutionContext
000007ff001ad478  400079d       18        System.String  0 instance 000000011fab1458 m_Name
000007ff001e0530  400079e       20      System.Delegate  0 instance 0000000000000000 m_Delegate
000007ff001f5780  400079f       28 ...ation.CultureInfo  0 instance 0000000000000000 m_CurrentCulture
000007ff001f5780  40007a0       30 ...ation.CultureInfo  0 instance 0000000000000000 m_CurrentUICulture
000007ff001a57f8  40007a1       38        System.Object  0 instance 0000000000000000 m_ThreadStartArg
000007ff00259f70  40007a2       40        System.IntPtr  1 instance         1aefe390 DONT_USE_InternalThread
000007ff001f3518  40007a3       48         System.Int32  1 instance                2 m_Priority
000007ff001f3518  40007a4       4c         System.Int32  1 instance               27 m_ManagedThreadId
000007ff006273f8  40007a5      318 ...LocalDataStoreMgr  0   shared           static s_LocalDataStoreMgr
                                 >> Domain:Value  0000000002837030:NotInit  00000000186d9260:NotInit  <<
000007ff01dfab40  40007a6       10 ...alDataStoreHolder  0   shared         TLstatic s_LocalDataStore
    >> Thread:Value <<

게다가 운이 좋군요. m_Name에 값이 있으니 다음과 같이 스레드 객체에 할당했던 이름을 알 수 있습니다.

0:045> !DumpObj /d 000000011fab1458
Name:        System.String
MethodTable: 000007ff001ad478
EEClass:     000007ff001c8588
Size:        92(0x5c) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String:      TEST-MY-THREAD
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007ff001f3518  4000103        8         System.Int32  1 instance               33 m_stringLength
000007ff001ae438  4000104        c          System.Char  1 instance               41 m_firstChar
000007ff001ad478  4000105       10        System.String  0   shared           static Empty
                                 >> Domain:Value  0000000002837030:000000019fa60978 00000000186d9260:000000019fa60978 <<

저것만 알아도 소스 코드에서 어떤 스레드가 대상인지 금방 식별할 수 있습니다. 그다음 흥미 있는 정보는 m_ManagedThreadId == 27입니다. 16진수로 0x1b이고 !threads 명령을 통해 디버거 내의 스레드 ID를 알 수 있습니다.

0:045> !threads
ThreadCount:      101
UnstartedThread:  0
BackgroundThread: 73
PendingThread:    0
DeadThread:       28
Hosted Runtime:   no
                                           PreEmptive                                                   Lock
       ID  OSID        ThreadOBJ     State GC       GC Alloc Context                  Domain           Count APT Exception
  16    1  16d0 0000000002878150      8220 Enabled  0000000000000000:0000000000000000 0000000002837030     0 Ukn
  34    2   b4c 000000000289e970      b220 Enabled  0000000000000000:0000000000000000 0000000002837030     0 MTA (Finalizer)
  36    3  21c0 0000000017b67ca0   100a220 Enabled  0000000000000000:0000000000000000 0000000002837030     0 MTA (Threadpool Worker)
  37    4  27c8 0000000018753930      1220 Enabled  0000000000000000:0000000000000000 0000000002837030     0 Ukn
  38   11  1b40 000000001aef9cf0      b220 Enabled  0000000000000000:0000000000000000 00000000186d9260     0 MTA
  39   12  1be4 000000001aefa400   200b220 Enabled  00000001500568b0:0000000150057d28 00000000186d9260     0 MTA
  40   13  25d0 000000001aefab10   200b220 Enabled  00000001b21dc148:00000001b21dd1a8 00000000186d9260     0 MTA
  41   14  10e0 000000001aefb220      b220 Enabled  00000001405b48c8:00000001405b48f0 00000000186d9260     0 MTA
  42   15  1508 000000001aefb930   200b220 Enabled  0000000000000000:0000000000000000 00000000186d9260     0 MTA
  43   16   a40 000000001aefc040   1000220 Enabled  0000000000000000:0000000000000000 0000000002837030     0 Ukn (Threadpool Worker)
  44   17   e94 000000001aefc750   8009220 Enabled  0000000000000000:0000000000000000 0000000002837030     0 MTA (Threadpool Completion Port)
  45   19  18b4 000000001aefd570   200b220 Enabled  00000001605cfac8:00000001605d17b0 00000000186d9260     0 MTA
  46   1a   a94 000000001aefdc80   200b220 Enabled  0000000000000000:0000000000000000 00000000186d9260     0 MTA
  47   1b   9d0 000000001aefe390      b221 Enabled  0000000120c94e38:0000000120c94e50 00000000186d9260     1 MTA
  48   1c  2320 000000001aefeaa0   200b220 Enabled  0000000000000000:0000000000000000 00000000186d9260     0 MTA
...[생략]...

따라서 문맥을 변경해서 Abort 대상이 되었던 스레드가 어떤 작업을 수행하는 상태였는지 알 수 있습니다.

0:045> ~47s
ntdll!ZwWaitForSingleObject+0xa:
00000000`7725bd7a c3              ret

0:047> !clrstack
OS Thread Id: 0x9d0 (47)
Child SP         IP               Call Site
0000000020e2d5b8 000000007725bd7a [HelperMethodFrame: 0000000020e2d5b8] 
0000000020e2d6d0 000007ff0298739d System.Diagnostics.StackFrameHelper.GetMethodBase(Int32)
0000000020e2d720 000007ff02f78dbc System.Diagnostics.StackTrace.CaptureStackTrace(Int32, Boolean, System.Threading.Thread, System.Exception)
0000000020e2d780 000007ff02f78cb1 System.Diagnostics.StackTrace..ctor(System.Threading.Thread, Boolean)
0000000020e2d7d0 000007ff02f7898b WebApp.BaseLib.Dumper.GetCallStack(System.Threading.Thread)
0000000020e2d890 000007ff027c8036 WebApp.Library.CallStack.DumpStack()
0000000020e2da50 000007ff027bc2f5 WebApp.Library.CallStack.DoCallStack(System.Object)
0000000020e2dac0 000007ff025fa678 System.Threading.ExecutionContext.runTryCode(System.Object)
0000000020e2e1e8 000007fef885c9e4 [HelperMethodFrame_PROTECTOBJ: 0000000020e2e1e8] System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object)
0000000020e2e310 000007ff007de3f6 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
0000000020e2e370 000007ff025f8fab System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
0000000020e2e3c0 000007ff025f8b8d System.Threading.ThreadHelper.ThreadStart(System.Object)
0000000020e2e828 000007fef885c9e4 [GCFrame: 0000000020e2e828] 
0000000020e2ec10 000007fef885c9e4 [DebuggerU2MCatchHandlerFrame: 0000000020e2ec10] 
0000000020e2ede8 000007fef885c9e4 [ContextTransitionFrame: 0000000020e2ede8] 
0000000020e2efd0 000007fef885c9e4 [DebuggerU2MCatchHandlerFrame: 0000000020e2efd0] 

보니까, 특정 스레드의 호출 스택을 구하는 스레드입니다. 그렇다면 또 그 스레드는 어떤 것일지 추적해 보겠습니다. StackTrace 타입의 생성자에 첫 번째 인자(rcx)로 System.Threading.Thread 객체가 있습니다.

0:047> !U /d 000007ff02f78cb1
Normal JIT generated code
System.Diagnostics.StackTrace..ctor(System.Threading.Thread, Boolean)
Begin 000007ff02f78c70, size 4a
000007ff`02f78c70 53              push    rbx
000007ff`02f78c71 56              push    rsi
000007ff`02f78c72 57              push    rdi
000007ff`02f78c73 4883ec30        sub     rsp,30h
000007ff`02f78c77 410fb6f8        movzx   edi,r8b
000007ff`02f78c7b 488bf2          mov     rsi,rdx
000007ff`02f78c7e 488bd9          mov     rbx,rcx
000007ff`02f78c81 488bcb          mov     rcx,rbx
000007ff`02f78c84 e8e77728fd      call    000007ff`00200470 (System.Object..ctor(), mdToken: 000000644E0FBCC0)
000007ff`02f78c89 c7431000000000  mov     dword ptr [rbx+10h],0
000007ff`02f78c90 c7431400000000  mov     dword ptr [rbx+14h],0
000007ff`02f78c97 48c744242000000000 mov   qword ptr [rsp+20h],0
000007ff`02f78ca0 4c8bce          mov     r9,rsi
000007ff`02f78ca3 440fb6c7        movzx   r8d,dil
000007ff`02f78ca7 33d2            xor     edx,edx
000007ff`02f78ca9 488bcb          mov     rcx,rbx
000007ff`02f78cac e8f70e7bfd      call    000007ff`00729ba8 (System.Diagnostics.StackTrace.CaptureStackTrace(Int32, Boolean, System.Threading.Thread, System.Exception), mdToken: 000000644E0FBCC0)
>>> 000007ff`02f78cb1 90              nop
000007ff`02f78cb2 4883c430        add     rsp,30h
000007ff`02f78cb6 5f              pop     rdi
000007ff`02f78cb7 5e              pop     rsi
000007ff`02f78cb8 5b              pop     rbx
000007ff`02f78cb9 c3              ret

역시 이번에도 스레드 스택에는 rcx의 족적이 없습니다. 여기서도 다시 부모 함수로 가보겠습니다.

0:047> !U /d 000007ff02f7898b
Normal JIT generated code
WebApp.BaseLib.Dumper.GetCallStack(System.Threading.Thread)
Begin 000007ff02f787b0, size 349
000007ff`02f787b0 4889542410      mov     qword ptr [rsp+10h],rdx
000007ff`02f787b5 48894c2408      mov     qword ptr [rsp+8],rcx
000007ff`02f787ba 55              push    rbp
000007ff`02f787bb 4881ecb0000000  sub     rsp,0B0h
000007ff`02f787c2 488d6c2420      lea     rbp,[rsp+20h]
000007ff`02f787c7 48896500        mov     qword ptr [rbp],rsp
000007ff`02f787cb 33c0            xor     eax,eax
000007ff`02f787cd 48894528        mov     qword ptr [rbp+28h],rax
000007ff`02f787d1 48894510        mov     qword ptr [rbp+10h],rax
000007ff`02f787d5 33c0            xor     eax,eax
000007ff`02f787d7 884531          mov     byte ptr [rbp+31h],al
...[생략]...
000007ff`02f7896c 48894560        mov     qword ptr [rbp+60h],rax
000007ff`02f78970 488b4560        mov     rax,qword ptr [rbp+60h]
000007ff`02f78974 48894568        mov     qword ptr [rbp+68h],rax
000007ff`02f78978 41b001          mov     r8b,1
000007ff`02f7897b 488b95a8000000  mov     rdx,qword ptr [rbp+0A8h]
000007ff`02f78982 488b4d68        mov     rcx,qword ptr [rbp+68h]
000007ff`02f78986 e805127bfd      call    000007ff`00729b90 (System.Diagnostics.StackTrace..ctor(System.Threading.Thread, Boolean), mdToken: 000000644E0FBCC0)
>>> 000007ff`02f7898b 4c8b5d68        mov     r11,qword ptr [rbp+68h]

System.Diagnostics.StackTrace..ctor 생성자를 호출하는데, 이것의 첫 번째 인자(rcx)는 this 포인터 값이라는 것에 유의해야 합니다. 따라서 우리가 원하는 생성자의 (C# 코드 상의) 첫 번째 인자(System.Threading.Thread)는 실제로는 두 번째 인자(rdx)로 전달됩니다.

즉, [rbp+0A8h] 위치에 우리가 원하는 Thread 인스턴스의 값이 보관되어 있습니다. 따라서 이번에도 역시 "windbg - x64 SOS 확장의 !clrstack 명령어가 출력하는 Child SP 값의 의미" 글에서 설명했던 방법에 따라, 현재 메서드의 Child SP로부터 시작해,

Child SP         IP               Call Site
0000000020e2d7d0 000007ff02f7898b WebApp.BaseLib.Dumper.GetCallStack(System.Threading.Thread)

다음과 같이 인자 값을 덤프할 수 있습니다.

0:047> ? 0000000020e2d7d0 + 20h
Evaluate expression: 551737328 = 00000000`20e2d7f0

0:047> dq 00000000`20e2d7f0 + 0a8h L1
00000000`20e2d898  00000001`8fe88670

0:047> !do 00000001`8fe88670
Name:        System.Threading.Thread
MethodTable: 000007ff001e1780
EEClass:     000007ff001c9cc8
Size:        88(0x58) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007ff00252860  400079b        8 ....Contexts.Context  0 instance 0000000181994a40 m_Context
000007ff003f0930  400079c       10 ....ExecutionContext  0 instance 000000017ff9c8f0 m_ExecutionContext
000007ff001ad478  400079d       18        System.String  0 instance 0000000000000000 m_Name
000007ff001e0530  400079e       20      System.Delegate  0 instance 0000000000000000 m_Delegate
000007ff001f5780  400079f       28 ...ation.CultureInfo  0 instance 0000000000000000 m_CurrentCulture
000007ff001f5780  40007a0       30 ...ation.CultureInfo  0 instance 0000000000000000 m_CurrentUICulture
000007ff001a57f8  40007a1       38        System.Object  0 instance 0000000000000000 m_ThreadStartArg
000007ff00259f70  40007a2       40        System.IntPtr  1 instance         1ff7bcf0 DONT_USE_InternalThread
000007ff001f3518  40007a3       48         System.Int32  1 instance                2 m_Priority
000007ff001f3518  40007a4       4c         System.Int32  1 instance               35 m_ManagedThreadId
000007ff006273f8  40007a5      318 ...LocalDataStoreMgr  0   shared           static s_LocalDataStoreMgr
                                 >> Domain:Value  0000000002837030:NotInit  00000000186d9260:NotInit  <<
000007ff01dfab40  40007a6       10 ...alDataStoreHolder  0   shared         TLstatic s_LocalDataStore
    >> Thread:Value <<
ThinLock owner 1b (0000000000000000), Recursive 0

아쉽지만 이번에는 m_Name 값이 없고 m_ManagedThreadId(35 == 0x23)를 통해 디버거 내의 해당 스레드의 식별자를 찾을 수 있습니다.

0:047> !threads
ThreadCount:      101
UnstartedThread:  0
BackgroundThread: 73
PendingThread:    0
DeadThread:       28
Hosted Runtime:   no
                                           PreEmptive                                                   Lock
       ID  OSID        ThreadOBJ     State GC       GC Alloc Context                  Domain           Count APT Exception
  16    1  16d0 0000000002878150      8220 Enabled  0000000000000000:0000000000000000 0000000002837030     0 Ukn
..[생략]...
  66   23  162c 000000001ff7bcf0   1089224 Enabled  0000000181c4b510:0000000181c4b528 00000000186d9260     1 MTA (Threadpool Worker)
XXXX   3d       000000002012ccc0   1019820 Enabled  0000000000000000:0000000000000000 0000000002837030     0 MTA (Threadpool Worker)

따라서 이렇게 해당 스레드의 상태와 콜 스택을 얻을 수 있습니다.

0:047> ~66s
ntdll!ZwWaitForSingleObject+0xa:
00000000`7725bd7a c3              ret

0:066> !threadstate 1089224
    User Suspend Pending
    Legal to Join
    Background
    CLR Owns
    In Multi Threaded Apartment
    Sync Suspended
    Thread Pool Worker Thread

0:066> !clrstack
OS Thread Id: 0x162c (66)
Child SP         IP               Call Site
...[생략]...
System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr, System.Web.RequestNotificationStatus ByRef)
0000000022e2f530 000007ff0256bf57 DomainNeutralILStubClass.IL_STUB_PInvoke(IntPtr, System.Web.RequestNotificationStatus ByRef)
0000000022e2f600 000007ff024e8551 System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr, IntPtr, IntPtr, Int32)
0000000022e2f740 000007ff024e8142 System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32)
0000000022e2f790 000007ff024e7b21 DomainNeutralILStubClass.IL_STUB_ReversePInvoke(Int64, Int64, Int64, Int32)
0000000022e2f9f8 000007fef897c2db [ContextTransitionFrame: 0000000022e2f9f8] 




정리해 보면, 닷넷 응용 프로그램에서 인자 값 추적은 부모 쪽으로 가는 것이 더 좋다는 점입니다. 왜냐하면 사용자 코드를 포함한 managed 쪽은 실행 시 컴파일(JIT)되는 구조이기 때문에 성능적인 이슈로 인해 아무리 릴리스 빌드라고 해도 최적화를 그다지 심하게 할 수는 없기 때문입니다. 반면, 네이티브 함수로 내려가면 대개의 경우 최적화가 잘 된 상태로 머신 코드가 배열되기 때문에 분석도 어렵고 rbp 프레임 구조를 띄지 않는 경우가 많습니다.

마지막으로, 인자 추적을 위한 예제로 이 글을 사용하긴 했지만 어쨌든 중요한 점은 Thread.Abort가 hang에 걸릴 수 있다는 점을 염두에 두어야 합니다. (그 이유는 나중에 한번 더 다루겠습니다. ^^)




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





[최초 등록일: ]
[최종 수정일: 11/30/2017 ]

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

비밀번호

댓글 쓴 사람
 




... 31  32  33  34  35  36  37  38  39  40  41  42  43  [44]  45  ...
NoWriterDateCnt.TitleFile(s)
11132정성태3/25/201711683.NET Framework: 634. C# 개발자를 위한 Win32 DLL export 함수의 호출 규약 (1) - x86 환경에서의 __cdecl, __stdcall에 대한 Name mangling파일 다운로드1
11131정성태1/13/20178032.NET Framework: 633. C# - IL 코드 분석을 위한 팁 [2]
11130정성태1/11/20176674.NET Framework: 632. x86 실행 환경에서 SECURITY_ATTRIBUTES 구조체를 CreateEvent에 전달할 때 예외 발생파일 다운로드1
11129정성태1/11/20178349.NET Framework: 631. async/await에 대한 "There Is No Thread" 글의 부가 설명 [4]파일 다운로드1
11128정성태1/9/20177750.NET Framework: 630. C# - Interlocked.CompareExchange 사용 예제 [3]파일 다운로드1
11127정성태1/8/20176043기타: 63. (개발자를 위한) Visual Studio의 "with MSDN" 라이선스 설명
11126정성태1/7/20179789기타: 62. Edge 웹 브라우저의 즐겨찾기(Favorites)를 편집/백업/복원하는 방법 [1]파일 다운로드1
11125정성태1/7/20176731개발 환경 구성: 310. IIS - appcmd.exe를 이용해 특정 페이지에 클라이언트 측 인증서를 제출하도록 설정하는 방법
11124정성태1/4/20178196개발 환경 구성: 309. 3년짜리 유효 기간을 제공하는 StartSSL [2]
11123정성태1/4/20176573.NET Framework: 629. .NET Core의 dotnet.exe CLI 명령어 확장 방법 [1]
11122정성태1/3/20176921.NET Framework: 628. TransactionScope에 사용자 정의 트랜잭션을 참여시키는 방법 [2]파일 다운로드1
11121정성태1/1/20175834개발 환경 구성: 308. "ASP.NET Core Web Application (.NET Core)"와 "ASP.NET Core Web Application (.NET Framework)" 차이점
11120정성태12/12/20199259개발 환경 구성: 307. ASP.NET Core Web Application을 IIS에서 호스팅하는 방법
11119정성태12/23/201627156개발 환경 구성: 306. Visual Studio Code에서 Python 개발 환경 구성 [1]
11118정성태12/22/201610022오류 유형: 374. Python 64비트 설치 시 0x80070659 오류 발생 [1]
11117정성태12/21/20166217웹: 35. nopCommerce 예제 사이트 구성 방법
11116정성태12/21/20168280디버깅 기술: 84. NopCommerce의 Autofac 부하(CPU, Memory) [2]
11115정성태12/21/201610219Windows: 133. 윈도우 서버 2016에서 플래시가 동작하지 않는 경우 [2]
11114정성태12/19/201611315Windows: 132. 역 슬래시(backslash) 문자가 왜 통화 표기 문자(한글인 경우 "\")로 보일까요? [2]
11113정성태12/19/20165275오류 유형: 373. ICOMAdminCatalog::GetCollection에서 CO_E_ISOLEVELMISMATCH(0x8004E02F) 오류 발생파일 다운로드1
11112정성태11/23/201610896오류 유형: 372. MySQL 서비스가 올라오지 않는 경우 - Error 1067
11111정성태2/26/202015338.NET Framework: 627. C++로 만든 DLL을 C#에서 사용하기 [2]
11110정성태11/17/20165538.NET Framework: 626. Commit 메모리가 낮은 상황에서도 메모리 부족(Out-of-memory) 예외 발생
11109정성태11/17/20165287.NET Framework: 625. ASP.NET에서 System.Web.HttpApplication 인스턴스는 다중으로 생성됩니다.
11108정성태11/13/20165915.NET Framework: 624. WPF - Line 요소를 Canvas에 위치시켰을 때 흐림(blur) 현상파일 다운로드1
11107정성태11/10/20166131오류 유형: 371. Post cache substitution is not compatible with modules in the IIS integrated pipeline that modify the response buffers.파일 다운로드1
... 31  32  33  34  35  36  37  38  39  40  41  42  43  [44]  45  ...