Create TOC

2005년 12월 27일

WinDbg

Symbol setting

OS 심볼 설정

.symfix c:\symbol\winsym

기타 심볼

적당한 폴더에 pdb를 넣고 File-Symbol File Path 메뉴에서 추가로 등록해준다.

기본 명령

  • k : for stack
  • ~ : list all thread
  • ~ <tid> : changes to specific thread number
  • ~*kb : lists the stacks for all threads in a process
  • ~<tid>kb : list the stack for <tid> thread
  • g : go
  • ln <address> : address로부터 근접한 함수를 찾아줌. symbol 필요. stack dump를 떠서 손으로 call stack을 추척할때 필요하다.
  • dump /f <filename> : create memory dump
  • lm : list module. see .hh lm
  • lmvm 모듈명 : 모듈에 대한 정보를 얻는다.
  • .hh <command> : help
  • dt 구조체명 [주소] : 구조체의 실제 구성내용을 보여준다. [주소] 가 생략되면 prototype을, [주소] 가 주어지면 구조체의 멤버변수 값을 보여준다.

덤프 분석

커널 덤프 경우

기본 OS 설정에서는 BSOD 발생시 풀 덤프를 만들어주지 않는다. BSOD를 분석하기 위해서는 반드시 풀 덤프가 생기도록 Kernel Dump 설정 해줘야 한다.

  1. ''!analyze -v'' 명령을 통해서 나온 오류 코드를 도움말에서 찾아서 분석한다.
  2. !processs 이녀석이 관련된 process.

그 외에 Kernel Memory Space Analyzer도 도움이 된다.

User 덤프 경우

Dr.Watson32 나 UserDumpUserDump는 업데이트가 되지 않기 때문에 SysInternals의 procdump를 사용하는 것이 더 좋다를 사용해서 풀 덤프를 받아온다.

Interactive Debugging

example) 임의의 모듈에 break 걸기

  1. process attach
  2. break
  3. x user32!Message* : 현재 attach한 process가 user32 를 load 하고 있을때 user32의 Message 로 시작하는 함수 목록을 출력
  4. bp <주소> 또는 bp 모듈명!함수이름 : 위에서 원하는 함수에 대한 주소를 얻어서 break. break point 목록은 bl, 지울때는 bc
  5. bu <module>!<function> : module이 load되기 전에 breakpoint를 설정하고 싶을 때 사용한다.
  6. g

원격 디버깅

문제가 발생하는 PC와 개발자가 사용하는 PC에 각각 WinDbg를 설치하고 문제가 되는 PC에서 아래와 같이 WinDbg를 실행한다.

windbg.exe -server tcp:port=사용할포트

그 뒤에 개발자 PC에서 아래와 같이 입력하면 개발자 PC에서 원격으로 디버깅을 할 수 있다.

windbg.exe -remote tcp:server=WinDbg서버IP,port=포트

Call stack 해석

WinDbg의 call stack에서는 parameter를 3개까지밖에 표시해 주지 않는다. 추가적인 parameter는 clientEBP 값을 가지고 계산하면 된다.

  • 첫번째 인자는 EBP + 0x8
  • 두번째 인자는 EBP + 0xc

이런식으로 주소를 4씩 증가시키면서 보면 된다.

메모리 특정 영역 값이 변경될때 break 걸기

ba w4 address

유용한 링크

시간:
태그: ,