디버깅 툴을 이용한 윈도우 8 충돌 원인 파악 방법

죽음의 블루 스크린 윈도우 8에서 죽음의 블루 스크린(Blue Screen of Death/ BSOD)는 크고 간단한 :( 모양의 이모티콘과 간단한 정보를 제공하는 짧은 설명으로 변경되었다. 또한 마이크로소프트는 덤프 파일 생성과 관리 프로세스에 있어서도 발전된 모습을 보여주었다. 비록 이 기사 내용은 윈도우 8에 초점이 맞춰져 있지만, 윈도우 RT와 윈도우 서버 2012에도 모두 동일하게 적용된다.

충돌 현상은 보호 조치다 대부분의 경우, 충돌 현상은 운영체제 보호 조치의 일환으로 발생한다. 운영체제가 핵심 기기의 고장이나 내부 운영체제 상태가 바이러스, 잘못된 기기 드라이브, RAM 고장 등에 의해서 이상징후가 감지되면, 더 많은 피해가 발생하기에 앞서 즉각적으로 중단하는 것이 보통 더욱 안전한 방안이다. 시스템 충돌 현상 3번 중 2번은 커널(Kernel) 모드, 즉 운영체제 커널과 하드웨어에 직접적 접속을 가지는 상태에서 부적절한 행동을 취하는 서드파티 드라이버 때문에 발생하게 된다.

메모리 덤프 덕분이다 메모리 덤프는 최고이자 최악의 친구라고 할 수 있다. 이는 운영체제가 멈췄을 때 컴퓨터 시스템 상태를 보여주는 스냅샷이다. 윈도우 8에서 운영체제는 작은 메모리 덤프, 커널 메모리 덤프, 전체 메모리 덤프, 자동 메모리 덤프를 만들어낸다. 윈도우 8 스타일 메뉴(Style Menu)에 간단히 “제어판”을 입력하면 앱스(Apps) 페이지로 이동하여 “제어판”을 감싸고 있는 하얀 상자를 보게 될 것이다. 거기서 엔터를 누른다.

메모리 덤프 경로 윈도우 8 메모리 덤프 설정(Windows 8 Memory Dump Settings)을 확인하려면, 제어판에서 시작하여 제어판 > 시스템 및 보안 > 시스템 > 고급 시스템 설정 > 시작 및 복구 > 설정을 따라가면 된다.

시작 및 복구 시작 및 복구 대화상자에서 시스템 오류의 디버깅 정보 쓰기에 ‘자동 메모리 덤프’가 체크되어있는지 확인하라. 또한 ‘시스템 로그에 이벤트 기록’과 ‘자동으로 다시 시작’ 항목이 모두 체크되어 있는지도 확인하면 좋다.

WinDb 설치하기 PC를 WinDbg 기반 충돌 분석에 맞추려면, 32 혹은 64비트 W8/R2/서버 2012/윈도우7/서버 2008, 윈도우 8 용 윈도우 SDK의 윈도우 부문 디버깅 툴(Debugging Tools), 그리고 256MB정도의 하드 디스크 공간이 필요하다. 먼저 sdksetup.exe를 다운로드하라.

skdsetup.exe 실행하기 소프트웨어 개발 키트(Software Development Kit: SDK)를 설치하고, 라이선스 계약에 동의하라. 윈도우용 디버깅 툴(Debugging Tools for Windows)만 남겨두고 나머지 체크마크를 없애고, 설치(Install)을 클릭한다. 덤프 파일을 불러오기 전에 심볼 테이블을 통해서 심볼 파일에 접속할 수 있는지 확인해야 한다.

WinDbg 실행 윈도우 8 UI 상에서 사용할 버전 (x64 혹은 x86)의 WinDbg를 우클릭하고, 화면 아래쪽에서 튀어나오는 바에서 “관리자 권한으로 실행”을 선택하라. 그러면 회색 블록의 아주 지루해 보이는 애플리케이션 인터페이스를 보게 될 것이다. 거기를 데이터로 채우기 이전에 심볼 파일을 어디서 찾아야 할 지부터 이야기해주어야 한다. 정확한 심볼을 사용하는지 확실히 하기 위해 WinDbg의 메뉴바에서 File > Symbol file path를 선택하라.

심볼 검색 경로 심볼 검색 경로(Symbol search path) 창에 다음과 같이 주소를 입력하라: srv*c:\cache*http://msdl.microsoft.com/download/symbols 별표 사이의 주소가 당신이 앞으로 심볼을 저장하고자 하는 장소다. 예를 들어, c: 드라이브의 심볼이라 불리는 폴더 안에 심볼들을 저장한다면, srv*c:\symbols*http://msdl.microsoft.com/download/symbols 을 입력해야 한다. 또, 방화벽이 msdl.microsoft.com에 접속을 허용하도록 확인해두어야 한다.

덤프 파일 생성하기 메모리 덤프가 보이지 않는다면, 스스로 NotMyFault를 사용하여 하나 생성할 수 있다. 시스인터널(SysInternal)의 윈도우 인터널 북(Windows Internals Book) 페이지로 가서 다운로드 링크를 볼 수 있는 북 툴(Book Tools)까지 스크롤해서 내리면 NotMyFault를 찾을 수 있다. http://technet.microsoft.com/ko-kr/sysinternals/bb963901.aspx. NotMyFault는 시스템을 충돌시키기 때문에 잃으면 안 되는 정보를 담은 모든 파일을 저장하고, 모든 애플리케이션을 종료해야 한다. 적절히 준비했다면, 전원이 꺼졌다 다시 부팅되고, 미니덤프와 커널 덤프 모두 생성될 것이다.

NotMyFault 실행하기 NotMyFault를 실행하고 High IRQL 폴트(커널-모드)를 선택한 후 충돌(Crash) 버튼을 눌러라. :( 이 곧바로 나타나고, 적절히 구성해두었다면 미니덤프와 커널 덤프 파일 모두 저장되고 나서 시스템이 재시작 할 것이다. “PC에 문제가 발생했습니다…”라는 메시지가 파란 밴드와 나올 것이다. “세부사항 보내기” 버튼을 클릭하면, 마이크로소프트는 WinDbg와 “!analyze” 명령을 사용하여 문제의 원인을 식별할 것이다. 그 결과물은 알려진 드라이버 버그 수정과 결합하여 고장을 판별하는데 도움을 준다.

WinDbg를 실행하고 (종종) 충돌의 원인 보기 윈도우 8 UI 상에서 우클릭으로 WinDbg를 실행하고 “관리자 권한으로 실행”을 선택하라. 디버거가 실행되면 File > Open Crash Dump 메뉴 옵션을 선택하고, 분석하고 싶은 덤프 파일을 연다. 워크스페이스 정보 저장하기(Save Workspace Information)를 물으면 저장시켜라. 명령 창이 열리게 되고, WinDbg는 분석을 실행하여 그 결과를 창에 띄울 것이다.

WinDbg 오류 메시지 아래는 흔한 오류 메시지들로, 무엇을 의미하고 어떻게 해결해야 하는지에 대한 내용이다. *** 경고: ntoskrnl.exe의 타임스탬프를 확인할 수 없습니다 *** 오류: 모듈은 완전히 로드되었지만 ntoskrnl.exe에 심볼은 로드할 수 없습니다 이 두 가지 메시지가 뜬다면, 원하는 분석이 되지 않는다는 의미다. 이는 “버그체크 분석(Bugcheck Analysis)”이 자동적으로 실행되고,” ***** 커널 심볼이 잘못되었다. 분석할 수 있도록 심볼을 수정하라”라는 메시지가 표시된다.

추정 원인 그런 메시지들이 나오는 가장 큰 원인들은 다음과 같다. 1)무경로(No path)/잘못된 경로(worng path): 심볼 파일로 가는 경로의 미설정이나 입력 실수. 2)연결 실패: 인터넷 연결 확인, 3)접속 차단; 방화벽의 심볼 파일 접속 차단 혹은 찾는 과정에서 파일의 손상. 이 문제가 해결될 때까지 더 이상 나아가면 안 된다. 만약 ‘*** 경고: myfault.sys의 타임스탬프를 확인할 수 없습니다 *** 오류: 모듈은 완전히 로드되었지만 myfault.sys에 심볼은 로드 할 수 없습니다’와 같은 메시지가 표시된다면 걱정할 필요가 없다.

