Windows 11을 사용하다 갑자기 파란 화면이 나타난 뒤 재부팅되면 가장 먼저 드는 생각은 “그래픽카드가 고장 난 건가?”, “메모리를 바꿔야 하나?”일 것입니다. 하지만 화면에 잠깐 보인 중지 코드 하나만으로 부품이나 드라이버를 범인으로 확정하면 불필요한 교체와 재설치가 이어질 수 있습니다.

블루스크린은 원인 그 자체가 아니라 Windows 커널이 더 이상 안전하게 실행될 수 없다고 판단해 시스템을 중지한 결과입니다. 따라서 해결의 출발점은 무작정 초기화하는 것이 아니라, 같은 시각에 남은 중지 코드·신뢰성 기록·이벤트 로그·메모리 덤프를 서로 대조하는 것입니다.

이 글은 Windows 11에서 반복되는 블루스크린을 안전하게 진단하는 순서를 설명합니다. WinDbg 결과를 읽는 법까지 다루지만, 덤프에 표시된 파일명 하나를 곧바로 원인으로 단정하지 않는 것이 핵심입니다.

핵심 결론: 이벤트 ID 41은 “정상적으로 종료되지 않았다”는 결과 기록일 뿐, 전원 공급 장치가 원인이라는 확정 증거가 아닙니다. 먼저 발생 시각과 중지 코드를 기록하고, 이벤트 ID 1001과 미니덤프의 BUGCHECK_CODE, MODULE_NAME, IMAGE_NAME, 호출 스택을 함께 확인해야 합니다.

먼저 해야 할 일과 하지 말아야 할 일

블루스크린이 한 번 발생했다면 즉시 Windows를 초기화할 필요는 없습니다. 그러나 같은 중지 코드가 반복되거나 중요한 작업 중 재부팅된다면 데이터 보호와 증거 보존을 먼저 해야 합니다.

지금 바로 할 일

1. 중요한 문서와 사진을 외장 저장장치 또는 신뢰할 수 있는 저장 공간에 백업합니다.
2. 파란 화면의 Stop code와 표시된 드라이버 파일명이 있다면 휴대전화로 촬영합니다.
3. 발생 시각, 당시 실행하던 프로그램, 새로 연결한 장치, 최근 설치한 드라이버를 기록합니다.
4. 오버클럭·언더볼팅·메모리 XMP/EXPO를 사용 중이라면 현재 설정을 메모합니다.
5. C:\Windows\Minidump 폴더의 .dmp 파일을 다른 폴더에 복사해 보존합니다.

처음부터 하지 말아야 할 일

• 출처가 불분명한 “드라이버 자동 업데이트” 프로그램을 설치하지 않습니다.
• 원인을 확인하기 전에 여러 드라이버와 BIOS를 한꺼번에 바꾸지 않습니다.
• 덤프를 확보하기 전에 Windows 초기화나 디스크 정리를 실행하지 않습니다.
• 블로그의 레지스트리 파일을 그대로 병합하지 않습니다.
• 일반 사용자는 Driver Verifier를 시험 삼아 켜지 않습니다. 이 도구는 의도적으로 드라이버에 강한 검사를 가해 추가 충돌이나 부팅 반복을 만들 수 있습니다.

블루스크린 진단은 왜 ‘증거 네 가지’를 맞춰야 할까

중지 코드는 실패한 순간의 유형을 알려주지만, 항상 최초 원인을 직접 지목하지는 않습니다. 예를 들어 IRQL_NOT_LESS_OR_EQUAL은 잘못된 메모리 접근이 감지됐다는 뜻에 가깝습니다. 그 접근을 일으킨 주체는 장치 드라이버일 수도 있고, 불안정한 RAM이나 손상된 데이터가 뒤늦게 드러난 것일 수도 있습니다.

신뢰성 기록은 충돌 전후에 설치된 업데이트와 응용프로그램 실패를 시간순으로 보여 줍니다. 이벤트 로그는 재부팅과 버그 검사 기록을 남기며, 미니덤프는 충돌 당시 커널의 제한된 상태와 호출 스택을 보존합니다. 어느 하나만 보는 것보다 네 가지가 같은 방향을 가리킬 때 판단의 신뢰도가 높아집니다.

1단계: 자동 재시작을 잠시 끄고 중지 코드를 확보합니다

중지 코드가 너무 빨리 사라진다면 다음 경로에서 자동 재시작을 해제할 수 있습니다.

