[Noenemy]'s microgroove

오늘은 WinDbg를 이용해서 remote debugging을 하는 방법을 알아보려 합니다.

원격지의 WinDbg 프로그램을 서로 Server, Client 처럼 TCP/IP나 named pipe를 이용해서 통신하게 함으로써 debugging을 하는 방법입니다. 이 방법은 실제 debugging을 진행할 사람과 재현 장비가 멀리 떨어져 있는 경우 네트웤을 통해 디버깅을 할 수 있게 해주므로 매우 유용하게 사용할 수 있습니다. 다만 이렇게 WinDbg 끼리 서로 통신하려면 상호간에 연결이 되어야 하므로 약간을 설정이 필요합니다.

여기서는 TCP/IP를 이용한 remote debugging 방법을 알아보도록 하지요.

다음과 같은 상황을 가정해 보았습니다.

우선 일반적으로 kernel debugging을 하기 위한 환경 설정을 먼저 진행합니다. Target machine과 Host machine을 1394를 이용해서 연결하는 과정입니다.
(세부 내용은 http://msdn.microsoft.com/en-us/library/cc266332.aspx 참고)

1.     일반적으로 kernel debugging을 위해서 target machine과 host machine을 1394 cable을 이용해서 연결한 뒤

2.     Target machine을 debug mode로 부팅하고 (boot.ini 수정이나 vista에서는 bcdedit.exe 설정 필요)

3.     Host machine에서는 WinDbg를 실행시킨 후 kernel debug를 시작한다.

4.     Target machine과 Host machine의 windbg가 연결되면 kernel debugging이 가능하다.

자..여기까지 진행되었다면 Host machine과 원격지에 있는 Remote machine을 연결하는 방법을 알아보도록 하겠습니다.
현재 상황에서는 Host machine의 WinDbg가 server의 역할을, 그리고 Remote machine의 WinDbg가 client의 역할을 하게 됩니다.

즉, Hostmachine의 WinDbg와 Remote machine의 WinDbg가 서로 연결되어 통신할 수 있다면, Remote machine에서 Host machine을 거쳐서 Target machine을 kernel debugging을 하는 것이 가능해집니다.

Host machine과 Remote machine은 TCP/IP나 named pipe로 연결이 가능한데, 여기서는 TCP/IP를 이용한 네트워크 연결법을 알아보도록 하겠습니다. 

5.     Host machine에서 windbg를 break한 상태에서 kernel debug mode에서 다음과 같이 입력합니다.

A.     Kd> .server tcp:Port=<port number>

B.      Host machine의 windbg에서 server가 start 되었다는 메시지가 보여집니다. 즉, Host machine에서 지정한 port number로 remote machine이 연결하기를 기다리는 상태가 됩니다.

이제 원격지에서 실제로 debugging할 엔지니어에게 host machine에 접근할 수 있는 장비명(or IP 주소)과 Port 번호를 알려줍니다. 만약 중간에 방화벽 같은 게 있다면 접근이 허용될 수 있도록 설정을 해줘야 합니다.

이제 Remote machine에서 Host machine으로 접근해 보겠습니다.

6.     Remote machine의 WinDbg의 file 메뉴에서 ‘connect to remote session’을 선택하고 접근할 Host machine의 server name(or IP 주소)과 지정한 port 번호를 입력합니다.

7.     연결에 성공하였다면 Remote machine의 WinDbg에서 다음과 같은 메시지를 볼 수 있습니다.

Microsoft (R) Windows Debugger Version 6.11.0001.402 X86

Copyright (c) Microsoft Corporation. All rights reserved.

Server started.  Client can connect with any of these command lines

0: <debugger> -remote tcp:Port=10123,Server=SOONKKIM2

SOONKKIM1\soonkkim (tcp 157.60.9.124:43460) connected at Fri Mar 20 15:52:52 2009

8.     Remote machine의 WinDbg를 이용해서 debugging을 진행하면 됩니다.

오늘은 흔히 WER이라고 불리우는 Windows Error Reporting에 대해서 알아보도록 하겠습니다.

Windows XP 이후로 시스템이 비정상 종료된 이후에 다시 부팅을 하면 '오류로 부터 복구 되었는데 이를 보고하겠느냐'라는 메시지 박스가 뜨는 것을 볼 수 있습니다. 이 기능을 이용해서 사용자들로부터 수집된 오류 데이터를 이용해서 어떠한 문제로 사용자들이 불편을 겪고 있는지, 그 문제가 어떤 모듈에서 발생을 한 것인지 확인하고 발생 빈도가 높은 문제는 긴급한 이슈로 인식하고 문제를 수정하고 hotfix가 제작될 수 있도록 할 수 있습니다. 이러한 과정을 통해서 실제 사용자에게 발생하는 오류들을 수집하고 모니터링함으로써 보다 안정적인 환경에서 컴퓨터를 사용할 수 있도록 하고자 하는 것이 WER 서비스의 목적이라고 할 수 있습니다.

              [그림] WER 데이터의 수집 및 해결 과정

이 서비스를 잘 이용하면 마이크로소프트 뿐만 아니라 커널 모드에서 문제를 발생시킬 수 있는 소프트웨어를 개발하는 업체(ISV : Indenpendt Software Vendor)나 하드웨어 개발 업체(IHV - Indenpendent Hardware Vendor), 제조업체(OEM : Original hardware Manufacturer)에게 자사의 제품을 보다 안정성을 높이는데 매우 유용하게 사용될 수 있습니다. 왜냐하면 이들 업체에서는 대부분 제품을 실제 시장에 내보내기 전에 내부적으로 여러 가지 상황을 대비해서 테스트를 진행하고 품질을 검증한 뒤에 출시를 하게 되는데, 실제 사용자들이 사용하는 모든 다양한 환경에서 테스트를 진행하지 못하기 때문에 예상못한 상황에 대해서 사용자들이 겪고 있는 문제점들을 수집할 수 있는 매우 좋은 기회가 됩니다.

WER을 이용해서 전세계의 사용자에 의해서 매우 방대한 분량의 오류가 보고되고 있는데, 마이크로소프트에서는 이를 bucket 이란 가상의 단위로 관리합니다. 즉 수집된 오류 중에서 특정 버전의 드라이버나 애플리케이션이나 윈도우 기능이나 구성요소와 관련된 오류를 분류하여 동일하다고 판단되는 내용을 하나의 bucket으로 관리합니다. 따라서 bucket에 대한 시간에 따른 발생 빈도수나 발생 추이를 보면 해당 문제가 현재 얼마나 빈번하게 발생하는지, 또 그 오류가 확산되고 있는지 줄어들고 있는지에 대한 추적이 가능하게 됩니다.

WER에서 어떠한 정보들이 수집되는지?

다음과 같은 정보들이 수집됩니다.

• 어떠한 소프트웨어나 하드웨어에서 문제가 발생했는지
• 문제의 심각성 정도
• 문제에 대하여 정의하는데 도움되는 파일들 - 시스템 파일이나 문제가 발생한 전이나 후의 소프트웨어 동작에 대한 리포트 파일들..
• 기본적인 소프트웨어, 하드웨어 정보들 - 운영체제 버전, 언어, 장치 모델, 제조업체, 메모리나 디스크 크기 등

사용자의 장비에서 정보를 수집한다는 것은 개인 정보 보호 차원에서 매우 민감한 부분일 수 있습니다. WER의 개인 정보 보호 정책에 대한 내용은 아래 문서에서 확인할 수 있습니다.

Privacy Statement for the Microsoft Error Reporting Service
http://oca.microsoft.com/en/dcp20.asp

WER에서 수집된 오류 리포트를 보려면?

우선 다음과 같은 방법으로 마이크로소프트 Winqual(Windows Quality Online Services) 사이트에 등록하셔야 합니다.

1. Winqual 계정 만들기 : 다른 회사로 사칭하는 것을 막기 위해 VeriSign 인증서를 필요로 합니다.
2. WER 약관 동의하기
3. Winqual site에 로그인하기
4. Windows Error Reports 클릭

WER 사이트에 제품이나 파일 등록하기

앞서 설명드린 것처럼 수많은 오류 데이터가 수집되는데 특정 모듈이 어느 회사에서 작성한 제품이나 파일인지에 대한 정보를 알 수 있다면 보다 더 효율적으로 데이터를 이용할 수 있게 됩니다.  이를 위해서 여러분 회사에서 작성한 제품이나 파일에 대한 정보를 등록하면,  긴급하게 늘어나는 오류 상황이 발생했을 때 마이크로소프트와 여러분의 회사가 보다 신속하게 해당 문제를 해결하는데 도움이 됩니다.

1. Winqual 사이트의 Request file mapping이나 Request file unmapping 항목을 작성합니다.
2. 이 작업을 마친 후, 여러분의 회사와 관련된 파일들에 대한 정보를 확인할 수 있습니다.

추가적으로 다음 문서 내용을 참고하시면, WER 정보를 이용해서 개발자들이 실제 bucket 데이터를 어떻게 활용하고 대처할 수 있는지에 대한 정보를 얻을 수 있습니다.

Developers Guide to WER
https://winqual.microsoft.com/help/developers_guide_to_wer.htm

Kernel mode에서 처리할 수 없는 exception이 발생하는 경우 흔히 우리가 블루스크린이라고 말하는 BSOD(Blue Screen Of Death) 화면을 볼 수 있습니다. 이때 시스템에서 설정한 옵션에 따라 오류 발생 시점의 메모리 정보를 dump file에 저장함으로써 나중에 왜 블루스크린이 발생했는지에 대한 원인을 분석하는데 사용할 수 있습니다. 이러한 덤프 분석을 문제가 발생한 이후에 이를 조사한다는 의미에서 Post morterm analysis라는 용어를 쓰기도 합니다.

블루스크린이 발생하면 파란 배경화면에 발생한 오류에 대한 코드와 몇 가지 추가 정보가 파라미터로 보여지고 덤프 파일을 저장하는 과정이 보여집니다. 즉, 메모리 상태를 덤프해서 memory.dmp 파일(일반적으로 c:\Windows에 위치)에 저장을 하는 과정입니다. 일반 사용자에게는 컴퓨터를 사용 중에 갑자기 이 화면을 만나게 되면 작업이 중단되고 시스템이 재시작되어야 하므로 매우 곤욕스럽습니다. 하지만 원인을 분석하고 이를 해결함으로써 컴퓨터 사용환경이 보다 더 안정적으로 될 수 있는 기회가 되므로 엔지니어나 개발자에게는 이때 저장되는 덤프 파일 정보가 문제해결에 매우 중요한 단서가 됩니다.

명시적으로 오류가 발생해서 BSOD가 발생하고 덤프 파일이 수집이 가능한 경우가 대부분이지만, 특정 시점에 덤프 파일을 강제로 생성할 필요가 있는 경우도 있습니다. 예를 들어, 특정 시점에 컴퓨터의 반응이 불안정하거나 너무 느려진 경우(주로 hanging이라고 부름) 그 원인을 찾기 위해 덤프를 수집하고 이를 분석할 필요가 있는데, 이는 커널에서 특정 예외가 발생한 경우가 아니기 때문에 덤프가 생성이 되지를 않습니다. 그래서 강제로 특정 시점의 덤프를 수집할 필요가 있는데 다음과 같은 방법으로 수집이 가능합니다.

*키보드의 특수 키 조합으로 강제로 BSOD를 발생시키는 방법으로 사용중인 키보드에 따라서 이 방법을 사용하지 못할 수도 있습니다. 예를 들어 노트북의 경우 제조 모델에 따라 키패드의 조합이 다르고, 특히 오른쪽 Ctrl 키를 이용하므로 왼쪽 Ctrl 키만 있는 일부 키보드를 이용해서는 수집할 수 없습니다.

* How to get full dump file manually

1. 제어판 - 시스템 - 고급 - 시작 및 복구
2. 현재 서버의 물리적인 Memory 가 2GB 이하라면 “전체 메모리 덤프(Full Memory dump)” 로 설정합니다. 만약 2GB 이상이라면 “커널 메모리 덤프(Kernel Memory dump)” 로 설정하십시오.
3. 기존 파일에 덮어쓰기 : 옵션 선택 확인 (선택되어 있어야 합니다.)
4. %SystemRoot% 파티션에 Paging 파일이 존재해야 합니다.
5. Paging 파일(pagefile.sys)의 크기가 물리적인 메모리보다 최소한 같거나 커야 합니다.
6. 기본적으로 Memory Dump 는 C:\Windows 에 저장됩니다. C Drive 에 공간이 충분히 있는지 확인하십시오.
7. 레지스트리 편집기를 실행하여 아래 레지스트리 키를 추가한 후, 이를 적용하기 위하여 시스템을 재부팅 합니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
값 이름: CrashOnCtrlScroll
데이터 형식: REG_DWORD
값: 1

8. 오른쪽 Ctrl 키를 누른 상태에서 Scroll Lock 키를 두 번 누르면, BSOD가 발생하고 덤프가 수집됩니다.

*덤프 수집이 안된다면, 레지스트리 변경후 재부팅을 했는지 또는 오른쪽 Ctrl 키를 눌렀는지, Scroll Lock 키를 두 번 눌렀는지, 특수한 키보드를 사용중인지를 확인해보시기 바랍니다.

Kernel 영역에서 exception이 발생하여 이에 대해서 handling되지 못하는 경우에는 흔히 우리가 블루스크린이라고 부르는 BSOD(Blue Screen Of Death) 화면이 보여지고 시스템 실행이 중단됩니다. 이는 운영체제 자체의 문제점에 의해 발생하는 경우도 있지만 대부분은 커널 영역에서 실행되는 3rd party driver에 의해서 발생하는 경우가 많습니다. 저희가 사용하는 시스템에는 운영체제가 설치된 이후로 수많은 응용 프로그램들이 추가로 설치되고 함께 실행되고 있고, 또한 운영체제 자체가 수많은 벤더에서 제작한 하드웨어의 조합으로 구성되어 있고 이에 따라 많은 3rd party device driver와 연동되어 실행됩니다. 이러한 이유에서 블루스크린이 발생했을 때에는 그 원인이 어디에 있는지 찾고 적절한 해결방법을 찾는 것이 중요합니다.

커널모드에서 실행되는 특정 드라이버가 시스템 불안정의 원인이라고 의심될 경우 이를 확인하기 위한 도구로서 Driver Verifier라는 유틸리티가 제공됩니다. 이는 Windows 2000 이후 버전부터 운영체제에 포함되어 함께 배포되고 있습니다. 간단히 명령창에서 verifier.exe를 실행시키면 다음과 같은 UI를 제공하는 프로그램이 실행됩니다. 또한 command 모드로도 실행이 가능한데 verifier /? 라고 실행하면 실행에 필요한 각종 옵션과 구문을 확인할 수 있습니다.

[그림] driver verfier의 실행 화면

Verifier 도구는 특히 device driver 개발자에게 유용하게 사용될 수 있는데 개발중인 driver 파일을 릴리즈하기 전에 작성한 모듈에 대해서 보다 엄격한 환경에서 테스트가 가능하므로 안정성을 높일 수 있습니다. 커널모드에서 BSOD가 발생한 경우에 수집된 memory dump 파일을 분석함으로써 문제의 원인을 찾을 수 있지만 memory dump 파일은 실제 exception이 발생한 시점의 메모리 상태에 대한 dump이므로, 실제로 문제의 원인이 되는 root cause를 밝히지는 못할 수 있습니다. 예를 들어, a.sys라는 드라이버에서 메모리를 corruption 시키고 b.sys에서 이 메모리에 접근함으로써 BSOD가 발생한 경우를 가정해보면 BSOD가 발생하고 dump가 수집된 상황은 b.sys에서 잘못된 메모리를 접근한 시점이 됩니다. 하지만 우리가 찾고자 하는 것은 이러한 memory를 corruption을 시킨 것이 a.sys라는 것을 찾아야 하는데 이럴 때 verifier를 이용해서 a.sys 드라이버에 대해서 감시함으로써 memory가 corruption 되는 시점에서 BSOD를 발생시키도록 할 수 있습니다.

Verifier에는 특정 driver가 가질 수 있는 여러 문제점들에 대해서 검증을 할 수 있도록 여러 옵션을 제공하고 있습니다. 실제 verifier를 사용하고 있는 분들도 이들 옵션이 의미하는 바에 대해서 모르는 경우가 많은데, 이들 옵션이 의미하는 것과 해당 옵션에서 잡을 수 있는 오류에 대해서 알고 있어야 원하는 결과를 얻을 수 있습니다. 무분별하게 verifier 옵션을 사용할 경우 오히려 찾으려는 문제점과 관련없는 쪽으로 시선을 돌리게 되어 시간을 헛되이 보낼 수도 있기 때문입니다.

이러한 의미에서 verifier가 제공하는 여러 옵션 항목과 그 역할을 알아보도록 하겠습니다.

[그림] verifier에서 제공하는 여러 검사 옵션들

1. Special pool

이 옵션이 활성화 되어 있으면, 검사 대상이 되는 driver에서 요청한 메모리에 대해서 일반적으로 사용되는 pool 영역이 아닌 special pool이라는 별도의 영역을 이용해서 할당합니다. 그리고 할당된 이후에 이 영역에 대한 메모리 사용시 모니터링함으로써 overrun, underrun, 이미 해제된 메모리에 접근하는 등의 잘못된 메모리 접근이 감지되면 바로 BSOD를 발생시킵니다.

2. Pool tracking

이 옵션이 활성화 되어 있으면, 특정 드라이버가 unload 되는 시점에  해당 드라이버에서 memory leak이 발생했는지 확인하고 있으면 BSOD를 발생시킵니다. 즉, 해당 드라이버에 의해서 할당된 메모리 영역에 대해서 해제가 되지 않은 채로 드라이버가 언로드가 되는 것을 감지하고 싶을 경우에 사용하면 됩니다.

3. Force IRQL checking

이 옵션이 활성화 되어 있으면 해당 드라이버가 적절한 IRQL에서 메모리에 접근하는지를 검사하게 됩니다. 커널 모드 드라이버는 page fault handler가 처리할 수 없는 high IRQL에서 메모리에 접근해서는 안됩니다. 왜냐하면 접근하려는 page가 page out되어 invalid한 상태일 경우 이를 다시 paging file에서 page in 시켜서 물리적 메모리로 불러와야 하는데 high IRQL에서는 이를 처리할 방법이 없기 때문입니다.

4. I/O verification

이 옵션이 활성화 되어 있으면, I/O manager가 해당 드라이버를 위한 IRPs를 special pool을 이용해서 할당하고 이를 모니터링합니다. 만약 올바르지 않은 상태에서 IRP가 completion 되거나 I/O manager에게 잘못된 device object가 전달되려고 하면 Bug check을 발생시킵니다.

5. Enhanced I/O verification

이 옵션이 활성화되면, 감시 대상이 되는 드라이버에 대한 모든 IRP를 모니터링하고 비동기 completion, device stack location을 제대로 관리하는지, device object를 한번만 제거하는지 등에 대한 검사를 수행합니다.

6. Deadlock detection (Win XP 이후)

이 옵션이 활성화되면, 해당 드라이버에서 spin lock, mutex, fast mutex을 사용하는 경우를 모니터링하고 잠재적으로 deadlock을 발생시킬 수 있는  코드가 있는지를 검증합니다.

7. DMA checking (Win XP 이후)

 DMA는 Direct Memory Access의 약자로서 CPU 도움없이 하드웨어가 물리적 메모리에 직접 접근할 수 있도록 해주는 기술을 말합니다. 이 옵션이 활성화 되어 있으면, DMA 관련 함수가 제대로 사용되는지 그리고 DMA 수행에 대해서 I/O manager가 제공하는 버퍼가 사용될 때 올바르게 사용되는지를 감시합니다.

8. Low resources simulation

일반적으로 커널모드 드라이버는 메모리 사용이 원활한 상태를 가정하고 개발이 되는데, 이 옵션을 활성화하면 시스템 자원이 부족하여 메모리 할당에 대한 요청을 제대로 처리할 수 없는 상황을 시뮬레이션합니다. 이러한 메모리 부족 상태에서 해당 드라이버가 적절하게 동작할 수 있는지 검증하는데 사용됩니다.

9. Disk Integrity Verification (Win 2003 이후)

 이 옵션이 활성화되면, 하드 디스크에 접근을 모니터링하고 디스크가 데이터를 제대로 보존하는지에 대해서 검증합니다.

10. IRP logging (Win 2003 이후)

이 옵션이 활성화되면, 해당 드라이버의 IRP 사용을 모니터링하고 이를 WMI 정보로 저장합니다. 이 WMI 정보를 텍스트 파일로 추출하려면 WDK에 포함되어 있는 DC2WMIParser.exe를 사용하면 됩니다.

[참고자료]

Windows 2000에서 Driver Verifier를 사용하여 장치 드라이버 문제를 해결하는 방법
http://support.microsoft.com/kb/244617

Driver Verifier
http://www.osronline.com/DDKx/ddtools/dv_7g8j.htm