Windows 11에서 블루스크린이 반복될 때 — 미니덤프·이벤트 뷰어·WinDbg로 원인 찾기

Windows 11에서 블루스크린이 반복되면 MEMORY_MANAGEMENT, PAGE_FAULT_IN_NONPAGED_AREA, DRIVER_IRQL_NOT_LESS_OR_EQUAL 같은 Stop Code가 나타날 수 있습니다.

다만 Stop Code 하나만으로 실제 원인을 확정하기는 어렵습니다. 드라이버, 메모리, 저장장치, Windows 업데이트, BIOS·펌웨어 등 여러 원인이 같은 형태의 블루스크린을 일으킬 수 있기 때문입니다.

처음부터 모든 드라이버를 업데이트하거나 SFC·DISM·CHKDSK를 차례로 실행하기보다 Windows가 남긴 이벤트 로그와 Crash Dump를 먼저 확인하는 편이 좋습니다.

전체 흐름은 아래와 같습니다.

블루스크린 발생 시간 기록
↓
Event Viewer에서 BugCheck 확인
↓
Minidump 확인
↓
WinDbg에서 !analyze -v 실행
↓
반복되는 Driver·Module 확인
↓
최근 변경 사항과 비교
↓
필요한 부분만 수정 후 재검증

먼저 확인할 내용

확인 기준 환경

Windows 11 25H2
Windows Event Viewer
Small Memory Dump 또는 Kernel/Automatic Dump
Microsoft WinDbg

Windows 11 25H2는 이 글의 확인 기준 OS입니다. 아래의 모든 블루스크린 유형을 같은 환경에서 직접 재현했다는 뜻은 아닙니다.

대표 증상

Windows 11에서 BSOD가 반복됨
블루스크린 직후 자동으로 재부팅됨
특정 게임이나 프로그램 실행 중 발생
절전 모드 복귀 후 발생
드라이버 또는 Windows Update 이후 시작됨
Event Viewer에 Event ID 1001이 기록됨
C:\Windows\Minidump에 .dmp가 생성됨
WinDbg에서 특정 .sys 파일이 반복해서 나타남

1. 블루스크린 발생 시간과 Stop Code 기록

블루스크린이 나타나면 가능한 한 Stop Code와 발생 시간을 기록합니다.

예:

DRIVER_IRQL_NOT_LESS_OR_EQUAL

2026-08-28 09:15경

화면에 exampledriver.sys 같은 파일 이름이 표시된다면 함께 기록합니다.

다만 파일 이름 하나만으로 해당 드라이버를 원인으로 확정해서는 안 됩니다. Crash Dump의 BugCheck 정보와 여러 차례의 반복 패턴까지 확인해야 합니다.

2. 이벤트 뷰어에서 BugCheck 확인

Win + R에서 다음을 실행합니다.

eventvwr.msc

다음 위치로 이동합니다.

Windows 로그 → 시스템

블루스크린 전후에는 다음 이벤트를 주로 확인합니다.

Event ID 1001 — WER-SystemErrorReporting
Event ID 41 — Kernel-Power
Event ID 6008 — EventLog

여기서 중요한 점은 Event ID 41 자체가 원인은 아니라는 것입니다.

Event ID 41은 Windows가 정상 종료 절차를 거치지 않은 채 다시 시작됐다는 사실을 보여줍니다. 블루스크린뿐 아니라 전원 차단이나 강제 재부팅 때도 발생할 수 있습니다.

실제 BugCheck가 기록됐다면 Event ID 1001에서 다음 정보를 확인할 수 있습니다.

BugCheck Code
BugCheck Parameter
Dump 파일 경로
Report ID

최근 관련 이벤트를 PowerShell에서 한 번에 확인하려면 다음 명령을 사용합니다.

$StartTime = (Get-Date).AddDays(-7)

Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 41, 1001, 6008
    StartTime = $StartTime
} |
Sort-Object TimeCreated -Descending |
Select-Object TimeCreated, Id, ProviderName, Message |
Format-List

3. Minidump가 생성됐는지 확인

Small Memory Dump를 사용한다면 보통 다음 경로에서 확인할 수 있습니다.

C:\Windows\Minidump

최근 Dump를 PowerShell에서 확인하려면 다음을 실행합니다.

Get-ChildItem "$env:SystemRoot\Minidump\*.dmp" -ErrorAction SilentlyContinue |
Sort-Object LastWriteTime -Descending |
Select-Object -First 5 Name, LastWriteTime, Length

블루스크린 발생 시간과 가까운 파일을 찾습니다.

Small Memory Dump에 전체 RAM이 저장되지는 않지만, 다음 분석 정보가 포함될 수 있습니다.

BugCheck Code와 Parameter
로드된 Driver
충돌 Thread 정보
Kernel Call Stack

BSOD가 반복된다면 가장 최근 Dump 하나만 보지 말고 3~5개 Dump에서 같은 Driver나 BugCheck가 반복되는지 비교하는 것이 좋습니다.

4. Dump가 없다면 설정 확인