그러면 충돌의 원인은 무엇인가? WinDbg로 덤프 파일을 열면, 자동적으로 기본 분석을 수행하여 “아마도 myfault.sys에 의해 발생되었다”라고 이야기하는 화면과 같이 디버거에 어떠한 직접적 명령도 주지 않은 채 범인을 잡아내곤 한다. 충돌 현상과 미심쩍은 모듈에 대한 더 많은 정보를 얻으려면, !analyze-v와 lmvm 두 명령이 필요하다.

WinDbg에 명령하는 새로운 방식 WinDbg 인터페이스를 유심히 살펴봤다면, “버그체크 분석(Bugcheck Analysis)” 상자 바로 아래에 위치한 “세부 디버깅 정보를 얻으려면, !analyze –v를 사용하라”는 문구가 나오고 그 명령어 링크가 파랗게 표시되어 있는 것을 볼 수 있을 것이다. 이 링크를 누르면 명령어가 바로 실행된다.

!analyze –v의 결과물 !analyze –v가 제공한 분석 결과물은 영어와 프로그래머 언어가 혼합되어 있지만, 그럼에도 아주 훌륭한 시작점이다. 사실 대부분의 경우, 여기에서 더 이상 나아갈 필요가 없다. 충돌의 원인을 식별했다면, 아마 여기까지가 끝일 것이다.