1. Win + R을 누르고 sysdm.cpl을 입력합니다.
2. 고급 탭에서 시작 및 복구 → 설정을 엽니다.
3. 시스템 오류 → 자동으로 다시 시작의 체크를 잠시 해제합니다.
4. 디버깅 정보 쓰기는 우선 소형 메모리 덤프(256KB) 또는 자동 메모리 덤프로 둡니다.
5. 소형 덤프 디렉터리가 %SystemRoot%\Minidump인지 확인합니다.

자동 재시작을 끄면 다음 충돌 때 화면이 유지되므로 코드를 기록하기 쉽습니다. 다만 무인 PC나 원격 장비는 오류 화면에서 멈춘 채 복구되지 않을 수 있으므로 운영 환경에서는 관리 방식에 맞춰 결정해야 합니다.

Microsoft의 시스템 실패·복구 설정 문서도 이 메뉴에서 시스템 로그 기록, 자동 재시작, 디버깅 정보 유형을 구성하도록 안내합니다. 설정을 바꾼 뒤에는 재부팅해야 다음 충돌부터 안정적으로 적용됩니다.

2단계: 신뢰성 기록에서 ‘변경 직후’를 찾습니다

Win + R을 누른 뒤 아래 명령을 실행합니다.

perfmon /rel

신뢰성 모니터에서 블루스크린 발생 날짜의 빨간 X를 선택하고 Windows 오류 또는 Windows가 제대로 종료되지 않음 항목을 확인합니다. 여기서 중요한 것은 오류 개수보다 충돌 직전에 무엇이 바뀌었는지입니다.

• 그래픽 드라이버 업데이트 직후 게임에서만 충돌했는가
• 새 USB 장치를 연결한 이후 대기 모드 복귀 때 발생하는가
• BIOS 업데이트나 메모리 설정 변경 이후 시작됐는가
• 특정 보안·가상화 프로그램 설치 후 반복되는가

단, 시간상 먼저 일어났다는 이유만으로 원인이라고 확정해서는 안 됩니다. 의심 항목을 하나씩 원래 상태로 되돌린 뒤 같은 사용 조건에서 재현 여부를 비교해야 합니다.

3단계: 이벤트 뷰어에서 ID 41과 1001을 구분합니다

1. 시작 버튼을 마우스 오른쪽 버튼으로 누르고 이벤트 뷰어를 엽니다.
2. Windows 로그 → 시스템으로 이동합니다.
3. 오른쪽의 현재 로그 필터링을 누릅니다.
4. 이벤트 ID에 41,1001을 입력합니다.

ID 1001의 일반 탭에는 The bugcheck was: 0x... 형태의 코드와 덤프 저장 경로가 보일 수 있습니다. 이 값과 파란 화면에서 촬영한 Stop code가 같은 사건인지 발생 시각으로 맞춰 봅니다.

반면 ID 41만 있고 버그 검사 코드와 덤프가 없다면 전원 차단, 과열 보호, 하드 리셋, 덤프 작성 실패 등 범위를 넓혀야 합니다. 이때 “ID 41 = 파워 고장”이라고 결론 내리는 것은 지나친 단순화입니다.

4단계: 중지 코드는 ‘원인’이 아니라 조사 방향으로 읽습니다

아래 분류는 대표적인 조사 방향일 뿐 부품 고장 판정표가 아닙니다.

중지 코드가 매번 다르게 바뀌면 여러 부품이 동시에 고장 났다고 보기보다 공통 기반을 살펴야 합니다. 불안정한 메모리 설정, 전원 품질, 메인보드 펌웨어, 저장장치 데이터 손상처럼 여러 실행 경로에 영향을 주는 요소가 코드 변화를 만들 수 있습니다.

5단계: 미니덤프가 생성됐는지 확인합니다

파일 탐색기 주소창에 다음 경로를 입력합니다.

C:\Windows\Minidump

날짜가 이름에 포함된 .dmp 파일이 있다면 최신 파일 하나만 보지 말고 최근 3~5개의 패턴을 비교하는 편이 좋습니다. 분석 전에 바탕화면 같은 별도 폴더로 복사하고 원본은 보존합니다. 덤프에는 실행 중이던 커널 상태와 시스템 정보 일부가 포함될 수 있으므로 공개 게시판에 무심코 올리지 말고 개인정보와 보안 정책을 고려해야 합니다.

Minidump 폴더가 비어 있을 때

덤프가 없다고 해서 블루스크린이 아니었다고 단정할 수는 없습니다. 다음을 확인합니다.

