[WinDbg] Thread Dump 분석해 보기

어제 회사 동료분께서 점심 먹고 여의도 공원 한바퀴 돌고 오니까 나른해서 졸고 있는데 Hang Dump 분석 도와 달라고 했습니다.

 

 여기서 질문 여러분들은 Hang(CPU 100%)이 발생했을 때 어떻게 분석하세요. 저는 Adplus를 이용해서 프로세스 실행중 덤프를 3번 정도 수집합니다. 그리고 이 덤프를 분석하는 방법을 사용합니다. (Hand 덤프 수집하는 adplus툴 사용법은 이미 제블로그에 있습니다. 관심있는분들은 search 해보세요). 혹시 자신만의 특별한 비법이 있으면 공유해요^^

 

 어제 동료분과 Hang 덤프를 분석하면서 Raw Thread Stack Dump에 대해서 간단하게 정리하면 좋겠다는 생각이 들어서 오늘 블로그에 정리합니다.^^

 

아래 스레드 덤프 분석 단계는 시간이 많이 걸리지만 최후의 방법으로 사용하면 좋습니다.

 

1) 모든 스레드 확인하기

0:000> ~
.  0  Id: 106c.4e4 Suspend: 1 Teb: 7ffde000 Unfrozen
   1  Id: 106c.4e0 Suspend: 1 Teb: 7ffdc000 Unfrozen
   2  Id: 106c.1158 Suspend: 1 Teb: 7ffdb000 Unfrozen
   3  Id: 106c.c3c Suspend: 1 Teb: 7ffd9000 Unfrozen
   4  Id: 106c.1174 Suspend: 1 Teb: 7ffd8000 Unfrozen
   5  Id: 106c.1168 Suspend: 1 Teb: 7ffd4000 Unfrozen
   6  Id: 106c.1568 Suspend: 1 Teb: 7ffaf000 Unfrozen
   7  Id: 106c.1574 Suspend: 1 Teb: 7ffad000 Unfrozen
   8  Id: 106c.964 Suspend: 1 Teb: 7ffac000 Unfrozen
   9  Id: 106c.1164 Suspend: 1 Teb: 7ffab000 Unfrozen
  10  Id: 106c.d84 Suspend: 1 Teb: 7ffaa000 Unfrozen
  11  Id: 106c.bf4 Suspend: 1 Teb: 7ffa9000 Unfrozen
  12  Id: 106c.eac Suspend: 1 Teb: 7ffa8000 Unfrozen

 

~

  33  Id: 106c.4f0 Suspend: 1 Teb: 7ff49000 Unfrozen
  34  Id: 106c.be8 Suspend: 1 Teb: 7ffae000 Unfrozen
  35  Id: 106c.14e0 Suspend: 1 Teb: 7ff5d000 Unfrozen
  36  Id: 106c.fe0 Suspend: 1 Teb: 7ff5b000 Unfrozen
  37  Id: 106c.1470 Suspend: 1 Teb: 7ff57000 Unfrozen
  38  Id: 106c.16c4 Suspend: 1 Teb: 7ff5e000 Unfrozen

 

2)의심스러운 스레든 teb(thread environment block) 확인하기

0:000> !teb 7ffad000
TEB at 7ffad000
    ExceptionList:        0181ff0c
    StackBase:            01820000
    StackLimit:           0181c000
    SubSystemTib:         00000000
    FiberData:            00001e00
    ArbitraryUserPointer: 00000000
    Self:                 7ffad000
    EnvironmentPointer:   00000000
    ClientId:             0000106c . 00001574
    RpcHandle:            00000000
    Tls Storage:          00000000
    PEB Address:          7ffdf000
    LastErrorValue:       0
    LastStatusValue:      c000000d
    Count Owned Locks:    0
    HardErrorMode:        0

 

3)dps를 이용해서 스레드 스택 영역(일정 범위) 메모리 내용 확인하기

0:000> dps 0181c000 01820000
0181c000  00000000
0181c004  00000000
0181c008  00000000
0181c00c  00000000
0181c010  00000000
0181c014  00000000
0181c018  00000000
0181c01c  00000000
0181c020  00000000
0181c024  00000000
...
...
...
0181ffb8  0181ffec
0181ffbc  77e6608b kernel32!BaseThreadStart+0x34
0181ffc0  00f31eb0
0181ffc4  00000000
0181ffc8  00000000
0181ffcc  00f31eb0
0181ffd0  8a38f7a8
0181ffd4  0181ffc4
0181ffd8  88a474b8
0181ffdc  ffffffff
0181ffe0  77e6b7d0 kernel32!_except_handler3
0181ffe4  77e66098 kernel32!`string'+0x98
0181ffe8  00000000
0181ffec  00000000
0181fff0  00000000
0181fff4  7923a709
0181fff8  00f31eb0
0181fffc  00000000
01820000  ????????

 

드디어 의심 가는 부분을 찾았습니다.( 빨간색 글씨로 적힌 부분 )

덤프를 보니 아마도 우리가 가장 실수를 많이 하는 스트링 버퍼 조작에 오류가 있는것 같습니다.

이제는 소스코드를 봐서 스트링 조작하는 부분을 확인하는 일이 남았네요. ^^

 

출처: 다년간의 프로그램밍 경험(삽질) & http://www.dumpanalysis.org(참고사이트)

[출처] [WinDbg] Thread Dump 분석해 보기|작성자 갱주니