블루스크린이 발생했는데 C:\Windows\Minidump가 비어 있다면 다음을 실행합니다.

sysdm.cpl

고급 → 시작 및 복구 → 설정

에서 디버깅 정보 쓰기 항목을 확인합니다.

Windows는 환경에 따라 Small, Kernel, Automatic Memory Dump 등을 사용할 수 있습니다.

이미 Kernel 또는 Automatic Dump가 정상적으로 생성된다면 굳이 Small Dump로 바꿀 필요는 없습니다.

Small Dump가 아니라 다음 파일이 생성되어 있을 수도 있습니다.

C:\Windows\MEMORY.DMP

Dump 생성에는 Page File 설정도 영향을 줄 수 있습니다. 성능 최적화를 이유로 Page File을 임의로 비활성화한 환경이라면 이 설정도 확인합니다.

5. WinDbg에서 Dump 분석

Microsoft WinDbg가 설치되어 있다면 최근 .dmp 파일을 엽니다.

WinDbg에서:

File → Open dump file

을 선택합니다.

Symbol 관련 문제가 있다면 Command 창에서 다음을 실행합니다.

.symfix
.reload

그다음 가장 먼저 다음 명령을 실행합니다.

!analyze -v

출력 전체를 처음부터 모두 이해할 필요는 없습니다.

우선 다음 항목을 확인합니다.

BugCheck
Arguments
MODULE_NAME
IMAGE_NAME
STACK_TEXT

BugCheck와 Parameter만 다시 보려면 다음을 실행합니다.

.bugcheck

를 사용할 수 있습니다.

6. Driver 이름 하나만으로 원인을 확정하지 않기

분석 결과에 다음과 같이 특정 Driver가 나타날 수 있습니다.

MODULE_NAME: exampledriver

IMAGE_NAME: exampledriver.sys

이 결과는 중요한 단서지만 해당 Driver가 100% 원인이라는 뜻은 아닙니다.

Crash 시점에 해당 Module에서 문제가 발견됐을 뿐, 다른 Driver가 먼저 메모리를 손상시킨 경우도 있습니다.

특히 다음과 같은 Windows 공통 Module이 나타났다고 해서 Windows Kernel 자체가 고장 났다고 바로 판단해서는 안 됩니다.

ntoskrnl.exe

의심되는 Driver 정보를 더 확인하려면 다음을 실행합니다.

lmvm exampledriver

를 사용할 수 있습니다.

Call Stack은 다음 명령으로 확인합니다.

가장 중요한 것은 같은 Driver가 여러 Dump에서 반복되는지입니다.

7. 반복되는 패턴과 최근 변경 사항 비교

예를 들어 다음 패턴이 확인됐다고 가정합니다.

그래픽 Driver 업데이트

↓

그날부터 블루스크린 시작

↓

최근 세 개 Dump에서 같은 그래픽 Driver 반복

이 정도 정보가 맞아떨어지면 해당 Driver를 우선 조사할 근거가 생깁니다.

상황에 따라:

제조사의 안정적인 최신 Driver로 업데이트
문제가 시작되기 전 버전으로 롤백

같은 조치를 검토합니다.

반대로 여러 Dump에서 매번 서로 다른 Driver와 Memory 관련 BugCheck가 나타난다면 조사 범위를 넓혀야 합니다.

예를 들면 다음과 같습니다.

RAM
CPU·메모리 오버클럭
BIOS·UEFI
Storage
전원
여러 Kernel Driver 간 충돌

등입니다.

다만 Dump를 분석하기 전부터 하드웨어 문제로 단정해서는 안 됩니다.

8. Stop Code가 너무 빨리 사라진다면

블루스크린이 나타난 직후 바로 재부팅되어 Stop Code를 읽기 어렵다면:

sysdm.cpl

을 실행하고:

고급 → 시작 및 복구 → 설정

에서 자동으로 다시 시작 설정을 확인합니다.

진단 기간에는 자동 재시작을 해제하면 블루스크린 화면을 직접 확인하기 쉽습니다.

업무용 또는 원격 시스템에서는 자동 재부팅 정책을 변경하면 운영에 영향을 줄 수 있으므로 주의해야 합니다.

9. SFC·DISM을 무조건 먼저 실행하지 않기

다음 명령들은 Windows 시스템 파일 복구에는 유용합니다.

sfc /scannow

DISM /Online /Cleanup-Image /RestoreHealth

다만 모든 블루스크린을 해결하는 범용 명령은 아닙니다.

Dump에서 특정 Third-party Driver가 반복해서 나타난다면 해당 Driver를 먼저 확인하는 편이 더 직접적입니다.

저장장치 관련 근거가 없는 상태에서 chkdsk /f를 습관적으로 실행할 필요도 없습니다.

로그와 Dump에서 근거가 나온 영역부터 확인하는 것이 핵심입니다.

10. Driver Verifier는 첫 단계로 사용하지 않기

Windows의 Driver Verifier는 Driver 문제를 찾는 강력한 도구입니다. 다만 의도적으로 Driver에 추가 검사를 적용하고 새로운 BugCheck를 발생시킬 수 있습니다.

