본문으로 건너뛰기
오류사전오류 코드 해결 사전

홈 › 가이드

블루스크린 덤프 파일 읽는 법

확인일 2026.09.04

블루스크린은 Windows가 안전한 동작을 계속할 수 없는 상태를 만나 시스템을 멈춘 것으로, Microsoft 문서는 이를 버그 검사(bug check)라고 부릅니다. 화면에는 중지 코드가 적히고, 덤프 파일이 남아 있을 수 있습니다. 이 가이드는 Microsoft의 디버거 문서(개발자용)에서 일반 사용자가 실제로 할 수 있는 부분만 골라 한국어 문장으로 옮긴 것입니다. 화면에서 무엇을 적어야 하는지, 덤프 파일을 WinDbg로 열어 !analyze -v를 실행하면 어떤 항목을 보면 되는지, 그다음 어디로 가면 되는지의 순서입니다. 원문 자체도 프로그래머용이라고 밝히면서 일반 사용자는 Microsoft 지원의 ‘중지 코드 오류 문제 해결’ 페이지를, IT 전문가는 ‘중지 코드 오류 고급 문제 해결’ 페이지를 보라고 안내하니, 덤프 분석이 부담스러우면 그 페이지와 이 사이트의 블루스크린 허브만으로도 충분합니다.

1. 화면에서 적어 둘 것

원문은 오류 메시지의 버그 검사 정보 부분에 있는 문구를 정확히 옮겨 적어 두라고 합니다. 중지 코드에는 두 가지 표기가 있습니다. 하나는 DRIVER_POWER_STATE_FAILURE 같은 상수명(symbolic name)이고, 다른 하나는 9F 같은 16진수 코드값입니다. 원문의 예에서 DRIVER_POWER_STATE_FAILURE의 코드값은 9F이며, 버그 검사 코드 참조표에는 0x0000009F로 실려 있습니다. 같은 코드를 0x9F, 9F, 0x0000009F로 다르게 적을 수 있다는 점은 오류 코드 검색하는 법에 정리했습니다. 이 사이트에서는 상수명으로 페이지를 찾습니다(예: DRIVER_POWER_STATE_FAILURE).

모든 버그 검사 코드에는 매개변수 네 개가 붙어 있고, 각 매개변수의 뜻은 코드마다 다릅니다. 참조표의 코드별 문서에 매개변수 설명이 있으며 이 사이트의 코드 페이지도 그 설명을 옮겨 두었으므로, 코드와 함께 매개변수 네 값도 적어 두면 좋습니다. 원문은 복잡한 문제를 좁히려면 실패 직전에 무슨 작업을 했는지 정확한 순서로 기록해 두는 것이 도움이 된다고도 적었습니다.

2. 매개변수 네 개를 얻는 세 가지 방법

화면에서 미처 적지 못했더라도 원문이 제시하는 세 가지 방법으로 다시 얻을 수 있습니다.

  • 이벤트 뷰어: Windows 시스템 로그에 버그 검사 이벤트가 남고, 그 이벤트의 속성에 중지 코드 매개변수 네 개가 적혀 있습니다. 덤프 파일을 다루지 않아도 되므로 가장 쉬운 방법입니다.
  • 덤프 파일: 생성된 덤프 파일을 디버거로 열고 !analyze 명령을 실행합니다. 이 가이드의 3~6번이 이 방법입니다.
  • 커널 디버거 연결: 문제가 나는 PC에 커널 디버거를 붙여 두면 버그 검사가 일어날 때 디버거 출력에 코드값과 매개변수 네 개가 나옵니다. 개발자용 구성이므로 일반 사용자는 건너뛰어도 됩니다.

3. 덤프 파일에 대해 알아 둘 것

버그 검사가 발생하면 버그 검사 덤프 파일이 만들어져 있을 수 있습니다. 이 파일에는 중지 코드가 발생한 시점의 메모리 내용에 대한 정보가 더 담겨 있습니다. 원문이 덤프 파일에 대해 밝히는 사실은 다음과 같습니다.

  • 덤프 파일의 확장자는 보통 .dmp 또는 .mdmp입니다.
  • 네트워크 공유나 UNC 경로에 있는 파일도 열 수 있습니다.
  • 덤프를 만든 PC의 프로세서나 Windows 버전이 분석하는 PC와 같을 필요는 없습니다. 다른 PC에서 분석해도 됩니다.
  • 덤프 파일이 CAB 파일로 묶여 있으면 .cab 확장자까지 지정해서 그대로 열 수 있습니다. 단, CAB 안에 덤프가 여러 개면 하나만 읽고, 함께 들어 있는 다른 파일은 읽지 않습니다.
  • 메모리 내용 자체를 이해하려면 프로세서 레지스터와 어셈블리 지식이 필요합니다. 그러나 !analyze의 자동 분석은 그런 지식 없이도 유용한 정보를 내놓는다는 것이 원문의 설명이므로, 일반 사용자는 자동 분석 결과의 몇 항목만 보면 됩니다.
  • 운영 체제를 멈추지 않고 메모리 정보만 담는 ‘라이브 덤프’ 중지 코드도 있는데, 이는 일반 참조표에 없고 별도 문서에 있습니다.

