BSoD 발생 시 메모리덤프 분석
엔드포인트에서 BSoD 발생 시 아래 절차를 통해 발생 원인을 추측할 수 있습니다.
BSoD 화면에서 EDR 관련 드라이버 파일명이 확인되는 경우
%windir%memory.dmp 와 에이전트 Full 로그를 수집하여 분석요청을 합니다.
반대로 BSoD 화면상에 다른 제품 드라이버 명이 출력되는 경우, 해당 제품 개발사에 원인 분석요청을 합니다.
BSoD 화면에서 드라이버 파일명이 확인되지 않는 경우
문제가 발생하는 드라이버 파일을 확인하기 위해 필요한 분석 프로그램을 설치합니다.
windbg 설치: windbg는 windows sdk 를 통해 설치할 수 있습니다. (windows sdk를 설치하면서 설치할 요소 중 "Debugging Tools for Windows"만 선택하고 나머지는 선택 해제)
덤프파일 열기: 인터넷이 가능한 PC에서 windbg를 설치한 후 windbg에서 %windir%memory.dmp 를 열어봅니다. (memory.dmp에 읽기 권한 설정 후 windbg 창에 drag 합니다.)
심볼경로 설정: 덤프가 열리면 다음의 명령 실행합니다.
.symfix+
.reload
자동분석 실행: !analyze -v를 실행한 후 출력되는 분석 보고서를 면밀하게 읽어봅니다.
분석 결과 중에 아래와 같은 부분(MODULE_NAME)이 있으면 이 드라이버가 문제일 가능성이 높습니다. 문제 드라이버가 확인된 경우 해당 드라이버 개발사에 원인 분석을 요청합니다.
6: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000001, The system cumulatively spent an extended period of time at
DISPATCH_LEVEL or above. The offending component can usually be
identified with a stack trace.
...
MODULE_NAME: check64 <<< 이 부분!!
IMAGE_NAME: check64.sys
...
의심스러운 드라이버 이름이 확인되었지만, 이 드라이버에 대한 정확한 정보를 파악할 수 없다면 해당 PC에서 드라이버 파일을 찾아 정보를 확인해야 합니다. 예를 들어, 확인된 드라이버 이름이 f_ih.sys인 경우 lmvm 명령으로 해당 드라이버 위치(Image path)를 확인할 수 있습니다. 드라이버 파일을 찾아서 등록정보 등을 확인해보면 개발사를 유추할 수 있습니다.
6: kd> lmvm f_ih
Browse full module list
start end module name
fffff805`37030000 fffff805`3703a000 f_ih (deferred)
Image path: \??\C:\windows\SYSTEM32\DRIVERS\f_ih.sys
Image name: f_ih.sys
Browse all global symbols functions data
Timestamp: Tue Oct 18 09:43:46 2016 (58057042)
CheckSum: 0001256B
ImageSize: 0000A000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:
!analyze -v 결과 중에 의심 드라이버가 특정되지 않은 경우, CallStack 부분을 주의깊게 살펴봅니다.
STACK_TEXT:
ffff9881`99fe5b08 : nt!KeBugCheckEx
ffff9881`99fe5b10 : nt!KeAccumulateTicks+0x181641
ffff9881`99fe5b70 : nt!KeClockInterruptNotify+0x98c
ffff9881`99fe5f30 : hal!HalpTimerClockInterrupt+0xf7
ffff9881`99fe5f60 : nt!KiCallInterruptServiceRoutine+0xa5
ffff9881`99fe5fb0 : nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
ffffbd05`dfd57660 : nt!KiInterruptDispatchNoLockNoEtw+0x37
ffffbd05`dfd577f0 : nt!KxWaitForSpinLockAndAcquire+0x30
ffffbd05`dfd57820 : nt!KeAcquireSpinLockRaiseToDpc+0x87
ffffbd05`dfd57850 : check64!test::Lock+0x30 [c:\test.cpp @ 205]
ffffbd05`dfd57880 : check64!test::EnumElement+0x65 [c:\test.cpp @ 277]
ffffbd05`dfd578d0 : check64!testanalyze::fileinfo+0x10f [c:\testanalyze.cpp @ 1786]
ffffbd05`dfd57950 : check64!testcheckInfo+0x100 [c:\testcheck.cpp @ 7214]
ffffbd05`dfd579f0 : check64!testcheckCallback+0x1ca [c:\testcheck.cpp @ 3189]
ffffbd05`dfd57a50 : check64!stest::memoryQueue+0x9e [c:\stest.cpp @ 118]
ffffbd05`dfd57a90 : check64!stest::checkFunc+0x9d [c:\stest.cpp @ 145]
ffffbd05`dfd57b10 : nt!PspSystemThreadStartup+0x55
ffffbd05`dfd57b60 : nt!KiStartSystemThread+0x28
Callstack의 각 항목은 다음과 같은 의미를 가집니다.
[주소/인자 등 16진수] : [모듈이름] ! [해당 모듈 내의 주소 / Offset]
예를 들어 아래와 같은 항목은 nt 커널의 KiStartSystemThread+0x28 메모리 주소를 의미합니다.
ffffbd05`dfd57b60 : nt!KiStartSystemThread+0x28
Callstack은 아래쪽이 먼저 호출된 함수, 윗쪽이 나중에 호출된 함수를 의미합니다. Callstack을 위에서부터 아래로 내려오면서 나중에 호출된 모듈부터 살펴봅니다. 이때, Windows의 구성요소가 아닌 모듈 중 가장 처음 나타나는 모듈이 문제를 일으켰을 가능성이 높습니다. 예를 들어, 위의 Callstack에서는 다음과 같은 순서로 모듈이 나타납니다.
nt >> hal >> nt >> check64 >> nt
이 중에서 nt, hal 는 windows의 구성요소이기 때문에 windows 구성요소가 아닌 모듈중에서 처음으로 나타난 check64가 문제를 일으킨 모듈입니다. 일반적으로 Callstack에 많이 등장하는 Windows 모듈명들은 다음과 같습니다.
모듈명 |
역할 |
|---|---|
nt |
윈도우즈커널 |
hal |
H/W 관장 |
io |
IO manager |
netio |
Network I/O Subsystem |
fltmgr |
Filter manager |
ob |
Object manager |
의심스러운 모듈을 찾아냈다면 lmvm 명령으로 파일의 경로를 확인하고, 해당 파일의 등록정보나 전자서명 정보에서 제조사 등의 정보를 체크합니다. 확인된 의심 모듈이 EDR 관련 모듈이거나 윈도우즈 관련 모듈인 경우, %windir%memory.dmp 및 에이전트 로그를 수집하여 원인 분석을 요청합니다.