3.1 시스템 다운 트러블 슈팅 : 에러 메시지는 무엇인가?

[자손]

에러 메시지에 대한 확인은 '에러 메시지의 확인' 항목에서도 언급이 되어 있습니다.  이 항목은 일반적인 경우에 대한 에러 메시지 확인이라고 하면, 여기서는 시스템이 다운되는 경우에 아주 중요한 에러 메시지의 확인입니다. 많은 사용자들은 에러 메시지에 상당히 무관심한 것 같습니다. 어떤 에러든지 에러가 발생하였을 때 에러 메시지를 보고 판단하는 것은 매우 중요합니다. 하지만 대체로 에러 메시지가 발생하면 그냥 무시하고 문제가 무엇인지 고민하는 경우가 대부분입니다. 시스템이 다운될 때 다양한 현상이 있지만 대부분의 경우에는 에러 메시지가 표시가 되어 그 에러를 확인할 수 있게 됩니다. 일반적으로 프로그래머들은 프로그램을 작성할 때 발생할 수 있는 오류를 감지하여 에러 처리를 합니다. 이것은 매우 중요합니다. 엔지니어가 구성하는 프로젝트에서도 그러한 에러 처리 코드가 있다면 제일 먼저 여기에서 에러가 감지될 것이며, 시스템이 다운되는 데까지 이를 확률을 줄일 수가 있습니다.

우리가 사용하는 응용 프로그램들은 상용으로 판매하기 위해서 버그가 있어서는 안되기 때문에 그 응용 프로그램의 개발자들은 최소한 중요한 부분에는 에러 처리 루틴을 삽입합니다. 시스템에 문제가 있을 때 가장 먼저 에러를 감지할 수 있는 것은 사용자의 프로그램에서 감지할 수가 있으며, 다음에는 사용하는 응용 프로그램에서 감지할 수 있고 마지막으로 운영 시스템에서 에러를 감지할 수 있습니다. 만약 어디에서도 에러를 감지하지를 못했다면 아무런 에러 메시지가 없이 다운되어 버릴 것입니다. 사용자의 프로그램에서 감지된 에러는 사용자가 분석하여 조치하면 됩니다. 응용 프로그램에서 감지된 에러도 응용 프로그램의 도움말을 참조하여 조치하면 될 것입니다. 그런데 응용 시스템에서 감지되는 에러는 대부분이 저수준의 문제이기 때문에 에러 메시지만으로는 분석하기가 어렵습니다. 대부분의 경우가 메모리 상의 문제가 생기는 것이며, 그 결과로 메모리를 덤프하여 표시할 때가 많습니다. 여기에서는 모든 문제를 열거할 수가 없고, 한가지 예를 들어 어떻게 분석하고 어떻게 조치하는지 살펴보도록 합니다.

덤프된 내용은 거의 헥사 코드로 이루어져 있어 일반 사용자가 보기에는 어려움이 많습니다. 그래서 그 내용을 그냥 버리는 경우가 많은데 사실은 매우 중요한 내용입니다. 그 내용을 분석하는데 도움이 될 만한 정보가 있스니다. 그것은 마이크로소프트의 MSDN입니다. MSDN은 Visual C++에 같이 제공이 되며, 컴파일러가 없는 경우에는 MSDN 웹사이트를 방문하면 됩니다. MSDN 웹 사이트는 www.msdn.com 입니다. 앞으로 설명하는 내용은 아래 홈페이지에 있는 내용입니다.

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windows2000pro/reskit/part7/proch33.asp

마이크로소프트의 윈도 2000은 복구할 수 없는 에러 조건을 감지하게 되면 Stop 메시지와 Malfunction 메시지를 포함하여 다양한 시스템 메시지를 생성합니다. 이 메시지는 일반적으로 Blue Screen 메시지라고도 부릅니다. 다양한 Stop 메시지가 가지는 의미의 해석과 그 문제를 해결하기 위해 취해야 하는 적절한 조치를 하기 위해서는 특별한 기술이 필요합니다.

