윈도우11 블루스크린 원인 찾는 법｜STOP 코드·미니덤프·Kernel-Power 41 분석
- 공유 링크 만들기
- X
- 이메일
- 기타 앱
Windows 11을 사용하다 갑자기 파란 화면이 뜨고 CRITICAL_PROCESS_DIED, MEMORY_MANAGEMENT, IRQL_NOT_LESS_OR_EQUAL 같은 문구가 표시된 뒤 컴퓨터가 재부팅되는 경우가 있습니다.
문제는 인터넷에서 Stop Code를 검색하면 RAM, SSD, 그래픽카드, 드라이버, Windows까지 거의 모든 부품이 원인 후보로 나온다는 것입니다.
Windows가 남긴 발생 시간 → BugCheck Code → 덤프 파일 → 관련 드라이버를 연결해서 봐야 원인 범위를 제대로 줄일 수 있습니다.
먼저 블루스크린과 갑작스러운 재부팅을 구분하세요
컴퓨터가 갑자기 재부팅됐다고 해서 모두 블루스크린은 아닙니다.
| 증상 | 가능성 | 우선 확인 |
|---|---|---|
| 파란 화면과 STOP Code가 보임 | Windows BugCheck | STOP Code·덤프 |
| 파란 화면도 없이 즉시 꺼졌다 켜짐 | 전원·하드웨어 또는 자동 재시작된 BugCheck | Event ID 41·1001 |
| 화면이 멈춘 뒤 강제종료 | 프리징·드라이버·하드웨어 | 이벤트 로그·덤프 존재 여부 |
| 게임이나 GPU 부하 때만 재부팅 | GPU·PSU·온도·드라이버 | BugCheck 여부부터 구분 |
이 구분을 먼저 해야 Windows 문제와 전원 공급 문제를 같은 방식으로 처리하는 실수를 줄일 수 있습니다.
1. 블루스크린이 너무 빨리 사라진다면 자동 재시작부터 끄세요
Windows는 시스템 오류가 발생하면 기본 설정에 따라 자동으로 다시 시작할 수 있습니다.
그래서 실제로 블루스크린이 발생했는데도 사용자는 단순히 “컴퓨터가 갑자기 재부팅됐다”고 느낄 수 있습니다.
→ 시작 및 복구의 설정
→ 시스템 오류
→ 자동으로 다시 시작 체크 해제
Microsoft도 STOP 오류를 확인하기 어려운 경우 자동 재시작을 해제해 실제 오류 코드를 확인하도록 안내합니다.
다음 오류가 발생했을 때 STOP Code를 읽을 시간을 확보하기 위한 진단 설정입니다.
2. STOP Code를 사진으로 남기세요
다음 블루스크린이 발생하면 문구 전체를 외울 필요는 없습니다.
우선 다음 두 가지만 확보합니다.
예: MEMORY_MANAGEMENT
② 오류 코드 또는 관련 파일명이 표시되면 함께 기록
예: 0x0000001A
nvlddmkm.sys 등
Microsoft는 블루스크린을 Windows가 안전하게 계속 실행할 수 없는 상태를 감지해 시스템을 중지시키는 Bug Check라고 설명합니다.
STOP Code는 문제 범위를 알려주는 중요한 단서지만 그 자체가 항상 고장 난 부품의 이름을 의미하는 것은 아닙니다.
3. STOP Code 이름만 보고 부품을 바로 사면 안 되는 이유
예를 들어 MEMORY_MANAGEMENT라는 문구를 보면 RAM 고장이라고 생각하기 쉽습니다.
하지만 메모리를 잘못 건드린 장치 드라이버나 다른 하드웨어 문제에서도 메모리 관련 BugCheck가 나타날 수 있습니다.
반대로 VIDEO_TDR_FAILURE라고 해서 그래픽카드 자체가 반드시 고장났다는 의미도 아닙니다. 그래픽 드라이버나 GPU 상태를 함께 봐야 합니다.
| 대표 STOP Code | Microsoft BugCheck | 먼저 볼 영역 |
|---|---|---|
| MEMORY_MANAGEMENT | 0x1A | RAM·메모리 접근·드라이버 |
| IRQL_NOT_LESS_OR_EQUAL | 0xA | 드라이버·잘못된 메모리 접근 |
| DRIVER_IRQL_NOT_LESS_OR_EQUAL | 0xD1 | 커널 드라이버 |
| PAGE_FAULT_IN_NONPAGED_AREA | 0x50 | 메모리·드라이버·손상된 데이터 |
| CRITICAL_PROCESS_DIED | 0xEF | Windows 핵심 프로세스 종료 원인 |
| VIDEO_TDR_FAILURE | 0x116 | GPU·그래픽 드라이버 |
| WHEA_UNCORRECTABLE_ERROR | 0x124 | 하드웨어 오류 계층 |
| DRIVER_POWER_STATE_FAILURE | 0x9F | 절전·전원 전환·장치 드라이버 |
Microsoft의 Bug Check Reference에도 각 코드는 별도의 매개변수와 분석 절차를 가지고 있습니다.
4. 가장 먼저 신뢰성 모니터에서 발생 시간을 잡으세요
블루스크린 발생 시간을 정확히 기억하지 못한다면 이벤트 뷰어보다 먼저 신뢰성 모니터를 보는 것도 좋습니다.
Microsoft의 perfmon 명령에서 `/rel` 옵션은 Reliability Monitor를 실행합니다.
날짜별 그래프에서 빨간 X가 있는 날짜를 선택하면 다음과 같은 기록을 확인할 수 있습니다.
Windows 하드웨어 오류
응용 프로그램 실패
Windows 실패
예를 들어 NVIDIA 드라이버를 업데이트한 날부터 블루스크린이 시작됐다면 단순 우연인지 최근 변경과 연관됐는지 빠르게 비교할 수 있습니다.
5. 이벤트 뷰어에서 Kernel-Power 41만 보고 전원 고장이라고 하면 안 됩니다
블루스크린이나 갑작스러운 재부팅을 검색하면 거의 항상 등장하는 것이 Kernel-Power, Event ID 41입니다.
하지만 이 이벤트를 해석할 때 가장 많은 오해가 생깁니다.
따라서 Event 41 하나만으로 “파워서플라이 고장”이라고 결론 내릴 수 없습니다.
Event 41은 다음 상황 모두에서 나타날 수 있습니다.
PC가 멈춰 전원 버튼을 길게 눌러 강제종료
실제 전원 공급 중단
하드웨어 리셋
시스템 프리징 후 비정상 종료
Microsoft 역시 Event ID 41 자체만으로는 무엇이 발생했는지 명확히 결정하기에 정보가 충분하지 않을 수 있다고 명시합니다.
6. Event ID 1001이 있으면 훨씬 중요한 단서입니다
블루스크린으로 재부팅된 경우 System 로그에 다음 이벤트가 남는 경우가 있습니다.
Microsoft의 예상치 못한 재부팅 진단 자료에서도 Event ID 1001은 BugCheck 코드와 생성된 덤프 파일 경로를 확인할 수 있는 중요한 기록으로 제시됩니다.
Event 41만 있음 → 비정상 종료가 있었다는 사실
Event 1001 + BugCheck → Windows Stop Error가 발생했다는 강한 증거
Dump 파일까지 존재 → 실제 충돌 내용을 추가 분석 가능
7. Event 41의 BugcheckCode가 0인지 아닌지도 봅니다
Event ID 41의 세부 정보에는 경우에 따라 다음 항목이 있습니다.
Microsoft 공식 예제에서는 BugcheckCode가 159로 기록돼 있고, 이를 16진수로 변환하면 0x9F, 즉 DRIVER_POWER_STATE_FAILURE가 됩니다.
주의할 점은 이 값이 우리가 흔히 보는 `0x9F`가 아니라 10진수로 기록될 수 있다는 것입니다.
PowerShell에서 변환하려면:
결과:
Microsoft는 BugCheck 정보를 기록하지 못한 전원 차단, 강제종료 또는 기타 비정상 종료 상황에서도 0이 나타날 수 있다고 설명합니다.
8. Minidump 파일이 있는지 확인하세요
Windows가 블루스크린 당시 작은 메모리 덤프를 생성했다면 보통 다음 폴더에 저장됩니다.
실제 환경에서는:
형태로 보는 것이 정확합니다.
파일 이름은 날짜가 포함된 `.dmp` 형식으로 생성됩니다.
Microsoft에 따르면 Small Memory Dump에는 다음과 같은 정보가 포함될 수 있습니다.
충돌 당시 프로세서 정보
충돌한 프로세스·스레드 정보
커널 호출 스택
로드된 드라이버 목록
즉 블루스크린 화면이 사라져도 덤프 파일이 남아 있다면 사후 분석이 가능합니다.
9. Minidump가 하나도 없다면 덤프 설정을 확인
블루스크린이 반복되는데 `C:\Windows\Minidump`가 계속 비어 있다면 덤프 생성 설정을 확인합니다.
→ 시작 및 복구
→ 설정
→ 디버깅 정보 쓰기
일반적인 진단에는 자동 메모리 덤프를 사용할 수 있습니다.
Microsoft의 최근 Stop Code 문제 해결 문서 역시 덤프 수집을 위해 Startup and Recovery에서 Automatic memory dump를 선택하도록 안내합니다.
Automatic Memory Dump의 기본 위치는:
입니다.
10. 덤프 생성에는 페이지 파일도 관계가 있습니다
이 부분은 일반적인 블루스크린 글에서 많이 빠집니다.
덤프를 생성하려면 Windows가 충돌 정보를 기록할 환경이 필요하며, 페이지 파일(Page File) 설정도 관계가 있습니다.
Microsoft는 Automatic Memory Dump가 System managed page file과 연동해 필요한 덤프를 확보하도록 설계돼 있다고 설명합니다.
11. WinDbg로 Minidump를 직접 열 수 있습니다
`.dmp` 파일은 메모장으로 열어봐도 의미 있는 정보를 보기 어렵습니다.
Microsoft가 제공하는 공식 분석 프로그램이 WinDbg입니다.
Windows 11에서는 터미널에서 다음 명령으로 설치할 수도 있습니다.
Microsoft는 현재 WinDbg가 Windows 11을 지원하며 크래시 덤프 분석에 사용할 수 있다고 안내합니다.
12. WinDbg에서 무엇을 봐야 할까?
WinDbg에서 덤프를 연 뒤 우선 다음 명령을 실행합니다.
Microsoft의 공식 디버깅 문서에서도 덤프 분석의 기본 단계로 `!analyze -v`를 사용합니다.
결과가 매우 길지만 처음부터 모두 이해할 필요는 없습니다.
우선 아래 항목을 찾습니다.
BUGCHECK_P1 ~ P4
MODULE_NAME
IMAGE_NAME
FAILURE_BUCKET_ID
STACK_TEXT
13. IMAGE_NAME에 .sys 파일이 나오면 어떻게 볼까?
예를 들어 분석 결과에서 다음과 같은 파일이 표시됐다고 가정해보겠습니다.
`nvlddmkm.sys`는 NVIDIA 그래픽 드라이버 계열 파일입니다.
그러면 진단 방향을 Windows 전체에서 NVIDIA 그래픽 드라이버·GPU 계층으로 크게 좁힐 수 있습니다.
다른 예:
| 덤프에서 보이는 파일 예 | 관련 영역 |
|---|---|
| nvlddmkm.sys | NVIDIA 그래픽 |
| amdkmdag.sys | AMD 그래픽 |
| iaStor*.sys | Intel 저장장치 계층 |
| Netwtw*.sys | 일부 Intel Wi-Fi 드라이버 |
| ntfs.sys | Windows NTFS 파일 시스템 계층 |
충돌 당시 피해를 받은 Windows 구성요소가 스택에 표시되는 경우도 있기 때문입니다.
반복되는 여러 덤프에서 같은 제3자 드라이버가 계속 등장하는지가 훨씬 중요한 단서입니다.
14. 같은 STOP Code가 반복되는지, 매번 달라지는지도 중요합니다
블루스크린이 여러 번 발생했다면 덤프 파일 하나만 보지 말고 최근 파일 여러 개를 비교합니다.
| 패턴 | 의심 방향 |
|---|---|
| 항상 같은 STOP Code + 같은 드라이버 | 특정 드라이버·장치 가능성 상승 |
| STOP Code는 달라도 같은 .sys가 반복 | 해당 드라이버 계층 확인 가치 큼 |
| 매번 STOP Code와 모듈이 제각각 | RAM·불안정한 하드웨어·오버클럭 등도 고려 |
| 덤프 없이 전원만 즉시 끊김 | 전원·하드웨어 계층 조사 비중 증가 |
특히 여러 덤프가 전혀 다른 위치에서 무작위 메모리 오류를 보인다면 소프트웨어 하나만의 문제보다 RAM 안정성을 확인할 이유가 커집니다.
15. RAM을 의심할 조건
MEMORY_MANAGEMENT가 떴다고 바로 RAM을 교체하기보다 다음 조건이 같이 있는지 확인합니다.
서로 다른 드라이버에서 메모리 오류가 반복됨
RAM 증설·교체 후부터 시작됨
XMP·EXPO 적용 후 발생함
고부하에서만 발생 빈도가 증가함
이 경우 Windows 메모리 진단이나 별도의 메모리 안정성 검사를 진행할 가치가 있습니다.
특히 XMP·EXPO나 CPU·RAM 오버클럭을 사용 중이라면 먼저 기본 설정으로 되돌린 상태에서 재현 여부를 확인하는 것이 좋습니다.
16. 그래픽카드를 의심할 조건
VIDEO_TDR_FAILURE / 0x116 반복
nvlddmkm.sys 또는 AMD 그래픽 드라이버가 반복 등장
드라이버 업데이트 직후부터 발생
화면 깨짐·검은 화면 증상이 함께 나타남
이 경우에는 무조건 최신 드라이버만 설치하기보다 문제가 시작된 시점을 보는 것이 중요합니다.
새 드라이버 설치 직후 시작됐다면 Microsoft의 Stop Code 문제 해결 가이드처럼 문제가 없던 이전 드라이버로 Roll Back하는 것도 진단 방법이 됩니다.
17. SSD나 저장장치를 의심할 조건
다음과 같은 증상이 함께 있다면 저장장치 계층도 봅니다.
Windows 부팅 자체가 불안정함
NTFS 관련 오류가 반복됨
CRITICAL_PROCESS_DIED와 디스크 오류가 같이 발생
저장장치가 BIOS에서 간헐적으로 사라짐
이 경우에는 단순히 `sfc /scannow`만 반복하는 것보다 SSD 상태, 연결, 펌웨어, Windows System 로그의 디스크 관련 이벤트를 함께 확인하는 것이 좋습니다.
18. Kernel-Power 41 + BugcheckCode 0이면 어디를 봐야 하나?
블루스크린 기록도 없고 덤프도 없으며 Event ID 41의 BugcheckCode가 0이라면 진단 방향이 달라집니다.
멀티탭·전원 케이블
CPU·GPU 과열
메인보드
RAM 불안정
오버클럭·언더볼팅
노트북 배터리·전원 어댑터
Microsoft도 Event ID 41에서 BugCheck 정보가 없는 경우 전원 공급 중단이나 하드웨어 계층을 조사 대상으로 안내합니다.
단 이것도 “Event 41 = 파워 불량”이라는 뜻은 아닙니다.
19. sfc /scannow와 DISM은 언제 쓰는가?
블루스크린 글마다 가장 먼저 등장하는 명령어지만 모든 BugCheck를 해결하는 만능 명령은 아닙니다.
Windows 시스템 파일 손상이 의심될 때 다음 명령을 사용할 수 있습니다.
완료 후:
하지만 덤프에서 NVIDIA 드라이버가 반복적으로 확인되거나 실제 RAM 불량이 있는 상황에서 SFC만 계속 실행하는 것은 진단 방향이 맞지 않습니다.
20. 바로 Windows를 포맷하면 안 되는 이유
클린 설치는 강력한 소프트웨어 초기화 방법이지만 원인을 찾기 전에 실행하면 중요한 증거도 함께 사라질 수 있습니다.
STOP Code 사진
Minidump 파일
Event ID 1001 내용
Event ID 41 세부 정보
최근 설치·업데이트 내역
특히 Windows를 새로 설치해도 같은 블루스크린이 그대로 발생한다면 하드웨어나 펌웨어 쪽 가능성을 판단하는 데도 중요한 정보가 됩니다.
블루스크린 진단을 이 순서로 하면 됩니다
↓
2. STOP Code 사진 저장
↓
3. perfmon /rel로 정확한 발생 시각 확인
↓
4. 이벤트 뷰어에서 Event 1001·41 확인
↓
5. C:\Windows\Minidump 확인
↓
6. WinDbg에서 !analyze -v 실행
↓
7. 반복되는 BugCheck·IMAGE_NAME 비교
↓
8. 드라이버 / RAM / GPU / SSD / 전원 중 범위 축소
↓
9. 원인 후보에 맞는 조치만 실행
증상별로 가장 먼저 볼 곳
| 증상 | 먼저 확인 | 이유 |
|---|---|---|
| 블루스크린 문구가 보임 | STOP Code·Minidump | BugCheck 증거 존재 |
| 너무 빨리 재부팅됨 | 자동 재시작 해제 | STOP Code 확보 |
| Event 41만 보임 | 1001·BugcheckCode 확인 | 41 자체는 원인이 아님 |
| 1001 + dump 경로 존재 | WinDbg | BugCheck 분석 가능 |
| 같은 .sys가 반복됨 | 해당 드라이버·장치 | 공통점 존재 |
| STOP Code가 계속 바뀜 | RAM·하드웨어 안정성 | 랜덤 메모리 손상 가능성 |
| 게임 때만 재부팅 | GPU·드라이버·PSU·온도 | 부하 의존 패턴 |
| 덤프 없이 바로 전원 차단 | 전원·하드웨어 | Windows가 dump를 남기지 못함 |
핵심은 '오류 코드'가 아니라 반복되는 공통점입니다
최근 5개의 Minidump에서 같은 NVIDIA 드라이버가 반복되는지,
STOP Code가 매번 제각각인데 메모리 손상 패턴이 반복되는지,
아예 Dump 없이 전원이 순간적으로 끊기는지를 비교해야 합니다.
그래야 해결책도 달라집니다.
드라이버 문제라면 드라이버를 조치하고, RAM 안정성 문제라면 메모리를 검사하고, 전원 문제라면 PSU와 전원 계통을 봐야 합니다.
처음부터 Windows 초기화·BIOS 업데이트·RAM 교체를 모두 해보는 방식보다 훨씬 효율적입니다.
Microsoft Learn - Bug Checks (Stop Code Errors)
Microsoft Learn - Bug Check Code Reference
Microsoft Learn - Stop code error or bug check troubleshooting
Microsoft Learn - Event ID 41 unexpected restart troubleshooting
Microsoft Learn - Unexpected reboot event log analysis
Microsoft Learn - Read small memory dump files
Microsoft Learn - Automatic Memory Dump
Microsoft Learn - Install WinDbg
Microsoft Learn - !analyze debugger command
Microsoft Learn - perfmon /rel Reliability Monitor
핵심 공식 내용:
Event ID 41은 정상 종료 없이 다시 시작됐음을 나타내는 기록이며 원인을 단독으로 확정하지 않음
Event ID 1001에서 BugCheck와 dump 경로를 확인할 수 있음
Small Dump 기본 경로는 %SystemRoot%\Minidump
Automatic Memory Dump 기본 경로는 %SystemRoot%\MEMORY.DMP
WinDbg의 !analyze -v로 자세한 BugCheck 분석 가능
perfmon /rel 명령으로 Reliability Monitor 실행 가능
확인일: 2026년 9월 1일
- 공유 링크 만들기
- X
- 이메일
- 기타 앱