1. 시작 및 복구에서 디버깅 정보 쓰기가 (없음)으로 되어 있지 않은지 확인합니다.
2. Windows가 설치된 드라이브에 충분한 여유 공간이 있는지 확인합니다.
3. 페이지 파일을 완전히 끄지 않았는지 확인합니다. 특별한 이유가 없다면 모든 드라이브의 페이징 파일 크기 자동 관리를 유지합니다.
4. 충돌 순간 저장장치 자체가 응답하지 않았는지 이벤트 로그를 확인합니다.
5. 시스템 정리 도구가 소형 메모리 덤프를 자동 삭제하는지 확인합니다.

전체 메모리 덤프는 정보가 많지만 RAM 용량에 비례해 파일이 매우 커질 수 있고 민감한 데이터가 더 많이 포함될 가능성이 있습니다. 일반 사용자의 첫 진단에는 소형 또는 자동 메모리 덤프가 현실적이며, 커널/전체 덤프는 기술지원 담당자가 구체적으로 요청할 때 선택하는 편이 안전합니다.

6단계: WinDbg로 덤프를 열고 !analyze -v를 실행합니다

Microsoft Store 또는 Microsoft 공식 안내 경로를 통해 WinDbg를 설치합니다. 출처가 불분명한 덤프 뷰어를 관리자 권한으로 실행하는 것은 피합니다.

1. WinDbg를 실행합니다.
2. File → Open dump file에서 복사해 둔 .dmp 파일을 엽니다.
3. 심벌을 불러오는 동안 기다립니다. Microsoft 공개 심벌에 접근하려면 인터넷 연결이 필요할 수 있습니다.
4. 아래 명령을 입력합니다.

!analyze -v

결과에서 먼저 볼 항목은 다음과 같습니다.

예를 들어 ntoskrnl.exe가 표시됐다고 해서 Windows 커널 파일 자체를 교체해야 한다는 뜻은 아닙니다. 커널은 많은 드라이버 호출의 마지막 실행 지점이므로, 제3자 드라이버나 하드웨어가 앞서 잘못된 상태를 만들고 커널에서 최종 감지됐을 수 있습니다.

반대로 서로 다른 날짜의 덤프에서 같은 제3자 .sys 파일이 반복되고, 그 장치 사용 시점과 충돌 조건까지 일치한다면 해당 드라이버의 가능성이 높아집니다. 그래도 파일명을 검색해 임의 삭제하기보다 장치 제조사의 공식 드라이버 설치·롤백 절차를 사용해야 합니다.

특정 모듈 정보를 더 확인할 때

WinDbg에서 의심 모듈의 이름을 확인한 뒤 다음 형식을 사용할 수 있습니다.

lmvm 모듈이름

이 명령은 모듈의 경로, 버전, 타임스탬프 같은 정보를 확인하는 데 도움을 줍니다. 단, 타임스탬프가 오래됐다는 사실만으로 악성 또는 결함 드라이버라고 단정하지 않습니다. 제조사 공식 지원 페이지의 대상 모델·Windows 버전과 비교합니다.

7단계: 원인 후보별로 한 번에 하나만 바꿉니다

특정 드라이버가 반복될 때

1. 장치 관리자에서 장치와 드라이버 공급자·버전을 기록합니다.
2. PC 또는 부품 제조사의 공식 지원 페이지에서 정확한 모델용 드라이버를 찾습니다.
3. 문제가 업데이트 직후 시작됐다면 드라이버 롤백 가능 여부를 먼저 확인합니다.
4. 변경 후 같은 작업에서 재현되는지 관찰합니다.

그래픽 드라이버, 저장장치 필터, VPN, 백신, 가상화 프로그램은 커널 영역과 밀접하게 동작할 수 있습니다. 프로그램을 무작정 여러 개 삭제하기보다 충돌 시점과 덤프에서 반복되는 구성 요소를 기준으로 우선순위를 정합니다.

메모리 관련 코드가 바뀌며 반복될 때

• XMP/EXPO, 오버클럭, 언더볼팅을 기본값으로 되돌립니다.
• PC 제조사가 제공하는 하드웨어 진단을 우선 사용합니다.
• Windows 메모리 진단은 1차 확인 수단으로 사용할 수 있지만, 통과가 모든 간헐 오류를 배제하지는 않습니다.
• 메모리 모듈 재장착이나 슬롯 교차 시험은 전원 분리·정전기 방지 방법을 아는 경우에만 진행합니다.

0x124 또는 WHEA 기록이 반복될 때

