Search

'WinDbg'에 해당되는 글 2건

  1. 2010/01/20 [WinDbg] 1장 WinDbg에 대하여
  2. 2008/12/26 Handle 누수 잡아내기

[WinDbg] 1장 WinDbg에 대하여

IT 2010/01/20 19:59 Posted by Gony Taegony

1WinDbg에 대하여

 

1.1주요기능

 

  a. 응용프로그램 디버깅 (유저모드 디버깅)

à 디버깅에 필요한 윈도우 내부 리소스 정보를 상세하게 제공

à 리소스 조작하는 기능도 제공

 

b. 커널모드 드라이버 디버깅 (커널모드 디버깅)

à 윈도우 커널을 직접 디버깅하는 기능

  : 커널 내부 구조를 조회 및 조작 가능

à 커널모드 드라이버를 디버깅하는 기능

 

c. 크래시 덤프 파일 분석

 

d. 윈도우 시스템 분석

à 윈도우 자체에 대한 많은 정보를 제공

à 윈도우 운영체제에 대한 분석

à 보안 프로그램을 위해 취약점을 분석하거나 보완하는 목적으로 사용 가능

 

e. 스크립트와 확장 DLL

à 스크립트 언어를 작성해 번거롭거나 반복적인 작업을 손쉽게 처리

à 디버깅 API를 이용해 별도의 확장 DLL을 제작 가능

 

f. 디버깅 도움말

 

1.2 용도

 

a. 개발자 : 개발 과정에서 사용하는 개발 도구

à 소스 파일과 심볼 파일만 복사하면 비주얼 스튜디오와 같은 소스레벨 디버깅 가능

à 커널모드 드라이버 개발은 통합 개발 환경이 없으므로 WinDbg가 필수요소

 

b. 테스트/기술지원 엔지니어 : 버그 분석하기 위한 도구

à 원인 파악 및 소스레벨 디버깅까지 수행해 소스코드의 문제점을 찾기도 가능

 

c. 해커/크래커 : 해킹이나 크래킹을 위해 사용되는 역공학 (Reverse Engineering)도구

à Disassembly 코드와 WinDbg 명령을 이용하여 소프트웨어 분석 가능

 

1.3 디버깅의 종류

 

a. 유저모드 디버깅

    : 유저모드에서 실행된 프로세스를 대상으로 디버깅하는 것

à 유저모드에서 실행 중인 응용프로그램 중 하나의 응용프로그램을 타겟으로 디버깅

à 대상

: 일반 응용프로그램, 서비스 응용프로그램, 문제가 발생했을 때 생성되는

메모리 덤프 파일

 

- 일반 응용프로그램

    : 일반 응용프로그램을 실행시키면서 디버깅

    : 비주얼 스튜디오에서 F5로 실행하면서 디버깅하는 것과 같은 방법

- 서비스 응용프로그램

      : 실행 중인 서비스 응용프로그램을 붙여서 Attach 디버깅을 수행

      : 일반 응용프로그램도 가능

    - 메모리 덤프 파일

      : 응용프로그램에 문제가 발생할 때 상태가 저장된 파일

 

b. 커널모드 디버깅

: 운영체제와 드라이버를 디버깅하는 것

à 유저모드와는 달리 운영체제와 드라이버들은 2GB라는 가상 메모리 공간에

   공존하고 있어 항상 서로의 메모리를 침범할 위험성을 내포

à 어떤 드라이버가 잘못해 운영체제 커널의 메모리를 깨뜨릴 경우 바로 블루스크린이 발생

à 대표적인 커널모드 디버깅 : DDK (Driver Development Kit)로 작성한 드라이버 디버깅

à 디버거가 드라이버에 연결돼 디버깅하는 것이 아니라 운영체제 자체에 연결돼

     커널모드 전체를 디버깅

 

1.4 라이브 디버깅과 덤프 디버깅

 

a. 라이브 디버깅

: 프로그램 동작 중 디버깅

à 유저모드 라이브 디버깅과 커널모드 라이브 디버깅으로 구분

 

b. 유저모드 라이브 디버깅

: 현재 PC에서 실행 중인 프로세스를 디버깅

à 작업 중인 PC에서 WinDbg를 실행해 현재 PC에서 실행 중인 프로세스를 디버깅

à 리모트 디버깅 기능

  : 디버깅할 PC에서는 WinDbg만 실행하고

   네트워크상의 PC에서 디버깅할 PC의 실행 중인 프로세스를 TCP/IP, PIPE로 연결해 디버깅

 

c. 커널모드 라이브 디버깅

:  실행 중인 운영체제와 커널모드 드라이버를 디버깅

à 리모트 디버깅만 가능

à 널모뎀 케이블 (시리얼 케이블), IEEE1394, USB2.0을 지원

à 느린 속도로 인해 한 대의 PC에서 디버깅을 하기 위해

     Virtual Machine, Local Kernel Debugging 기능을 사용

     Local Kernel Debugging은 제한적인 기능만 제공

 

