BSoD 발생 시 메모리덤프 분석 ======================================== 엔드포인트에서 BSoD 발생 시 아래 절차를 통해 발생 원인을 추측할 수 있습니다. BSoD 화면에서 EDR 관련 드라이버 파일명이 확인되는 경우 --------------------------------------------------------------- #. %windir%\memory.dmp 와 에이전트 Full 로그를 수집하여 분석요청을 합니다. #. 반대로 BSoD 화면상에 다른 제품 드라이버 명이 출력되는 경우, 해당 제품 개발사에 원인 분석요청을 합니다. BSoD 화면에서 드라이버 파일명이 확인되지 않는 경우 --------------------------------------------------------------- 문제가 발생하는 드라이버 파일을 확인하기 위해 필요한 분석 프로그램을 설치합니다. 1. **windbg 설치:** windbg는 `windows sdk `_ 를 통해 설치할 수 있습니다. (windows sdk를 설치하면서 설치할 요소 중 "Debugging Tools for Windows"만 선택하고 나머지는 선택 해제) 2. **덤프파일 열기:** 인터넷이 가능한 PC에서 windbg를 설치한 후 windbg에서 %windir%memory.dmp 를 열어봅니다. (memory.dmp에 읽기 권한 설정 후 windbg 창에 drag 합니다.) 3. **심볼경로 설정:** 덤프가 열리면 다음의 명령 실행합니다. :: .symfix+ .reload 4. **자동분석 실행:** !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: 6. !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 모듈명들은 다음과 같습니다. .. list-table:: windows 모듈명 :widths: 40 60 :align: left :header-rows: 1 * - 모듈명 - 역할 * - nt - 윈도우즈커널 * - hal - H/W 관장 * - io - IO manager * - netio - Network I/O Subsystem * - fltmgr - Filter manager * - ob - Object manager 의심스러운 모듈을 찾아냈다면 lmvm 명령으로 파일의 경로를 확인하고, 해당 파일의 등록정보나 전자서명 정보에서 제조사 등의 정보를 체크합니다. 확인된 의심 모듈이 EDR 관련 모듈이거나 윈도우즈 관련 모듈인 경우, %windir%\memory.dmp 및 에이전트 로그를 수집하여 원인 분석을 요청합니다.