WHEA 오류는 “CPU가 반드시 고장”이라는 뜻이 아닙니다. CPU, 메모리 컨트롤러, PCIe 장치, 메인보드, 전원, 냉각, 펌웨어 설정을 포함한 하드웨어 경로를 봐야 합니다. BIOS 기본값에서도 반복되고 제조사 진단에서 오류가 나오면 임의 전압 조정보다 전문 점검이 우선입니다.

0x7A와 저장장치 기록이 함께 나타날 때

중요 데이터를 먼저 백업합니다. SSD 제조사 도구로 상태와 펌웨어를 확인하고, SATA 장치라면 데이터·전원 케이블 경로도 점검합니다. 저장장치가 끊기는 상황에서 반복적인 대용량 검사나 쓰기 작업은 상태를 악화시킬 수 있으므로 SMART 경고나 읽기 오류가 보이면 복구 우선순위를 높여야 합니다.

Driver Verifier는 왜 일반 해결 단계에서 제외해야 할까

Driver Verifier는 Windows에 포함된 고급 검증 도구로, 드라이버의 잘못된 동작을 적극적으로 드러내기 위해 시스템에 추가 스트레스를 줍니다. 잘못 적용하면 정상 사용 중에는 없던 블루스크린이 발생하거나 로그인 전에 충돌이 반복될 수 있습니다.

따라서 다음 조건을 모두 이해하지 못한다면 실행하지 않는 것이 안전합니다.

• 안전 모드 또는 Windows 복구 환경에 진입하는 방법
• 명령 프롬프트에서 검증 설정을 해제하는 방법
• 어떤 드라이버만 대상으로 삼을지 결정하는 방법
• 생성된 덤프를 분석하고 원래 설정으로 복구하는 방법

이 글에서는 활성화 명령을 제공하지 않습니다. 이미 반복 충돌하는 업무용 PC나 BitLocker가 적용된 장비라면 복구 키와 백업 없이 실험해서는 안 됩니다. Driver Verifier가 필요할 정도라면 덤프와 시스템 정보를 제조사 또는 숙련된 기술 담당자에게 전달하는 편이 안전합니다.

이런 경우에는 직접 진단보다 전문 점검이 먼저입니다

• 타는 냄새, 스파크, 배터리 팽창, 비정상적인 고열이 동반됩니다.
• BIOS 기본값에서도 0x124 또는 WHEA 오류가 반복됩니다.
• SSD 진단에서 경고가 나오고 파일 복사가 자주 실패합니다.
• 로그인 전부터 반복 재부팅되어 백업할 수 없습니다.
• 업무·의료·회계 데이터처럼 손실 비용이 큰 장비입니다.
• 덤프마다 오류가 달라지고 제조사 하드웨어 진단에서도 실패합니다.

물리적 이상이 의심되면 전원을 끄고 충전기와 주변기기를 분리합니다. 보증 기간이 남아 있는 제품은 임의 분해가 보증 조건에 영향을 줄 수 있으므로 제조사 정책을 먼저 확인합니다.

블루스크린 진단 체크리스트

• 중요한 데이터를 먼저 백업했다.
• Stop code와 발생 시각을 기록했다.
• 최근 설치한 드라이버·장치·BIOS 변경을 적었다.
• perfmon /rel에서 충돌 전후 변경을 확인했다.
• 이벤트 ID 41과 1001의 차이를 구분했다.
• C:\Windows\Minidump의 최근 덤프를 보존했다.
• WinDbg의 !analyze -v 결과를 여러 덤프에서 비교했다.
• MODULE_NAME 하나만으로 원인을 확정하지 않았다.
• 한 번에 하나만 변경하고 재현 여부를 관찰했다.
• Driver Verifier나 레지스트리 변경을 먼저 실행하지 않았다.

자주 묻는 질문

Q1. 블루스크린이 한 번만 발생해도 부품을 교체해야 하나요?

아닙니다. 일회성 드라이버 충돌이나 업데이트 과정에서도 발생할 수 있습니다. 같은 코드가 반복되는지, 새 하드웨어 또는 설정 변경과 시간상 연관되는지부터 확인합니다.

Q2. 이벤트 ID 41이면 파워서플라이 고장인가요?

ID 41은 정상 종료가 아니었다는 기록입니다. 블루스크린, 정전, 강제 전원 종료, 과열 보호 등에서도 남을 수 있으므로 ID 1001, WHEA 기록, 덤프와 함께 판단해야 합니다.

Q3. ntoskrnl.exe가 원인으로 나오면 Windows를 다시 설치해야 하나요?

대개 그것만으로는 부족합니다. 커널이 마지막 감지 지점으로 표시될 수 있으므로 호출 스택, 반복되는 제3자 모듈, 하드웨어 검사 결과를 함께 봐야 합니다.