설정을 잘못 사용하면 부팅 문제가 더 심해질 수도 있습니다.

일반적인 BSOD 진단에서는 먼저 다음 순서로 진행합니다.

Event Viewer

↓

Crash Dump

↓

WinDbg

↓

반복 Driver 확인

순서로 진행합니다.

Driver Verifier는 이 단계에서도 원인을 찾기 어렵고, 사용 목적과 복구 방법을 충분히 이해했을 때 별도로 검토하는 편이 좋습니다.

11. 수정 후 같은 조건으로 재검증

Driver를 업데이트하거나 롤백했다면 기존에 BSOD가 발생했던 작업을 다시 재현합니다.

예를 들어:

특정 게임 실행
절전 모드 복귀
USB 장치 연결
GPU 고부하 작업
대용량 파일 복사

등입니다.

이후에는 다음 세 가지를 확인합니다.

같은 Stop Code가 다시 발생하는가

새로운 Dump가 생성되는가

같은 Driver가 다시 나타나는가

PC가 한 번 정상적으로 부팅됐다고 해서 해결됐다고 판단해서는 안 됩니다.

해결되지 않는 경우

추가 분석이 필요하다면 다음 정보를 정리해 둡니다.

Windows 11 버전과 OS Build
BSOD 발생 시간
당시 수행하던 작업
Stop Code
Event ID 1001
BugCheck Code와 Parameter
Dump 파일 경로
최근 Minidump 3~5개
WinDbg !analyze -v 결과
MODULE_NAME
IMAGE_NAME
최근 Driver 업데이트
최근 Windows Update
BIOS·UEFI 변경
새로운 하드웨어
오버클럭 여부

이 정도 정보가 있으면 단순히 “블루스크린이 계속 발생한다”는 설명보다 실제 원인을 훨씬 정확하게 좁힐 수 있습니다.

주의사항

Event ID 41을 실제 원인으로 단정하지 않기
Stop Code 하나만 보고 해결 방법을 결정하지 않기
ntoskrnl.exe가 보인다고 Windows Kernel 자체를 원인으로 판단하지 않기
WinDbg 결과 하나만 보고 Driver를 즉시 삭제하지 않기
가능하면 여러 Dump의 반복 패턴 확인하기
모든 Driver를 한꺼번에 업데이트하지 않기
BIOS 업데이트를 첫 번째 해결 방법으로 사용하지 않기
Driver Verifier를 일반적인 첫 진단 단계로 사용하지 않기
Dump 파일을 공개 서비스에 무분별하게 공유하지 않기
수정 후 기존 BSOD 발생 조건으로 다시 확인하기

마무리

Windows 11에서 블루스크린이 반복될 때 중요한 것은 여러 복구 명령을 한꺼번에 실행하는 일이 아니라 Windows가 남긴 Crash 정보를 먼저 확인하는 것입니다.

전체 흐름은 아래와 같습니다.

Stop Code와 발생 시간 기록
↓
Event ID 1001 확인
↓
Minidump 확인
↓
WinDbg에서 !analyze -v 실행
↓
Module과 Stack 확인
↓
여러 Dump의 반복 패턴 비교
↓
최근 Driver·Update 변경과 연결
↓
필요한 부분만 수정
↓
같은 조건으로 재검증

특히 Kernel-Power Event ID 41은 정상 종료 없이 시스템이 다시 시작됐다는 사실을 보여줄 뿐, 실제 원인을 알려주는 이벤트는 아닙니다.

BSOD가 반복된다면 Event ID 1001, Crash Dump, WinDbg 결과를 함께 보는 일이 훨씬 중요합니다.

참고 자료

Microsoft Learn — Stop code error or bug check troubleshooting
Windows Stop Error와 Crash Dump 기반 문제 해결 절차
https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/stop-code-error-troubleshooting

Microsoft Learn — Read small memory dump files
Small Memory Dump의 저장 위치와 포함 정보
https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/read-small-memory-dump-file

Microsoft Learn — Advanced troubleshooting for Event ID 41
Kernel-Power Event ID 41의 의미와 비정상 재부팅 진단
https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/event-id-41-restart

Microsoft Learn — Configure system failure and recovery options
자동 재시작 및 Memory Dump 설정 방법
https://learn.microsoft.com/ko-kr/troubleshoot/windows-client/performance/configure-system-failure-and-recovery-options

Microsoft Learn — Analyze a kernel-mode dump file by using WinDbg
WinDbg에서 Kernel Crash Dump를 분석하는 방법
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/analyzing-a-kernel-mode-dump-file-with-windbg

Microsoft Learn — !analyze
WinDbg의 !analyze -v 명령 설명
https://learn.microsoft.com/ko-kr/windows-hardware/drivers/debuggercmds/-analyze

Microsoft Learn — lm (List Loaded Modules)
lmvm으로 Driver와 Module 정보를 확인하는 방법
https://learn.microsoft.com/ko-kr/windows-hardware/drivers/debuggercmds/lm–list-loaded-modules-

Post Views: 20