1.5덤프 디버깅

: 덤프의 종류는 유저 덤프와 커널 덤프로 구분

 

a. 유저 덤프

: 유저모드에서 생성된 메모리 덤프 파일

: 미니 덤프와 전체 덤프가 존재

à 미니 덤프

  : 64KB 크기

  : 레지스터, 콜 스택, 프로세스 정보, 스레드 정보, 오류가 발생한 시점에 접근했던

메모리 일부만을 저장

: drwtsn32 실행 후 크래시 덤프 유형최소로 선택

  à 전체 덤프

    : 오류가 발생한 시점에 그 프로세스가 사용하고 있던 메모리를 모두 파일로 저장

    : drwtsn32 실행 후 크래시 덤프 유형전체로 선택

 

b. 커널 덤프

: 작은 메모리 덤프 (미니 덤프), 커널 메모리 덤프, 전체 메모리 덤프 가 존재

à 미니 덤프

  : 64KB 크기

: 레지스터, 콜 스택, 프로세스 정보, 스레드 정보, 오류가 발생한 시점에 접근했던

메모리 일부만을 저장

à 커널 메모리 덤프

  : 커널 메모리에 해당하는 영역만 저장

  : 보통 전체 메모리의 1/3 정도 크기로 생성 (1GB인 경우 300MB 정도가 생성)

à 전체 메모리 덤프

  : 오류가 발생한 시점에 메모리에 있던 내용을 모두 덤프 파일로 저장

   유저모드 메모리, 커널모드 메모리가 모두 고스란히 저장

 

1.6 WinDbg 디버깅 용어

à 디버거 (Debugger) : 디버깅을 하는 도구

à 디버기 (Debuggee) : 디버깅을 당하는 대상

à 블루스크린 (BSOD) : Blue Screen Of Death

à 버그체크 (BugCheck) 와 버그체크 번호

 : 커널에서 현재 동작 조건이 비정상이라고 판단했을 때 KeBugCheck () 함수를 호출하며

이 때 KeBugCheck로 넘어가는 파라미터 (에러 종류)가 버그체크 번호 (0x1 ~ 0xFF)

     : ) 0x50에러가 발생시 도움말에서 Bug Check 0x50으로 입력하여 에러 종류를 검색

 

1.7 디버그 심볼 파일

: 실행 파일을 빌드할 때 생성되는 디버그용 정보 파일

à 실행 파일 안에 존재하는 함수나 변수들의 이름과 위치, 소스 파일, 소스 라인 정보가 존재

à 비주얼 스튜디오에서 Release 모드로 디버깅을 할 수 없는 이유는 PDB 파일이 없기 때문

à 윈도우 버전마다 각기 다른 심볼파일이 필요

  : 각 심볼 패키지를 다운받아 설치

  : 웹 심볼을 이용

    - WinDbg에서 디버깅 중인 윈도우의 정보와 파일 정보를 심볼서버로 보내고

심볼 서버는 해당 윈도우 버전에 맞는 심볼 파일만을 WinDbg로 다운로드해줘서

정확한 심볼 파일을 사용할 수 있게 한다

- 파일이 필요해지는 첫 번째 시점에 다운로드

 

1.8 WinDbg 명령

: 일반 명령 (Debugger Commands),

메타 명령 (Meta Commands), 확장 명령 (Extension Commands)

 

a. 일반 명령 (Debugger Commands)

: 대부분의 디버거가 공통적으로 지원하는 디버깅 명령

   Ex) r – CPU 레지스터 상태, d – 메모리 내용, e – 메모리 내용 변경,

bp – 브레이크 포인트

à 일반 명령은 명령 앞에 ‘.’ ‘!’가 붙지 않고 그냥 단어 자체를 사용한다.

 

b. 메타 명령 (Meta Commands)

: 디버거 자체를 제어하는 명령

à 명령어는 ‘.’ 으로 시작

  Ex) .attach – 특정 프로세스에 붙여서 디버깅할 때 사용

  .cls – 창의 내용을 지울 때 사용

  .sympath – 심볼 경로 확인

  .relaod – 심볼 경로를 설정한 후에 WinDbg가 심볼을 다시 로드하게 할 때 사용

 

c. 확장 명령 (Extension Commands)

: 윈도우 운영체제에 종속적인 정보를 다루는 명령

 특정 정보를 자세히 보여주거나 해석해서 보여줘 디버깅을 편하게 도와주는 기능

à 명령어는 ‘!’로 시작

à 확장 명령은 별도의 DLL 파일로 존재

  도움말에서 원하는 명령을 찾으면 DLL 이라는 항목으로 어떤 DLL을 사용하고 있는지 확인

  Ex) !process – 현재 윈도우에서 실행 중인 모든 프로세스의 정보

 

1.9 명령줄 구분

 