Q4. Minidump 폴더가 없는 이유는 무엇인가요?

아직 버그 검사가 없었거나, 덤프 설정이 꺼져 있거나, 페이지 파일·디스크 공간·저장장치 응답 문제 때문에 작성되지 않았을 수 있습니다. 시작 및 복구 설정부터 확인합니다.

Q5. 미니덤프를 인터넷에 올려도 안전한가요?

덤프에는 시스템 경로, 드라이버 정보, 실행 상태 일부가 포함될 수 있습니다. 전체 덤프는 더 민감할 수 있으므로 공개 공유보다 신뢰할 수 있는 지원 창구를 이용하고 조직의 보안 정책을 따릅니다.

Q6. WinDbg에서 Probably caused by가 나오면 범인이 확정된 건가요?

아닙니다. 분석 엔진이 확보된 정보 안에서 제시한 후보입니다. 같은 모듈이 여러 덤프에서 반복되는지, 실제 재현 조건과 일치하는지 확인해야 합니다.

Q7. BIOS는 최신 버전으로 무조건 업데이트해야 하나요?

그렇지 않습니다. 제조사의 변경 내역에 현재 증상과 관련된 수정이 있는지 확인하고, 전원 중단 위험과 BitLocker 복구 키 준비 등 모델별 절차를 따라야 합니다.

Q8. Windows 메모리 진단을 통과하면 RAM은 정상인가요?

기본 검사 통과만으로 온도·부하·특정 타이밍에서 발생하는 간헐 오류를 완전히 배제할 수 없습니다. BIOS 기본값, 제조사 진단, 반복 패턴을 함께 확인합니다.

Q9. 블루스크린 전에 화면만 꺼지고 재부팅됐다면 같은 문제인가요?

가능하지만 확정할 수 없습니다. 이벤트 ID 1001과 덤프가 있으면 버그 검사였을 가능성이 높고, ID 41만 있다면 전원 차단이나 하드웨어 보호 동작도 조사해야 합니다.

Q10. sfc /scannow와 DISM부터 실행하면 되나요?

시스템 파일 손상이 의심될 때는 도움이 될 수 있지만 모든 블루스크린의 만능 해결책은 아닙니다. 먼저 덤프와 이벤트를 보존하고, 시스템 파일 오류를 가리키는 근거가 있을 때 실행하는 편이 진단 순서를 흐리지 않습니다.

Q11. 여러 덤프에서 중지 코드가 모두 다르면 어떻게 하나요?

공통 기반을 우선 조사합니다. 메모리 불안정, 전원, 펌웨어, 저장장치 데이터 손상처럼 여러 코드에 영향을 줄 수 있는 요소를 기본값에서 검증합니다.

Q12. 전문가에게 무엇을 전달해야 빠르게 진단할 수 있나요?

PC 정확한 모델명, Windows 빌드, 발생 시각, 최근 변경, Stop code 사진, 이벤트 ID 1001 내용, 최근 미니덤프 3~5개, 재현 조건을 함께 전달하면 단순히 “자꾸 꺼진다”고 설명하는 것보다 효율적입니다.

마무리: 블루스크린은 ‘파일명 하나’가 아니라 반복되는 증거로 좁혀야 합니다

Windows 11 블루스크린 진단에서 가장 흔한 실수는 눈에 띄는 코드나 .sys 파일 하나를 곧바로 범인으로 확정하는 것입니다. 먼저 데이터를 보호하고, 발생 시각을 기준으로 신뢰성 기록과 이벤트 ID 1001을 맞춘 뒤, 여러 미니덤프에서 같은 패턴이 반복되는지 확인해야 합니다.

한 번에 하나만 변경하면 해결 여부뿐 아니라 원인에 대한 설명도 남습니다. 반대로 드라이버, BIOS, 레지스트리, 부품을 동시에 바꾸면 일시적으로 증상이 사라져도 무엇이 문제였는지 알 수 없습니다. 증거를 보존하고 기본 설정부터 단계적으로 확인하는 것이 가장 빠르고 안전한 길입니다.

공식 참고 자료

• Microsoft: Windows 예기치 않은 재시작 및 중지 코드 오류 해결
• Microsoft Learn: 시스템 실패 및 복구 옵션 구성
• Microsoft Learn: 소형 메모리 덤프 파일 읽기
• Microsoft Learn: 커널 모드 덤프 파일 분석
• Microsoft Learn: Bug Check 코드 참조
• Microsoft Learn: Driver Verifier를 이용한 문제 식별