[Noenemy]'s microgroove

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