lmvm의 결과물 lmvm은 이미지 경로, 타임 스탬프, 이미지 사이즈, 파일 유형(이 경우에는 드라이버)에서부터 제작 회사, 제품의 소속처, 버전 번호와 설명에 이르기까지 폭넓은 데이터를 제공한다. 몇몇 회사들은 심지어 기술적 지원을 위한 연락처 정보까지 포함시킨다. 벤더의 이름을 찾으면, 벤더 웹사이트로 가서 업데이트, 지식 기반 항복, 기타 지원 정보들을 확인해보라.

나머지 삼분의 일 위의 지시를 따르면 세 번의 충돌 중 두 번 정도는 즉각적으로 원인을 파악할 수 있지만, 나머지 한 경우는 여전히 파악되지 않는다. 명확한 이유가 없거나 같은 이유로 반복되는 충돌을 경험한다면, 메모리 문제일 가능성이 높다. 메모리를 확인하는 두 가지 쓸만한 방으로 윈도우 메모리 진단(Windows Memory Diagnostic) 툴과 멤테스트86(Memtest86)이 있다. 제어판으로 가서 “메모리”를 검색상자에 넣고 “컴퓨터의 메모리 문제 진단”를 선택하면 된다.

윈도우가 문제일까? 사실 윈도우는 시스템 고장 문제를 거의 일으키지 않는다. 그러나 ntoskrnl.exe(윈도우 코어) 혹은 win32.sys (윈도우 상의 “GUI” 레이어를 책임지는 드라이버)가 문제의 원인으로 지목되었다면, 이를 너무 섣불리 받아들이지 말라. 다른 문제의 서드파티 기기 드라이버가 윈도우 요소에 의해 작업을 수행하도록 요청 받고 존재하지 않는 메모리에 쓰라는 등의 잘못된 지시를 내린 경우가 훨씬 많다. 그러므로, 운영체제도 분명히 잘못될 수 있지만, 마이크로소프트에게 잘못들 돌리기 앞서 다른 모든 가능성을 검토해보라.