제2의 비엔지니어 인생관을 꿈꾸며

Posted
Filed under Study

How to create memory dump on crashes?

[ What's mean BSoD?]

A Blue Screen of Death (also known as a stop error, BSoD or bluescreen) is an error screen displayed by certain operating systems, most notably Microsoft Windows, after encountering a critical system error which can cause the system to shut down to prevent damage. Bluescreens can be caused by poorly written device drivers, faulty memory, a corrupt registry, or an incompatible Dynamic-link library (DLL).

[Crash 발생시 동작 함수]

시 스템(CPU or OS)이 어떠한 문제(오류)를 인지하였을 경우 또는 커널을 보호해야 하는 경우는 Windows 운영체제 내의 KeBugCheckEx() 함수가 호출됩니다. KeBugCheckEx()함수는 5가지의 Arguments를 포함합니다.


 

Stop code (또는 bugcheck code)
Four stop-code defined parameters

KeBugCheckEx() 함수의 동작은 아래와 같습니다.

Turns off interrupts
Tells other CPUs to stop
Paints the blue screen (BSOD)
Notifies registered drivers of the crash
If a dump is configured (and it is safe to do so), writes dump to disk

위 내용을 정리하면, 아래 Crash 덤프 생성 순서를 확인할 수 있습니다.

[Crash 덤프 생성 순서]

① CPU(또는 OS)에 의한 시스템 오류 감지
② KeBugCheckEx() 함수 실행
③ 시스템의 메모리 내용을 Pagefile.sys 로 저장 (BSoD)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl 내용에 의해 덤프 종류 결정

④ 시스템 재부팅 (Automatically restart 옵션에 의해 결정)
⑤ 운영체제 시작 시 savedump.exe 프로세스 구동 (발생 시간 및 간단한 정보(BugCheck 등)을 Event 등록 )
⑥ Memory.dmp 파일 생성 후 pagefile.sys 에 저장된 내용을 해당 파일로 이동
(기본적으로 %Systemroot% 폴더에 위치함)
⑦ Logon 시 설정에 따라 Dumprep.exe 추가 수행

[Crashes Dump 발생 조건]
System 내 여러 동작 중 Designed 된 또는 정형화된 동작을 위반하는 경우, Windows는 Design 상 반드시 Memory Dump를 발생시키게 됩니다. 즉, KEBugcheckEX()함수에 정의된 값으로 내용을 저장하게 됩니다.

하 지만 몇몇 Crashed Dump 생성 조건에 부합되지 않는 경우는 Dump 가 발생치 않고, Dirty Shutdown 이 발생할 수 있습니다(Software 적인 처리가 안 되는 경우, 즉 H/W 오동작으로 인해 발생되는 시스템 재부팅은 Dirty Shutdown 으로 분리하지는 않습니다). 아래 내용을 참조합니다.

① Memory.dmp 파일이 이미 존재하고, 제어판의 시스템에서 기존 파일에 덮어쓰기 옵션이 반드시 선택되어 있어야 함
② 지정된 파티션에 Memory.dmp 파일을 포함하기에 충분한 디스크 여유 공간이 필요
③ C:\ 드라이브, 즉 Active Partition(시스템 파티션=Boot Volume)에 필히 pagefile.sys가 존재해야 함
④ 특정 하드웨어(시스템 BIOS 등)에서 직접 오류 처리 기능이 있다면, Disable 해야 함 (예, HP ARS)
⑤ SCSI 컨트롤러와 같이 디스크 IO 관련 문제로 Crash가 발생한 경우 Memory.dmp 생성되지 않을 수 있음
⑥ 전체 메모리 덤프 생성시 \%SYSTEMROOT% 파티션에 있는 유효한 페이지 파일(pagefile.sys)의 크기가 실제 물리적 메모리(RAM) 크기에 약 12 MB를 더한 크기 이상으로 존재해야 함

       A. 8GB의 시스템일 경우 pagefile.sys의 설정 ? 8204MB 이상 ((1024 x 8) + 12)
      B. 4GB 이상의 메모리를 가진 시스템은 반드시 Boot.ini 에 PAE 옵션을 추가해야 함
      C. Kernel Dump 수집 시 또한 가능한 2GB 이상의 Pagefile.sys 를 유지 권고



고객사가 말도 안되는 상황에 덤프를 분석하라는 명령따위의 지시를 한적이 있습니다. 덤프의 기본조건을 충족하지 못하면 OS단에서는 볼 가치도 없는 상황인거죠. 즉 비정상 종료(강제 셧다운)이나 메모리 상태를 디스크에 재기록 할수 없는 상황이라면 살인사건에 증거물 없는 DNA 분석이라고 비유하고 싶습니다.
좀 기본도 없는 사람이 어디서 좀 주워들었다고 요즘 DNA 조사하면 다 나오자나? 범인 금방 잡히자나?라는 말을 떠드는거랑 같은거라고 볼수 있습니다.
이런글로 특정 고객을 비아냥 거리는투의 글을 옮기는것이 부끄럽기는 하지만 그냥 주워들은 이야기로 막무가내 밀어부치는건 옳지 않은 행동입니다. 정말로 원인과 해결을 원한다면 차분하게 기본 절차를 밟는것이 좋은게 아닐까 합니다.
블루스크린을 떨어지고 정확하게 덤프가 떨어졌다면 분석에 앞서 한번은 이런생각을 해보고 넘어가야 됩니다. 커널에 영향을 받았다. 그럼 커널에 영향을 받는 요소들은 무엇일까? 시스템의 중요한 화일? 드라이버? 이정도만 인식을 해도 접근하기가 쉽습니다. 어플리케이션단에서 에러가 있어서 블루스크린을 유발했다?라고 한다면 그 어플리케이션이 시스템 드라이버를 핸들링하는 어플리케이션인지도 짚고 넘어가야 됩니다. 어플리케이션은 대부분 USER단에서 구동되기 때문에 시스템 드라이브를 핸들링 하지 않습니다. 핸들링 하는 어플리케이션도 있습니다만 커널영역을 넘나드는 프로그램은 아주 중요시하게 개발이 되야하는 제품입니다.
백신처럼 커널에서 필터 역할을 하는 제품은 제품이 이상증상을 보이면 필터역할을 제대로 못해서 시스템에 큰 영향을 주게 되고 블루스크린을 유발하는 경우도 종종 있습니다. 그래서 백신사용에 있어 단계적 검증이 필요하게 된 시점이기도 합니다. 덤프라는말을 흔히 하지만 그 덤프가 어떤구조와 단계로 이루어지는지는 기본개념은 갖고 있어야 되지 않을까 하는 생각에 위 기본 설명은 다른 블로그에서 퍼왔습니다.
5월 12일자에 교육자료를 잠깐 끼워 넣었습니다.


2012/04/26 01:17 2012/04/26 01:17