덤프 파일이 어느 폴더에 어떤 종류(전체·커널·작은 메모리 덤프)로 저장되는지는 이 가이드의 원문 범위 밖이라 여기서는 다루지 않습니다.

4. WinDbg 설치와 덤프 열기

WinDbg는 Microsoft의 Windows 디버거입니다. 원문은 Debugging tools for Windows 페이지에서 내려받으라고 안내합니다. 설치 뒤 덤프를 여는 방법은 세 가지입니다.

  1. 명령줄에서 -z 옵션으로 덤프 파일을 지정해 시작합니다. <SymbolPath>는 기호 파일 경로, <ImagePath>는 실행 파일 경로, <DumpFileName>은 덤프 파일 이름입니다. 자세한 출력을 원하면 -v 옵션을 함께 씁니다. 
    windbg -y <SymbolPath> -i <ImagePath> -z <DumpFileName>
  2. WinDbg가 이미 떠 있으면 File | Open Crash Dump 메뉴를 고르거나 Ctrl+D를 누릅니다. Open Crash Dump 창의 File name에 덤프 파일의 전체 경로와 이름을 입력하거나 찾아서 고른 뒤 Open을 선택합니다.
  3. 디버거가 실행 중일 때 .opendump 명령으로 덤프를 열고 g(Go) 명령을 이어서 실행하는 방법도 있습니다.

-z 스위치를 여러 번 주거나 .opendump를 반복하면 덤프 파일 여러 개를 동시에 디버깅할 수 있습니다. 커널 메모리 덤프나 작은 메모리 덤프를 분석할 때는 크래시 당시 메모리에 있던 실행 파일을 가리키도록 실행 이미지 경로를 지정해야 할 수 있다는 것도 원문의 주의 사항입니다.

5. !analyze -v 실행

원문은 덤프 파일 분석이 실제 디버깅 세션 분석과 비슷하며, 대부분의 경우 !analyze로 시작하라고 합니다. 이 확장 명령은 덤프를 자동으로 분석해 유용한 정보를 내놓고, 자세한 결과를 보려면 -v 옵션을 붙입니다. 결과는 디버거 명령 창에 표시됩니다.

!analyze -v

인터넷에 연결되어 있으면 디버거가 Microsoft의 크래시 해결책 데이터베이스에 접속을 시도합니다. 원문의 예에서는 이 접속이 실패했다는 메시지가 먼저 나오는데, PC가 인터넷에 닿지 못했거나 그 사이트가 동작하지 않는다는 뜻일 뿐 분석 자체와는 별개입니다. 코드값과 매개변수만 보고 싶으면 .bugcheck 명령을 쓰고, 특정 코드의 설명만 보고 싶으면 !analyze -show 뒤에 코드를 적습니다. 매개변수를 함께 적으면 그 매개변수 값에 해당하는 설명까지 나오며, 원문의 예는 DRIVER_POWER_STATE_FAILURE(0x9F)의 매개변수 1이 0x3인 경우입니다. 디버거의 기본 진법이 16이 아니면 코드 앞에 0x를 붙여야 합니다.

!analyze -show 0x9F 0x3

6. 결과에서 볼 항목

