S/W 개발자들이 사는 이야기 - 식스맨++

최근 들어서 계속 컴퓨터가 멈춰 버리는 현상이 생겼다.
조만간 밀어야지 밀어야지 하면서 같이 일하는 동료에게 증상을 이야기 하니깐.
컴퓨터가 멈춘것이 아니라 Explorer 쉘쪽이 문제가 있어서 화면이 갱신이 안되는것일 가망성이 높다고 했다.

그 이야기를 듣고, 네트웍으로 폴더를 접근하니 접근이 되었다.

이런.. 무엇때문이지. 흠..흠..
궁금증이 생겨도 화면을 움직일수가 없어서, 결국 커널 디버깅을 하기로 결정했다.

오래 전에 했던거라 기억이 가물가물해서. 우선 아래와 같이 kernel debug 셋팅.

▶WinDBG로 Kernel Debug.

준비물 : NULL Modem Cable Target PC setting :  boot.ini 삽입  multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional Debug" /debug /debugport=com1 /baudrate=115200 /Execute /fastdetect   Host PC Setting:  symbol setting  - SRV*d:\websymbols*http://msdl.microsoft.com/download/symbols   참고 windbg help 파일(Debuggers->Installation and Setup->Kenel-Mode Setup

셋팅한 상태에서 화면이 멈출때까지 컴퓨터 사용.

▶화면이 멈추었을 때

1. 커널 디버그를 할수 있는 준비를 한다.(windbg로 커널 dbg 참조)   2. 화면이 멈추는 현상 발생.  - host pc에서 kennel debug 연결한다.  - 어디에 locks이 걸렸는지 확인한다. >!locks . . Resource @ 0x89736720    Exclusively owned     Contention Count = 34268     NumberOfSharedWaiters = 4     NumberOfExclusiveWaiters = 33      Threads: 88c823f8-01<*> 897c0868-01    89ae8a28-01    896a9a50-01                  896a7258-01   . .     Contention Count = 757     NumberOfExclusiveWaiters = 2      Threads: 89b06bc8-01<*>      Threads Waiting On Exclusive Access:               896feda8       88c823f8       KD: Scanning for held locks........... !locks -v 897eeb88 Resource @ 0x897eeb88    Exclusively owned 88f913e8     Contention Count = 117     NumberOfExclusiveWaiters = 1      Threads: 89b06bc8-02<*>      Threads Waiting On Exclusive Access:               897f04b8       . .    - Contention Count가 많은것이 lock이 많이 걸린곳이므로 자세히 본다. >!locks -v 89736720 . . ownprocess 88c8dc18        image : explorer . .    - lock이 많이 발생한 process의 stack을 조사한다. >.process 88c8dc18 >.context >.thread 88c823f8 >.reload >kv 100     ps. 아래와 같이 같은 thread의 01,02가 의미하는 바를 이해하기가 어렵다.      Threads: 89b06bc8-01<*>      Threads: 89b06bc8-02<*> 영어로는 아래와 같이 이야기하는데 이해가 잘가지 않는다. Note that the address for each thread displayed is followed by its thread count (for example, "-01"). If a thread is followed by "<*>", that thread is one of the owners of the lock. In some instances, the initial thread address contains an offset. In that case, the actual thread address is displayed as well.   reference windbg help 파일(Debuggers->Debugger Operation(kernel Mode)->Chnageing Context) windbg help 파일(Debuggers->Crash Dump Files->Analyzeing a Kenel-Mode)

이렇게 해서 GreLockDisplay()에서 lock이 걸려서 화면 갱신이 되지 않는 다는것을 알았지만, 왜 이런 현상이 생기는지 찾지를 못했다. 흠.. 억울..

현재 Lock 되어 있는 프로그램만 종료하면 되겠다는 생각이 들어서 remotedebug를 찾아 보았다.

▶Remote Debug

remote debugging을 하기 위해서는 미리 debugging server를 켜 놓은 상태여야 한다.   - 디버그를 이용한 remote Debug  target application이 있을 때 사용.  pid는 target application의 pid이다.  ip는 debugging server의 ip이다.(\\ip를 했을때 접속가능해야한다.)   debugging server C:\Debugging Tools for windows> cdb -server tcp:port=1025 -p pid   debugging client C:\Debugging Tools for windows> windbg -remote tcp:server=ip,port 1025   - Process Server(User Mode)를 이용한 Remote Debug  target application을 모를때 사용.  pid는 target application의 pid이다.  ip는 debugging server의 ip이다.(\\ip를 했을때 접속가능해야한다.)   debugging server C:\Debugging Tools for windows>dbgsrv -t tcp:port=1025   debugging client C:\Debugging Tools for windows> windbg -premote tcp:server=ip,port 1025 -p pid   ps. debugging server는 디버그할 대상이 있는 서버이고, debugging client는 디버그를 하고 싶은 pc이다.   reference windbg help 파일(Debuggers->Debugger Operration->Remote Debugging)

언제 컴퓨터가 멈출지를 알수 없기 때문에, 디버그를 이용한 remote debug는 하지 못하고, process server를 이용한 remote debug를 사용하기로 결정하고, dbgsrv를 실행시켜 놓은 상태이다. 같은 현상이 발생하면 lock 걸린 process의 pid를 찾아서 windbg로 연결하여 강제 종료해 볼 생각이다.