블루스크린 덤프 파일 분석 방법｜WinDbg로 실제 원인 찾기

블루스크린 덤프 파일 분석은 중지 코드와 기본 점검만으로 원인을 좁히기 어려울 때 충돌 당시의 실행 기록을 WinDbg로 확인하는 과정입니다. 다만 분석 결과에 표시된 파일 이름이 곧바로 고장 난 드라이버나 부품을 뜻하지는 않습니다. 발생 조건, 최근 변경 사항과 여러 덤프에서 반복되는 패턴을 함께 봐야 합니다.

WinDbg 분석이 필요한 경우

• 같은 블루스크린이 반복되지만 원인이 분명하지 않습니다.
• 중지 코드가 매번 달라 단순 검색으로 판단하기 어렵습니다.
• 특정 드라이버·프로그램 설치 후 오류가 시작됐습니다.
• 신뢰성 모니터와 이벤트 뷰어만으로 원인을 좁히지 못했습니다.
• 수리점이나 제조사에 전달할 구체적인 충돌 정보를 준비해야 합니다.

한 번만 발생하고 이후 정상인 오류까지 반드시 분석할 필요는 없습니다. 중요한 자료를 먼저 백업하고 같은 조건에서 재발하는지 확인하세요.

분석 순서 한눈에 보기

1. 덤프 파일을 준비합니다

미니덤프 위치

작은 메모리 덤프가 생성됐다면 일반적으로 다음 폴더에 저장됩니다.

C:\Windows\Minidump

Mini날짜-번호.dmp처럼 날짜가 포함된 파일이 여러 개 보일 수 있습니다. 오류가 발생한 시각과 가장 가까운 파일을 선택하세요.

시스템 폴더에서 바로 열면 권한 문제로 실패할 수 있습니다. 원본은 그대로 두고 분석할 파일을 문서 폴더처럼 접근하기 쉬운 위치에 복사해 여는 편이 안전합니다.

덤프 파일이 없을 때

Win + R을 누르고 sysdm.cpl을 실행한 뒤 고급 → 시작 및 복구의 설정에서 디버깅 정보 쓰기 항목을 확인합니다. 작은 메모리 덤프 또는 자동 메모리 덤프가 선택돼 있어야 합니다.

• 페이지 파일을 완전히 꺼두면 덤프 생성에 문제가 생길 수 있습니다.
• 저장장치 여유 공간과 폴더 권한을 확인합니다.
• 전원이 즉시 끊기거나 하드웨어가 멈춘 경우에는 덤프가 생성되지 않을 수 있습니다.
• 설정을 바꿔도 이미 지나간 충돌의 덤프가 새로 생기지는 않습니다.

2. WinDbg를 설치하고 덤프를 엽니다

WinDbg 설치

Microsoft Store에서 WinDbg를 검색하거나 Microsoft 공식 WinDbg 안내 페이지에서 설치합니다. 이름이 비슷한 비공식 디버거 설치 파일은 사용하지 마세요.

덤프 열기

1. WinDbg를 실행합니다.
2. File → Open dump file을 선택합니다.
3. 복사해 둔 .dmp 파일을 선택합니다.
4. 덤프가 로드되고 명령 입력 창이 준비될 때까지 기다립니다.

처음 열 때 Windows 심볼을 내려받느라 시간이 걸릴 수 있습니다. 인터넷 연결을 유지하고 오류 메시지가 표시되는지 확인하세요.

심볼 상태 확인

심볼은 메모리 주소를 Windows 구성 요소와 함수 이름으로 해석하는 데 필요합니다. 기본 Microsoft 심볼 서버를 사용하는 경우 다음 명령으로 경로를 다시 설정하고 새로 불러올 수 있습니다.

.symfix
.reload

회사 프록시, 보안 프로그램과 네트워크 정책이 심볼 다운로드를 막을 수 있습니다. 심볼 오류가 남은 상태에서는 모듈과 호출 스택 해석의 신뢰도가 낮아질 수 있습니다.

3. 기본 분석 명령을 실행합니다

!analyze -v

분석 결과가 길게 출력되면 다음 항목부터 확인합니다.

