IT 관리자를 위한 필수 응급처치법
블루 스크린은 범인을 알고 있다?
박상옥｜마이크로소프트웨어
“서버가 수시로 재부팅되더니 갑자기 다운됐어요!” 다급하게 도움을 요청해 보지만 이내 익숙한(?) 블루 스크린이 나타난다. 시스템 관리자의 가장 큰 골칫거리 가운데 하나인 블루 스크린. 시스템 관리자들은 아무런 이유 없이 수시로 재부팅되는 시스템 앞에서 가슴이 답답해진다. 그러나 수만 가지 가능성 가운데 정확한 원인을 잡아내는 것은 유능한 어드민의 필수조건! 이제 논리적으로 원인을 분석해 해결 방안을 찾는데 한 발 더 다가가보자.
블루 스크린(BSOD, Blue Screen of Death)은 시스템 관리자들의 가장 논쟁적인 테마 가운데 하나다. 원인도 증상도 너무 다양하기 때문이다. 여기서는 블루 스크린의 발생 원인을 이론적으로 살펴보는 대신 IT 관리자들이 실무에서 자주 접하는 상황을 중심으로 이에 대한 대응법을 살펴본다. 블루 스크린에 대한 이론적인 내용은 마이크로소프트(이하 MS)의 관련 웹 페이지(support.microsoft.com/default.aspx?scid=kb;KO;129845)를 참고하기 바란다.
일반적으로 블루 스크린(STOP 에러)이 나타나는 이유는 다음과 같다.
- 잘못되었거나 호환되지 않는 서비스, 응용 프로그램, 장치 드라이버
- 하드웨어 문제
- 디스크 또는 파일 시스템 손상
- 오래되었거나 호환되지 않는 펌웨어 또는 BIOS
- 바이러스
서버가 수시로 재부팅된다면 시스템 관리자는 가장 먼저 메모리 덤프가 기록되었는지 확인하자. 일반적인 시스템은 하드웨어 또는 소프트웨어의 문제가 발생하면 이를 자동으로 감지해 블루 스크린 화면을 띄운 뒤 메모리 덤프 파일을 자동으로 생성한다. 서버가 재부팅되면 <화면 1>과 같이 이벤트 등록 정보를 살펴보자.
버튼으로 정보를 수신할 수 있으며, 기본 파일명은 ‘%SystemRoot%\MEMORY.DMP’이다.
<화면 1> 이벤트 뷰어의 메모리 덤프 정보
윈도우 2000 이상의 운영체제에서 메모리 덤프는 ‘전체 메모리 덤프’, ‘작은 메모리 덤프’, ‘커널 메모리 덤프’ 등 세 가지다. 작은 메모리 덤프는 64KB 크기로 덤프 파일이 생성되며, 크래시에 관한 정보를 거의 얻을 수 없다. 커널 메모리 덤프는 작은 메모리 덤프의 내용을 모두 포함하며, 문제 발생 시점에서 커널 모드 메모리에 로드된 모든 내용을 확인할 수 있다. 그러나 정확하게 문제의 원인을 파악하기 위해서는 전체 메모리 덤프를 사용해야 한다. 전체 메모리 덤프는 시스템에 할당된 물리적인 메모리 크기만큼 덤프 파일이 생성된다.
어떤 메모리 덤프를 사용할 것인가 하는 것은 시스템의 시작 및 복구 옵션에서 설정할 수 있다(<화면 2>). 주의할 것은 전체 메모리 덤프를 설정하면 덤프 파일이 설정된 디스크의 남은 공간이 물리적인 메모리 크기보다 많이 남아 있어야 한다는 점이다.
<화면 2> 디버깅 정보 쓰기 옵션
파일 시스템 오류로 인한 블루 스크린 해결법
<화면 3>은 전형적인 블루 스크린이다. 다음과 같은 에러 메시지가 출력되면서 바이러스와 파일 시스템을 체크하라는 메시지가 나타나면, 디스크 또는 파일시스템의 오류로 인한 부팅 실패일 가능성이 높다.
STOP: 0x0000007B : Bug Check Code
(parameter1, parameter2, parameter3, parameter4)
이럴 때는 먼저 운영체제 CD로 재부팅한 후 복구 콘솔로 들어가 ‘chkdsk /f /r’ 명령으로 체크 디스크를 실행하면 정상적으로 부팅할 수 있다. 해당 하드디스크를 정상적인 시스템에 슬레이브(Slave) 하드디스크로 연결한 후 chkdsk를 실행하거나 바이러스 체크를 하는 방법도 있다.
<화면 3> 블루 스크린
때로는 시스템 부팅시 로드되는 시스템 파일이 손상되거나 해킹으로 인해 파일이 삭제돼 블루 스크린이 나타나는 경우도 있다.
Bug Check 0x6F: SESSION3_INITIALIZATION_FAILED
(parameter1, parameter2, parameter3, parameter4)
실제로 필자는 해킹을 당해 시스템 세션 매니저 파일인 smss.exe 파일이 삭제돼 부팅이 되지 않는 사례가 있었는데, 이 때는 정상적인 시스템의 smss.exe 파일을 손상된 시스템의 System32 폴더 하위에 복사해 해결할 수 있었다.
덤프 파일을 ‘제대로’ 읽자
블루 스크린이 나타난 후 정상적으로 시스템이 부팅되고 Memory.DMP 파일이 생성됐다면 이제 해당 덤프파일을 근거로 문제의 원인을 파악해야 한다. 보통 이런 증상의 원인은 잘못되었거나 호환되지 않는 서비스나 응용 프로그램, 장치 드라이버나 하드웨어의 문제 등을 의심할 수 있다. 이제 덤프 파일을 분석해 원인을 파악해야 하는데 어디서부터 어떻게 시작해야 할까.
해법은 의외로 가까운 곳에 있다. 가지고 있는 윈도우 CD에서 SUPPORT 폴더를 검색해보자. 하위에 SUPTOOLS.MSI라는 윈도우 서포트 툴이 있는데 이를 설치하면 DumpChk.exe 프로그램을 사용할 수 있다. 이는 덤프 파일을 분석하는 툴로, 간단한 조작만으로도 덤프의 기본 정보를 얻을 수 있다.
<화면 4> dumpchk를 이용한 덤프 파일 분석
그러나 더 세밀한 분석을 위해서는 윈도우 디버깅 툴을 사용해야 한다. 설치된 운영체제의 i386 폴더(즉 OS CD의 I386) 파일과 Symbols 파일, 디버깅 툴, Memory.dmp 파일 등이 필요한데, MS 웹 사이트(www.microsoft.com/whdc/devtools/debugging/default.mspx)에서 관련 정보를 얻을 수 있다. 여기서 Install Debugging Tools for Windows 32-bit Version 메뉴와 Download Windows Symbol Packages 메뉴를 통해 디버깅 툴과 Symbol 파일을 다운로드할 수 있다. 이제 해당 파일을 차례로 서버에 설치하면 Crash Dump 파일을 분석할 준비를 마친 것이다. 설치를 마치면 명령 프롬프트에 다음과 같이 입력해 디버깅을 한다.
C:\Program Files\Debugging Tools for Windows> windbg -y SymbolPath -i ImagePath -z DumpFilePath
C:\Program Files\Debugging Tools for Windows> kd -y SymbolPath -i ImagePath -z DumpFilePath
이렇게 하면 Windbg는 GUI(Graphical User Interface)로 결과를 출력하며, KD는 커맨드 라인(Command Line)에서 결과를 보여준다.
C:\Program Files\Debugging Tools for Windows> windbg -y SRV*c:\winnt\symbols*http://msdl.microsoft.com/download/symbols -i d:\i386 -z d:\dump\Memory.DMP
C:\Program Files\Debugging Tools for Windows> kd -y SRV*c:\winnt\symbols*http://msdl.microsoft.com/download/symbols -i d:\i386 -z d:\dump\Memory.DMP
덤프 파일을 실제 디버깅한 결과는 ‘이달의 디스켓’으로 제공한다. 특히 주목해야 할 부분은 Probably caused by : v3engine.sys (v3engine+14fc) 부분이다. 이는 V3 백신의 드라이버 파일로, 해당 프로그램으로 인해 블루 스크린이 나타난 것임을 알 수 있다. 이 사례에서는 V3 백신 프로그램 제거해 시스템을 정상적으로 구동할 수 있었다. 이밖에 kd> 프롬프트 상태에서 확인할 수 있는 옵션 명령어는 매우 다양하다. 자세한 내용은 디버깅 도움말에서 확인하기 바란다.
한편 블루 스크린의 하드웨어적인 문제는 그 원인을 찾기가 더욱 어렵다. IBM, hp, 델 등 주요 벤더 제품이라면 업체가 제공하는 하드웨어 진단 툴을 이용하면 된다. 한 가지 주의할 것은 BIOS나 펌웨어의 버전이 낮을 경우 진단 툴로 문제를 인식하지 못하는 경우가 흔하니 반드시 이를 업그레이드한 후 점검하기 바란다. 점검 결과 하드웨어의 문제로 판명나면 해당 업체에 A/S를 의뢰하자.
지금까지 덤프 파일을 분석하는 방법을 살펴봤다. 시스템 어드민에게 있어 블루 스크린처럼 보기 싫은 것도 없다. 그러나 영화 ‘공공의 적’에서 나온 대사처럼 ‘현장은 범인을 알고 있다’. 윈도우 서버 시스템의 문제는 블루 스크린과 덤프 파일에 모든 증거가 담겨 있으므로 자신있게 다가서자.
디버깅 툴의 보너스 툴
앞서 언급한 윈도우용 디버깅 툴을 서버에 설치하면 응용 프로그램을 디버깅할 수도 있다. 실제로 현업의 시스템관리자들은 IIS(Internet Information Server)의 문제를 호소하는 경우가 많은데, 대표적인 증상이 IIS에서 구동되는 주 스크립트인 ASP 페이지가 제대로 작동하지 않는 것이다. 즉 html과 같은 정적인 페이지는 정상적으로 로딩되지만 ASP 동적 스크립트는 많은 사용자가 동시에 접속하면 응답이 없거나 사이트가 느려지는 것이다.
대부분 IIS에서 ASP 문제는 잘못된 스크립트 코드에서 시작된다. 이럴 때 어디서부터 손을 대야할 지 막막한 상황이라면 앞서 언급한 디버깅 툴로 IIS에 대한 덤프를 만들어 보자. 해당 툴이 설치된 폴더 하위에 보면 ADplus.VBS란 파일이 있는데, 이를 이용하면 현재 IIS의 문제에 대한 덤프 파일을 만들 수 있다.
C:\Program Files\Debugging Tools for Windows>cscript adplus.vbs -crash -iis
C:\Program Files\Debugging Tools for Windows>cscript adplus.vbs -hang -iis
해당 덤프 파일이 생성되면 블루 스크린의 메모리 덤프를 디버깅한 것처럼 IIS의 덤프 파일을 디버깅해 문제의 원인을 찾는 힌트를 얻을 수 있다. 덤프 파일은 디버깅 툴의 기본 폴더인 C:\Program Files\Debugging Tools for Windows 하위에 생성된다. 이와 관련된 기술 정보는 MS 웹 페이지(support.microsoft.com/default.aspx?scid=kb;kr;286350)를 참고하기 바란다.
제공 : DB포탈사이트 DBguide.net