!analyze -v의 결과는 항목 이름과 값이 줄줄이 나오는 형식입니다. 원문이 커널 모드(블루스크린) 예시로 설명하는 항목을 위에서부터 정리하면 다음과 같습니다. 이 사이트는 출력 화면을 싣지 않으므로, 항목 이름과 그 뜻만 적습니다.

  • 맨 위의 상수명과 코드값, 설명문: 예를 들어 DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)처럼 상수명 뒤에 코드값이 괄호로 붙고, 그 버그 검사 종류에 대한 일반 설명이 이어집니다. 원문은 이 설명 중 일부는 지금 사례에 해당하지 않을 수 있다고 주의를 줍니다. 상수명으로 이 사이트의 코드 페이지(예: DRIVER_IRQL_NOT_LESS_OR_EQUAL)를 찾으면 됩니다.
  • Arguments(Arg1~Arg4): 매개변수 네 개가 각각 설명과 함께 나옵니다. 원문의 예에서는 세 번째 매개변수 1이 ‘쓰기 작업 실패’를 뜻한다는 식으로 값 옆에 풀이가 붙습니다.
  • DEFAULT_BUCKET_ID: 이 실패가 속한 일반 범주입니다. 원문의 예에서는 DRIVER_FAULT, 즉 드라이버 결함 범주였습니다.
  • BUGCHECK_STR: 버그 검사 코드입니다. 경우에 따라 분류 정보가 덧붙습니다.
  • FAULTING_IP: 오류가 난 시점의 명령 위치입니다.
  • STACK_TEXT: 오류를 낸 구성 요소의 호출 흔적(스택 추적)입니다. 드라이버 파일 이름이 여기서 보이기도 합니다.
  • FOLLOWUP_IP: 오류를 일으켰다고 추정되는 명령입니다.
  • SYMBOL_NAME, MODULE_NAME, IMAGE_NAME, DEBUG_FLR_IMAGE_TIMESTAMP: 그 명령이 속한 기호·모듈·이미지 이름과 이미지 타임스탬프입니다. 일반 사용자에게 가장 쓸모 있는 항목은 IMAGE_NAME으로, 원문의 예에서는 USB 포트 드라이버 파일(USBPORT.SYS)이 나옵니다. 어떤 드라이버 파일이 관련되었는지 알면 코드 페이지의 해결 순서에서 드라이버 항목을 적용할 수 있습니다.
  • BUGCHECKING_DRIVER: 장치 드라이버 코드 안에서 버그 검사가 났으면 그 드라이버 이름이 여기에 표시될 수 있습니다.
  • BUCKET_ID: 이 실패가 속한 구체적인 범주입니다.
  • Followup: 문제 프레임의 소유자 정보입니다. 원문에 따르면 이 항목이 쓸모 있으려면 모듈·함수 소유자를 적은 triage.ini 파일을 먼저 만들어야 하므로, 일반 사용자에게는 해당하지 않습니다.

상황에 따라 다른 항목이 나올 수도 있습니다. 잘못된 주소로 제어가 넘어갔으면 FOLLOWUP_IP 대신 FAILED_INSTRUCTION_ADDRESS가 나오고, 프로세서 오동작이 의심되면 SINGLE_BIT_ERROR, TWO_BIT_ERROR, POSSIBLE_INVALID_CONTROL_TRANSFER가, 메모리 손상이 의심되면 조사에 쓸 !chkimg 명령을 알려 주는 CHKIMG_EXTENSION이 나옵니다. 앱이 튕긴 사용자 모드 덤프라면 예외 기록(EXCEPTION_RECORD)과 예외를 낸 프로세스 이름(PROCESS_NAME)이 대신 나오며, 이때 BUGCHECK_STR에는 버그 검사 코드가 아니라 예외 코드가 표시된다고 원문은 설명합니다.

7. 그다음에 할 일

덤프에서 얻은 상수명(또는 코드값)과 매개변수, IMAGE_NAME의 드라이버 파일 이름을 들고 블루스크린 허브에서 코드 페이지를 찾으세요. 코드 페이지에는 매개변수의 뜻과 원문이 정한 해결 순서가 있습니다. 원문이 덧붙이는 사실도 알아 둘 만합니다. 중지 코드 오류의 약 4분의 3이 결함 있는 드라이버 때문으로 추정되며, Windows에는 드라이버 동작을 실시간으로 검사하는 드라이버 확인 프로그램(Driver Verifier)이 기본으로 들어 있어 명령 프롬프트에서 Verifier를 입력해 시작할 수 있습니다. 다만 검증 코드는 실행에 부담을 주므로 검증할 드라이버 수를 가능한 한 적게 잡으라는 것이 원문의 당부입니다. 버그 검사가 자기 코드 때문이 아니라면 진짜 원인을 고칠 수는 없으니 문제를 우회하는 것이 목표이며, 가능하면 결함 있는 하드웨어나 소프트웨어 구성 요소를 분리해 제거하라고 합니다. 원문은 핵심 구성 요소 재설치, 파일 날짜 확인 같은 기본 절차와 이벤트 뷰어로 해결되는 문제도 많다고 적었습니다. 멈춘 스레드가 원인으로 의심되면 !analyze -hang을, 크래시가 없는데도 분석을 강제하려면 !analyze -f를 쓸 수 있습니다.

일반 사용자를 위한 Microsoft 지원 페이지는 중지 코드 오류 문제 해결과 Windows에서 블루 스크린 오류 해결, IT 전문가용은 중지 코드 오류 고급 문제 해결입니다.

출처: Analyze bug check (stop code error) data, Analyze a kernel-mode dump file by using WinDbg, Using the !analyze Extension, Bug check code reference (Microsoft Learn, CC BY 4.0), 2026-09-03 확인. 문장은 오류사전이 다시 쓴 것이고 명령어는 원문 그대로입니다.