Probably caused by나 파일 이름 한 줄만 보고 원인을 확정하지 마세요. 해당 모듈이 실제 원인인지, 다른 드라이버의 잘못된 메모리 접근 때문에 피해를 본 것인지 호출 스택과 반복 패턴을 함께 봐야 합니다.

ntoskrnl.exe가 표시될 때

ntoskrnl.exe는 Windows 커널의 핵심 파일입니다. 많은 블루스크린 처리 과정에 관여하므로 결과에 자주 표시될 수 있습니다. 이 파일이 보인다는 이유로 Windows 커널 파일을 내려받아 교체하면 안 됩니다.

다음 정보를 함께 확인하세요.

• 중지 코드와 매개변수
• 스택에 반복해서 나타나는 타사 드라이버
• 최근 설치한 장치와 드라이버
• RAM·저장장치·전원·발열 증상
• 다른 덤프에서도 같은 모듈이 반복되는지

여러 덤프를 비교합니다

한 개의 미니덤프만으로는 우연히 마지막에 실행된 모듈이 강조될 수 있습니다. 오류가 반복됐다면 최근 덤프 3~5개에서 다음을 비교하세요.

• 같은 버그 체크 코드가 반복되는지
• 같은 타사 모듈과 실패 버킷이 반복되는지
• 게임·절전 해제·USB 연결처럼 같은 조건에서 발생하는지
• 드라이버 업데이트 전후로 결과가 달라지는지

중지 코드는 달라도 같은 드라이버가 반복될 수 있고, 반대로 모듈이 매번 달라진다면 메모리·전원·저장장치처럼 넓은 범위의 불안정도 고려합니다.

분석 결과에 따른 다음 조치

BlueScreenView와 WinDbg의 차이

BlueScreenView 같은 도구는 덤프 목록과 드라이버 이름을 빠르게 확인하는 데 편리하지만, 간단한 표시만으로 실제 원인을 확정하기 어렵습니다. WinDbg는 버그 체크 매개변수, 스택과 심볼을 더 자세히 볼 수 있지만 해석에는 더 많은 주의가 필요합니다.

어떤 도구를 사용하더라도 파일 이름 하나를 원인으로 단정하지 않는 원칙은 같습니다.

피해야 할 분석 방법

• 분석 결과에 나온 드라이버 파일을 시스템 폴더에서 직접 삭제하지 않습니다.
• 비공식 사이트에서 DLL·SYS 파일을 내려받지 않습니다.
• 한 개의 덤프만 보고 RAM이나 그래픽카드를 바로 교체하지 않습니다.
• 심볼 오류가 많은 결과를 정상 분석처럼 해석하지 않습니다.
• 개인정보 가능성을 확인하지 않고 덤프를 공개 공유하지 않습니다.

전문가에게 전달할 정보

• 덤프 원본과 발생 날짜
• 중지 코드와 WinDbg 핵심 결과
• 최근 설치·업데이트한 프로그램과 드라이버
• 오류가 반복되는 작업 조건
• 하드웨어 변경, 발열, 이상 소리 여부

덤프 분석 결과를 발생 조건과 함께 전달하면 “가끔 블루스크린이 뜬다”는 설명보다 점검 범위를 빠르게 줄일 수 있습니다.

분석 결과를 오해하지 않는 법

Probably caused by에 나온 파일이 원인인가요?

원인 후보일 수 있지만 확정값은 아닙니다. 호출 스택, 여러 덤프에서의 반복 여부와 최근 변경 사항을 함께 확인하세요.

덤프 파일을 다른 사람에게 보내도 되나요?

시스템 경로와 메모리 정보가 포함될 수 있습니다. 신뢰할 수 있는 지원 담당자에게 필요한 범위만 전달하고 공개 게시판 업로드는 피하세요.

정리

WinDbg 분석의 핵심은 !analyze -v 한 줄이 아니라 정확한 심볼, 여러 덤프의 반복 패턴과 실제 발생 조건을 함께 보는 것입니다. 파일 이름만으로 결론 내리지 말고 결과를 다음 점검을 위한 단서로 사용하세요.

참고한 공식 자료

• Microsoft Learn: Windows Debugging
• Microsoft Learn: Download and Install WinDbg
• Microsoft Learn: Symbol Path
• Microsoft Learn: !analyze Command
• Microsoft Learn: Bug Check Code Reference