본문 바로가기

IT Professional/Windows Management Technology

Crash Dump 의 수집

윈도우 상에서 크래쉬가 발생하는 경우는 2가지의 경우가 있다.
하나는 어플리케이션 상의 크래쉬가 발생하는 경우이며, 다른 하나는 운영체제 상에서 크래쉬가 발생하는 경우다.

운영체제 크래쉬

운영 체제 상의 크래쉬는 크게 문제가 없다. 일반적으로 운영 체제 상의 크래쉬 (흔히들 윈도우 관리자 또는 엔지니어 들이 "블루 스크린" 이라고 의미하는) 가 발생하는 경우 기본 설정이 자동으로 사용자의 HDD 에 덤프를 받도록 설정되어 있으므로 크게 문제가 되지 않는다. 문제가 되는 경우는 아래의 경우다.

1. 운영체제가 32bit 인 경우 : 일반적으로 32 bit 인 경우에는 문제가 되지 않지만, 메모리의 크기가 2GB 이상인 경우 덤프를 생성하는데 문제가 될 수 있다. 이런 경우 레지스트리 값을 조정해야 하지만, 일반적인 경우 4GB 가 넘는 경우 64bit 운영 체제를 사용하는 것이 일반적이므로 이 경우는 논외로 하기로 하자.

2. boot partition (C 드라이브) 에 여유 공간이 메모리의 크기 + 28MB 에 미달하는 경우 : 이 경우 덤프가 생성되지 않는다. 윈도우의 운영 체제 덤프 파일의 생성 원리를 보면 알 수 있는데, 비정상적인 종료가 발생할 경우 레지스트리에 기록되고 해당 레지스트리의 플레그가 있는 경우 페이징 파일을 특정 위치로 옮긴 이후 리네임하게 된다. 이 경우 메모리 크기와 동일한 공간을 차지하는 덤프 파일의 복사 공간이 없는 경우 덤프 생성을 포기하고 재시작을 하게 되므로 이 경우에는 덤프가 생성되지 않는다. 따라서 윈도우의 운영체제 C 파티션에는 가급적 아무 것도 설치하지 말고, 넉넉잡아 10GB 정도는 여유를 두기로 하자. (메모리 크기만 해도 충분하지만, 부지불식 간에, 그리고 패치, 서비스 팩 설치시에 이래 저래 공간을 잡아 먹는다.)

3. HW 적인 오류가 발생한 경우 : CPU, Memory, HDD, Mainboard 등 덤프에 쓰기를 사용하는 device 의 오류가 발생하는 경우, 덤프가 발생하지 않는다. 하지만, 뭐 걱정하지 말자. 이 기기에 문제가 발생했다면, HW 교체 밖에 답이 없으니... 시스템 관리자의 손을 떠난 것이다.

응용 프로그램 크래쉬

워드나 엑셀을 사용하는 경우 가끔씩 응용 프로그램이 비정상적으로 종료되었더면서 재시작되는 경우가 있다. 이런 경우 재수없다 생각하고 여지껏 한 작업을 다시 수행하면 되지만, 해당 프로그램이 서버에서 구동되는 DB 나 Mail 서버의 경우 전사적인 장애를 유발하여 생산성에 치명적인 오류를 유발할 수가 있다.
특히 DB 나 exchange 의 경우 비정상적이 종료 이후에 재시작되는데 30분 이상의 시간이 걸리거나 운이 나쁘면 아예 재시작에 실패하는 경우가 있으므로 해당 장애는 꼭 원인을 규명해야 한다. 이를 위해서 자료를 수집하는 방법
을 알아 보자.

1.MPS report 를 수집한다. (자세한 방법은 이전에 블로깅한 내용을 찾아 보시라.)
2. Windows debugger 를 설치한다.
- Microsoft 사이트에서 windows debugging 또는 adplus 라는 키워드로 검색해 보자.
3. 해당 debugger 를 설치한다.
- 참고로 설치시에는 최신 .net framework 의 설치를 요청하는 경우가 있다. 서버에 함부로 .net framework 의 버전을 올리기가 부담스럽다면, 적당한 노트북에 해당 debugger 를 설치하고, adplus_old.vbs 가 있는 폴더를 하위폴더와 함께 폴더채 복사해서 사용해도 된다.
- 사용시에는 수집하고자 하는 덤프의 응용 프로그램의 bit 에 주의하기 바란다. 당연히 32bit 는 32bit 로 64bit 는 64bit 로만 수집이 된다.
4. 자. 복사가 끝났으면, 해당 폴더로 이동하여 아래와 같이 입력해 보자.
adplus_old.vbs -crash -pn [응용프로그램명.exe]

정상적으로 수집 되었나 아니냐의 검증은 다음 편에서 알아 보기로 하자.