BSOD는 "Blue Screen Of Death" 약어로 디바이스 드라이버를 개발하다 보면 종종 만나는 오류입니다. 이번 시간부터
제가 경험한 오류를 가지고 윈도우에서 만들어 준 덤프 파일을 가지고 같이 분석해 보는 시간을 갖도록 하겠습니다.
BAD_POOL_CALLER 오류는 IRQL이 잘못된 경우와 메모리 해제한 메모리 번지에 접근해서 또 다시 해제할 경우 주로
발생하는 오류입니다.
일단 BAD_POOL_CALLER 오류가 발생한 덤프 파일을 보고 같이 분석을 해 보겠습니다.
덤프 파일을 Windbg를 이용하여 열면 위와 같은 화면이 나올 것입니다.
그럼 가장 먼저 해야 할 일은 "!analyze -v"을 입력하는 것입니다. 이젠 분석의 반은 끝난 것입니다.
"!analyze -v"입력하면 위와 같은 화면들이 훅~~ 나타날 것입니다. ^^*
기본적으로 "!analyze -v"로 선분석은 끝나는 것입니다. 해당 명령으로 오류의 원인은 대충 알게 되는
것입니다.
위의 빨간색 네모칸을 보면 대충 어떤 상황에서 발생하였는지 감이 올 것 입니다. ^^*
위의 오류는 IRQL이 잘못된 경우가 아니라, 메모리 참조 관련 오류가 발생한 것 같습니다.
즉, 해제한 메모리 주소에 접근하여 또 다시 메모리 해제를 해서 BSOD가 발생한 것 같습니다.
그럼, 어떤 메모리를 잘못 건들려서 BSOD가 발생하였는지 훅~ 들어 가 보겠습니다.
"!analyze -v"명령을 통해서 분석 결과 화면에서 "!locks 80549ee0" 부분을 자세히 보십시요.
Windbg의 Help에서 "!locks"찾아 보니, 아래와 같이 설명을 해 줍니다. (친천한 Help 선생님..^^*)
BSOD를 발생한 드라이버가 리소스를 처리하다가 문제가 났구라라는 생각이 훅 드시죠?
그럼 하라는 데로 일단 "!locks 80549ee0"명령을 수행해 보겠습니다.
위의 내용을 보면, SystemResourcesList는 Linked List로 보이는데 해당 내용을 해제를 하다가 문제가 난 것으로
보여집니다.
그럼 정확하게 위에서 분석한 내용이 맞는지 훅~ 들어가 보겠습니다.
특정 구조체를 살펴 보기 위해스는 "dt" 명령을 사용합니다.(Windbg의 Help를 참고하세요!)
"dt" 명령을 사용하여 ERESOURCE 구조체 형채가 어떻게 생겼는지 확인해 보겠습니다.
위의 그림처럼 ERESOURCE 구조체 형태를 보면 어디에서 많이 본 것이 보일 것 입니다.
어떻게 찾았나요? 바로 SystemResourcesList라는 놈입니다. BSOD를 발생한 부분과 연관이 있는 내용입니다.
이젠 정말 오류를 발생한 드라이버에서 해제된 메모리 번지를 참조했는지 확인해 보겠습니다.
"dt _ERESOURCE 80549ee0" 명령을 사용하면 해당 번지에 구조체 값들을 보여 주게 됩니다.
위의 화면을 보면 메모리가 깨져있는 것을 볼 수가 있습니다. 즉 이미 해제가 된 것입니다.
결론적으로 오류를 발생한 드라이버에서 이미 해제된 ERESOURCE 구조체 포인터를 다시 접근해서 메모리 해제를
시도할려다가 발생한 오류인 것입니다.