시스템 메시지
윈도 2000에서는 발생된 이벤트에 대해서 다음과 같은 두 가지 종류의 메시지가 생성됩니다.
   - Stop 메시지 : 윈도 2000 커널에서 복구할 수 없는 조건을 감지할 때 생성합니다.
   - Malfunction 메시지 : 프로세서에서 복구할 수 없는 하드웨어 상의 결함을 감지할 때 생성합니다.

Stop 메시지
Stop 메시지는 아래 그림처럼 항상 캐릭터 모드에서 전체 화면으로 표시됩니다. 각각의 메시지는 고유한 헥사 값과 에러의 심벌릭 이름을 가리키는 문자열을 갖습니다. 그리고 다음과 같이 괄호 안에 에러 파라미터를 가리키는 헥사 값이 표시됩니다.

*** STOP: 0x0000001E (0xc0000005 0xFDE38AF9, 0x0000001, 0x7E8B0EB4) KMODE_EXCEPTION_NOT_HANDLED ***

아래 그림에서 보여지는 것처럼 윈도2000 Stop 메시지는 bugcheck, recommended user action 및 debug port information 세 부분으로 구성됩니다. Stop 메시지가 표시되면 먼저 bugcheck 내용을 참조하여 트러블 슈팅을 위한 정보들을 확인합니다. 다음엔 recommended user action 부분을 참조합니다. 이 부분은 윈도2000에서 감지된 에러와 관련된 트러블 슈팅 팁 미 사용자를 위한 팁들을 제공합니다. 마지막으로 debug port information을 참조하여 메모리를 덤프한 파일이 저장되었는지를 확인합니다.

Bugcheck 정보
Bugcheck 정보 영역에서는 괄호 안에 개발자에 의해서 정의된 파라미터인 bugcheck 코드라고 불리는 Stop 에러 코드와 에러에 대한 심벌릭 이름을 포함합니다. 아래 그림에서 Stop 에러 코드는 0x0000001E이고 심벌릭 이름은 KMODE_EXCEPTION_NOT_HANDELED입니다.

Bugcheck 정보 영역에서는 항상 그런 것은 아니지만 종종 문제가 된 소스의 특정 헥사 메모리 주소, 특정 드라이버의 이름 또는 문제로 예상되는 장치의 이름을 포함하는 경우가 있습니다. 그리고 이러한 정보가 표시되지 않는다 하더라도 감지된 문제의 종류를 결정짓게 됩니다. 어떤 조건에서는 커널에서는 Stop 메시지의 첫 줄만 표시하기도 합니다. 이것은 표시를 위한 필수적인 서비스가 에러에 영향을 받는 경우입니다.

Recommended User Action
Recommended User Action 영역에서는 에러 복구를 위한 조치 사항들을 제안합니다. 그 에러가 다시 발생할 것 같지 않은 경우에는 간단히 재기동 할 것만 표시됩니다. 다른 경우로는 Stop 메시지가 반환되면서도 다시 운전이 가능한 상태가 되는 경우가 있습니다. 종종 이러한 것은 최근에 있었던 변화 또는 윈도 2000 셋업 등에서 발생한 문제가 왔다 갔다 하는 경우입니다.

Debug Port Information
Debug port information 영역은 커널 디버거가 활성화 되어 있는 경우에 컴퓨터의 커널 디버거에서 사용하는 통신 파라미터(COM 포트, Baud rate 등)에 대한 내용을 포함합니다. 또한 메모리 덤프 파일이 저장되었는지도 가리킵니다. (덤프 파일 지시는 그 사양이 활성화 되어 있는 경우에만 표시됩니다.)

트러블 슈팅 절차
이 문제에 대해서 MSDN 웹사이트에서는 다음과 같이 트러블 슈팅 할 것을 제안합니다.

윈도 2000의 Stop 메시지에 대한 트러블 슈팅을 하기 위해서 먼저 다음의 질문을 합니다.:

만약 최근에 새로 추가된 하드웨어가 있다면, 그것을 제거한 후에 그 문제가 해결 되는지를 살펴봅니다. 하드웨어 업체에서 제공되는 진단 도구를 사용하여 시스템을 진단합니다. 하드웨어 업체에서 시스템 BIOS 또는 펌웨어가 업데이트 되어 있는지를 확인하여 최신의 것으로 업데이트를 합니다. 그리고 보드가 컴퓨터에 정확하게 장착이 되었는지, 케이블 연결을 잘 되었는지를 확인합니다.

윈도 2000 하드웨어 호환 목록(HCL, Hardware Compatibility List)에서 새로운 하드웨어가 있는지를 확인합니다.

만약 새로운 장치 드라이버 또는 시스템 서비스가 최근에 추가되었다면 그것을 제거하거나 또는 갱신을 하여 그 문제가 해결 되는지를 살펴봅니다. 구성 요소를 제거하거나 비활성 시키기 위해서 안전 보드를 사용해야 할 수도 있습니다.

최신의 바이러스 검색 프로그램으로 컴퓨터를 검사합니다. 바이러스는 하드디스크에 영향을 줄 수 있으며, 그 결과 시스템 Stop 메시지를 발생시킬 수 있습니다.

최근에 설치된 소프트웨어가 있다면, 그 소프트웨어가 윈도 2000과 호환이 되는지 확인합니다. 만약 호환되지 않는다면 메이커로부터 업데이트가 가능한지 또는 패치 파일이 있는지 확인합니다. 만약 없다면 그 소프트웨어를 제거하고 문제가 해결되는지 살펴봅니다.

운영 시스템의 최신 서비스 팩이 설치되어 있는지를 확인합니다.

Caching 또는 Shadowing 등과 같은 BIOS 메모리 옵션들을 비활성화 시킵니다.

이벤트 뷰어에서 시스템 로그와 응용 프로그램 로그를 확인하여 최근에 로그된 에러 메시지가 있는지를 봅니다. 이 메시지로부터 에러의 원인을 찾을 수도 있습니다.

마이크로소프트 Knowledge Base에서 Winnt 키워드와 전체 Stop 에러 코드로 검색을 하여 기존에 같은 에러가 발생한 것이 있는지를 확인합니다.

다른 트러블슈팅 기술이 실패하거나 문제가 가끔씩 발생할 때, 커널 디버깅은 특별한 도움을 줄 수 있습니다. 이러한 경우에 커널 디버거를 사용하여 문제가 드라이버에 있는지 응용 프로그램에 있는지를 가릴 수가 있습니다. 커널 디버깅에 있어서, Bugcheck에 있는 정확인 문장을 찾는 것이 매우 중요합니다. 또한 복잡한 문제를 가려내기 위해서 문제가 발생하는 정확한 스텝을 추적하는 것도 중요합니다.

이상이 마이크로소프트 홈페이지에서 발췌한 내용입니다. 이 외에도 본 사이트를 참조하여 보면 훨씬 많은 내용이 있습니다. 지금 이렇게 복잡하고 어려운 내용을 살펴본 것은 이런 자료를 참조하여 아무리 어려운 내용이라도 시스템 분석을 할 수 있다는 것입니다. 싸이텍 Knowledge Base에도 보면 같은 Stop 메시지에 대한 설명이 있습니다. 여기서도 마이크로소프트 홈페이지에서 그 내용을 확인할 것을 권장하고 있으며, 위와 비슷한 내용의 설명을 하고 있습니다.

이와 같이 덤프된 내용을 분석하여 문제를 조치할 수 있는데 그 전에 더욱 쉽게 문제를 해결할 수도 있습니다. 그것은 문제를 재현하는 것입니다. 만약 문제를 재현할 수 있다면 어떤 경우에 다운되는지를 파악할 수 있으며, 그 경우를 집중적으로 분석하면 되기 때문입니다.