à 유저모드

  0:000> _ : 처음 0은 프로세스 번호이고 000은 스레드 번호

à 커널모드

  Kd> _ : 단지 kd라고 표시돼 커널모드 디버깅이라는 사실만 표시

  0: kd> _ : 멀티 processor 인 경우 processor 번호가 표시

 

1.10 명령별 사용 조건 (도움말)

 

à 명령 도움말에서 Environment 항목에서 확인

  Ex) Modes : User mode, kernel mode

 Targets : Live, crash dump

 Platforms : All

à 확장명령 사용시 DLL 항목 확인

  Ex) Windows NT 4.0         Unavailable

      Windows 2000           Acpikd.dll

      Windows XP and later   Kdexts.dll

 

[출처 : WinDbg로 쉽게 배우는 Windows Debugging]

TAG WinDbg

Handle 누수 잡아내기

IT/일반 2008/12/26 17:53 Posted by Gony Taegony
최근 제품 기능 패치 후 부하테스트를 진행했다. 결과는 아래와 같이 나왔다.
사용자 삽입 이미지






















위 그림에서 하얗게 나온 그래프가 핸들의 개수이다.
약 15시간 테스트를 진행했는데 핸들이 비정상적으로 증가했다.
메모리 누수되는 부분이 있는지만 확인하려다가 그냥 핸들수도 체크항목에 넣어본건데 당황스러운 결과가 나왔다. -_-; 다행히 메모리 누수는 없는 것으로 판단이 됐지만 핸들 누수는 조금 의외였다. 혹시 방법이 있을까 싶어서 이리저리 검색해보다가 WinDbg로 확인하는 방법을 알아냈다. 이거 아니었으면 큰일 날 뻔했다. 그것도 연말에 말이쥥~ ^^;
아래와 같은 순서로 진행했다.

1. WinDbg를 실행한다.
  : 아래와 같이 실행할 파일을 선택한다.
사용자 삽입 이미지

 


























2. 아래와 같이 선택한 프로그램이 실행되며 pause 상태로 초기화된다.
  : !htrace -enable 명령을 입력하여 htrace를 활성화한다.
  : 이 명령은 이후 핸들의 open/close 상태를 기록하도록 한다.
 : 명령이 성공하면 아래와 같이 성공 메시지가 출력된다.
사용자 삽입 이미지



















3. 현재 pause 상태이므로
   g 명령을 입력하거나 메뉴에서 Degug > Go (F5)를 선택하여 프로그램을 진행시킨다.
사용자 삽입 이미지



















4. 일정 시간동안 프로그램을 수행한 후
   메뉴의 Debug > Break 를 선택하여 pause 상태로 만든다.
   그리고나서 명령창에 !htrace 를 입력한다.
사용자 삽입 이미지



















5. !htrace 를 입력하면 아래와 같이 핸들값들에 대한 open/close 로그가 출력된다
 : Open/close 한 모듈과 함수명도 출력이 된다.
 : 프로그램에 따라 상당히 많은 양이 출력된다.
사용자 삽입 이미지

 

















6. !htrace 명령을 수행하면 로그가 나오긴 하는데 상당히 많은 로그가 출력된다.
   글쎄 이걸 일일이 찾기는 좀 힘들어 보인다. 이 때는 !htrace -diff 명령을 수행한다.
  : 이 명령은 open 후 close 되지 않은 핸들을 출력한다.
사용자 삽입 이미지

 

















7. !htrace -diff 명령의 결과 아래와 같이 출력된다.
  : CProcess::KillProcess 함수에서 open한 핸들이 close되지 않았음을 알 수 있다.
 : Open 되었으나 close 되지 않은 핸들과 어느 모듈에서 호출했는지까지 보여준다.
   주의할 점은 !htrace -enable 명령을 내린 시점부터 현시점까지
   close되지 않았기 때문에 누수일 확률이 높다는 것이지 무조건 누수는 아니라는 것이다.  
   (당연한 얘기지만 ...^^;)
사용자 삽입 이미지

 

















8. 진행조건
  : WinDbg의 기본 환경은 미리 세팅한 상태이다. (File > Symbol File Path 항목)
  : 테스트를 진행한 프로그램의 PDB 파일은 실행 파일과 같은 폴더에 위치해 있다.
  : 만일 !htrace -diff 명령을 내려도 로그가 너무 많다면 일단 3번 항목을 수행하여
    프로그램을 진행시킨다. 그 후 적절한 시점 (프로그램에 따라 개발자가 판단해야함)에
    4번 항목을 수행하여 프로그램을 pause 시키고 2번 항목 (!htrace -enable)부터 수행한다.

WinDbg는 프로그램 비정상 종료시 Dr.Watson 로그를 분석할 때만 이용했는데 이런 기능도 있는지 미쳐몰랐다. 아무튼 이 놈때문에 쉽게 잡을 수 있어서 다행이다. 이젠 놀아야쥐 ~ ^^;