컴퓨터를 사용하다가 경고 없이 화면이 꺼지고 다시 켜지면 이벤트 뷰어에서 Kernel-Power 41이 발견되는 경우가 많습니다. 여기서 흔히 하는 실수가 “41번 오류가 떴으니 파워서플라이가 고장 났다”고 단정하는 것입니다.

하지만 Kernel-Power 41은 고장 부품의 이름이 아닙니다. Windows가 다음 부팅 과정에서 직전 종료가 정상 절차를 거치지 않았다는 사실을 기록한 결과 이벤트입니다. 블루스크린, 순간적인 전원 차단, 강제 종료, 시스템 멈춤, 과열, 메모리 오류가 모두 같은 41번 기록으로 남을 수 있습니다.

따라서 해결의 핵심은 41번을 없애는 것이 아니라 다음 네 가지 증거를 같은 시간축에서 비교하는 것입니다.

1. 재부팅 직전에 블루스크린이 있었는가
2. Event ID 41의 BugcheckCode와 PowerButtonTimestamp 값은 무엇인가
3. 같은 시각 전후로 WHEA-Logger·Display·Disk·volmgr 이벤트가 있었는가
4. C:\Windows\Minidump 또는 C:\Windows\MEMORY.DMP가 생성되었는가

이 글에서는 Windows를 초기화하거나 부품부터 교체하지 않고, 남아 있는 증거를 통해 소프트웨어 충돌과 전원·발열·메모리·저장장치 문제를 구분하는 순서를 설명합니다.

먼저 결론부터: Kernel-Power 41은 원인이 아니라 결과입니다

Microsoft는 Event ID 41만으로는 발생 원인을 명확하게 규정하기에 정보가 부족할 수 있다고 설명합니다. 41번 이벤트는 예상치 못한 종료가 있었다는 출발점이며, 실제 판단은 내부 데이터와 인접 이벤트를 함께 봐야 합니다.

중요한 점은 “가능성”과 “확정”을 구분하는 것입니다. 예를 들어 BugcheckCode=0은 전원 문제와 잘 맞지만, 그것만으로 PSU 불량이 확정되지는 않습니다. 시스템이 너무 빨리 꺼졌거나 저장장치에 덤프를 쓰지 못해도 값이 0으로 남을 수 있습니다.

진단 전에 하면 안 되는 행동

• 원인을 기록하기 전에 Windows 초기화부터 하지 않습니다.
• BIOS 업데이트 도중 전원을 차단하지 않습니다.
• 노트북을 임의로 분해하거나 배터리 단자를 만지지 않습니다.
• 검증되지 않은 드라이버 업데이트 프로그램을 사용하지 않습니다.
• 이벤트 41 하나만 보고 파워서플라이·메인보드·RAM을 한꺼번에 구매하지 않습니다.
• 출처가 불분명한 레지스트리 파일로 덤프 설정을 변경하지 않습니다.
• 재현 조건을 확인하려고 과도한 CPU·GPU 스트레스 테스트를 장시간 반복하지 않습니다.

재부팅이 반복되는 PC에는 저장되지 않은 문서와 브라우저 데이터가 손상될 수 있습니다. 원인 조사 전에 중요한 파일을 외장 저장장치나 신뢰할 수 있는 클라우드에 복사하되, 고장 가능성이 있는 원본 드라이브에만 백업을 두지 않는 편이 안전합니다.

1단계: 재부팅 장면부터 분류합니다

로그보다 먼저 사용자가 본 현상을 기록해야 합니다. 같은 Kernel-Power 41이라도 화면 모습과 재부팅 조건이 다르면 조사 방향이 달라집니다.

발생 시각도 분 단위로 적어 둡니다. “어제 저녁쯤”이 아니라 20:43, 게임 실행 7분 후처럼 기록해야 이벤트 뷰어의 앞뒤 로그와 맞출 수 있습니다.

2단계: 이벤트 뷰어에서 41번의 내부 값을 확인합니다

1. Windows 키 + R을 누릅니다.
2. eventvwr.msc를 입력하고 확인합니다.
3. Windows 로그 → 시스템으로 이동합니다.
4. 오른쪽에서 현재 로그 필터링을 누릅니다.
5. 이벤트 ID에 41,6008,1074,6006,46을 입력합니다.
6. 재부팅 시각의 Kernel-Power 41을 더블클릭합니다.
7. 자세히 → XML 보기를 선택합니다.

여기서 최소한 다음 값을 메모합니다.

BugcheckCode
BugcheckParameter1
BugcheckParameter2
BugcheckParameter3
BugcheckParameter4
PowerButtonTimestamp
SleepInProgress

BugcheckCode 해석 시 주의점

Event ID 41의 BugcheckCode는 10진수로 기록될 수 있지만, Microsoft의 Stop code 문서는 대개 16진수를 사용합니다. 예를 들어 10진수 159는 16진수 9F, 즉 0x0000009F로 변환됩니다.

Windows 계산기에서 프로그래머 모드 → DEC 선택 → 숫자 입력 → HEX 값 확인 순서로 변환하면 됩니다. 숫자를 그대로 검색해 다른 오류와 혼동하지 않아야 합니다.

PowerButtonTimestamp 해석

이 값이 0이 아니면 전원 버튼을 길게 눌러 강제 종료한 정황과 관련될 수 있습니다. 그러나 여기서도 “사용자 실수”라고 끝내면 안 됩니다. 컴퓨터가 먼저 멈췄기 때문에 사용자가 강제 종료했을 수 있으므로, 강제 종료 직전의 Display·Disk·스토리지·응용 프로그램 멈춤 로그를 조사해야 합니다.

3단계: 41번 앞의 5분을 조사합니다

41번은 다음 부팅 때 기록되므로, 진짜 단서는 그보다 앞선 시각에 있을 가능성이 큽니다. 시스템 로그를 시간순으로 정렬하고 재부팅 직전 약 5분 범위를 봅니다.

경고가 많다는 이유만으로 모두 원인은 아닙니다. 재부팅과 무관하게 매일 반복되던 로그보다, 문제 발생 시각에 새로 나타나거나 빈도가 급증한 이벤트가 더 중요합니다.

4단계: PowerShell로 재부팅 전후 로그를 한 번에 추출합니다

이벤트 뷰어에서 수동으로 찾기 어렵다면 관리자 권한이 아닌 일반 PowerShell에서도 읽기 가능한 범위의 시스템 이벤트를 추출할 수 있습니다.

$start = (Get-Date).AddDays(-7)
Get-WinEvent -FilterHashtable @{
    LogName='System'
    StartTime=$start
    Id=41,46,1074,6006,6008
} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
    Sort-Object TimeCreated -Descending

목적: 최근 7일간 종료·재부팅·덤프 관련 사건을 같은 목록에서 비교합니다.

결과 해석: 1074 뒤에 재부팅됐다면 앱·사용자·업데이트의 정상 요청일 수 있습니다. 41과 6008만 있고 1074가 없다면 비정상 종료 쪽에 무게가 실립니다. 46이 함께 있으면 덤프 설정과 페이지 파일을 확인합니다.

주의: 이 명령은 로그를 읽기만 하며 삭제하지 않습니다. 출력이 없다고 문제가 없다는 뜻은 아니며, 로그 보존 기간이 짧거나 해당 이벤트가 기록되지 않았을 수 있습니다.

WHEA 이벤트만 별도로 확인하려면 다음 명령을 사용합니다.

Get-WinEvent -FilterHashtable @{
    LogName='System'
    ProviderName='Microsoft-Windows-WHEA-Logger'
    StartTime=(Get-Date).AddDays(-30)
} | Select-Object TimeCreated, Id, LevelDisplayName, Message

Microsoft 문서에 따르면 WHEA는 하드웨어 오류가 발생할 때 ETW 이벤트를 만들고 시스템 이벤트 로그에 기록합니다. 다만 corrected error는 하드웨어가 오류를 감지하고 수정했다는 의미일 수 있으므로, 이벤트 하나만으로 즉시 부품 불량을 확정하지 않습니다. 동일 장치·동일 경로에서 반복되고 실제 재부팅 시각과 일치하는지를 봐야 합니다.

5단계: 덤프 파일 유무로 ‘Windows가 오류를 포착했는지’ 확인합니다

다음 두 위치를 확인합니다.

C:\Windows\Minidump
C:\Windows\MEMORY.DMP

재부팅 시각과 같은 날짜의 .dmp 파일이 있으면 Windows가 Stop 오류를 포착하고 메모리 상태 일부를 저장했다는 뜻입니다. 반대로 덤프가 없다고 블루스크린이 아니었다고 단정할 수는 없습니다. 전원이 너무 빨리 끊기거나, 페이지 파일·저장공간·덤프 설정 문제로 파일 작성에 실패할 수 있기 때문입니다.

다음 재발에 대비한 덤프 설정

1. Windows 키 + R → sysdm.cpl을 실행합니다.
2. 고급 → 시작 및 복구 → 설정으로 이동합니다.
3. 디버깅 정보 쓰기를 자동 메모리 덤프 또는 상황에 따라 작은 메모리 덤프로 설정합니다.
4. 작은 덤프 디렉터리가 %SystemRoot%\Minidump인지 확인합니다.
5. 블루스크린을 읽을 시간이 필요하면 자동으로 다시 시작을 일시적으로 해제합니다.

Microsoft는 작은 메모리 덤프에 Stop 메시지와 매개변수, 로드된 드라이버, 중지 스레드의 커널 호출 스택 등이 포함된다고 설명합니다. 하지만 작은 덤프는 정보량이 제한되어 실제 원인이 당시 실행 스레드와 직접 연결되지 않았다면 분석이 어려울 수 있습니다.

완전 메모리 덤프는 개인정보·암호화 키·열려 있던 문서 내용 등 메모리의 민감한 데이터가 포함될 수 있고 용량도 매우 큽니다. 일반 사용자가 무조건 설정할 항목이 아니며, Microsoft 역시 커널·전체 덤프 생성은 표준 진단을 마친 뒤 지원 엔지니어의 요청에 따라 신중히 사용하도록 안내합니다.

6단계: Minidump를 WinDbg로 읽을 때 봐야 할 항목

Microsoft Store 또는 Windows SDK 경로를 통해 Microsoft WinDbg를 설치한 뒤 덤프를 열 수 있습니다. 덤프를 연 다음 분석 창에서 다음 명령을 사용합니다.

!analyze -v

확인할 핵심은 다음과 같습니다.

• BUGCHECK_CODE: Stop 오류 분류
• MODULE_NAME: 분석에서 지목된 모듈
• IMAGE_NAME: 관련 드라이버 이미지
• FAILURE_BUCKET_ID: 유사 충돌을 묶는 식별자
• STACK_TEXT: 충돌 직전 호출 흐름

ntoskrnl.exe가 표시됐다고 Windows 커널 자체가 범인이라는 뜻은 아닙니다. 커널은 충돌을 최종 감지한 위치로 자주 등장합니다. 제3자 드라이버 이름, 반복되는 동일 모듈, Bugcheck 매개변수, 당시 사용 장치가 함께 일치해야 의미가 커집니다.

덤프 파일은 개인 데이터가 포함될 수 있으므로 공개 게시판에 원본을 무작정 업로드하지 않습니다. 회사 PC라면 조직의 보안 정책과 담당자 지침을 먼저 확인해야 합니다.

7단계: 신뢰성 기록으로 반복 패턴을 찾습니다

Windows 키 + R을 누르고 다음을 실행합니다.

perfmon /rel

신뢰성 모니터에는 날짜별로 응용 프로그램 실패, Windows 실패, 하드웨어 오류, 업데이트가 정리됩니다. 재부팅 날짜마다 같은 그래픽 프로그램, 드라이버 설치 또는 Windows 업데이트가 선행했는지 비교하기 좋습니다.

단, 신뢰성 기록의 “Windows가 제대로 종료되지 않음”도 원인 자체는 아닙니다. 해당 날짜의 다른 실패 항목과 기술 세부 정보를 연결하는 용도로 사용합니다.

8단계: 발생 조건으로 소프트웨어와 하드웨어를 분리합니다

특정 게임·3D 작업에서만 재부팅

GPU 부하, CPU 부하, PSU 출력, 온도가 동시에 증가하는 조건입니다. 그래픽 드라이버만 원인이라고 단정하지 말고 다음을 비교합니다.

• 같은 게임의 같은 장면에서 반복되는지
• 프레임 제한이나 전력 부하를 낮추면 빈도가 달라지는지
• WHEA 또는 Display 이벤트가 같은 시각에 있는지
• GPU 보조전원 케이블과 PSU 정격이 제조사 요구 조건에 맞는지
• 오버클럭·언더볼팅·메모리 XMP/EXPO를 기본값으로 돌렸을 때 재현되는지

BIOS 설정을 변경하기 전 현재 값을 사진으로 남기고, 본인이 설정 의미를 모르면 임의로 전압을 조정하지 않습니다.

아무 작업도 하지 않을 때 재부팅

유휴 상태의 전원 절약 전환, 절전 복귀, 펌웨어, 칩셋 드라이버가 후보가 됩니다. 발생 시각이 절전 진입·복귀와 일치하는지 확인하고 노트북이라면 제조사 진단 도구에서 배터리와 어댑터 상태도 점검합니다.

멀티탭이나 충전기를 바꾼 뒤 발생

정격이 부족한 USB-C 충전기, 헐거운 전원 케이블, 노후 멀티탭, 도킹 스테이션 전력 문제가 개입할 수 있습니다. 데스크톱 PSU를 임의 분해해서는 안 됩니다. PSU 내부에는 전원을 뽑은 뒤에도 위험한 전하가 남을 수 있습니다.

파일 복사 중 재부팅 또는 멈춤

저장장치·컨트롤러·케이블·파일시스템을 조사합니다. Disk, stornvme, storahci, Ntfs, volmgr 이벤트가 재부팅 직전에 반복되는지 확인합니다. SMART가 정상이어도 컨트롤러·케이블·펌웨어 문제는 남을 수 있으므로 정상 SMART 하나로 배제하지 않습니다.

9단계: 안전한 기본값으로 원인 범위를 줄입니다

다음 조치는 변경 범위가 비교적 작고 되돌리기 쉽습니다.

1. Windows 업데이트 기록에서 재부팅 시작 시점과 설치 날짜를 비교합니다.
2. PC·노트북 제조사 지원 페이지에서 정확한 모델의 BIOS·칩셋·그래픽 드라이버를 확인합니다.
3. 최근 설치한 튜닝·RGB·모니터링·가상 드라이버 프로그램을 하나씩 중지해 비교합니다.
4. 외장 GPU·USB 허브·도킹 장치 등 비필수 주변기기를 분리해 최소 구성으로 재현합니다.
5. BIOS 오버클럭·언더볼팅·XMP/EXPO를 기본 설정으로 되돌려 비교합니다.

BIOS 업데이트는 전원 중단 시 부팅 불능 위험이 있으므로, 증상과 관련된 변경 내역이 제조사 릴리스 노트에 있거나 제조사가 권고할 때 안정적인 전원 환경에서 진행합니다. 모델이 다른 BIOS 파일을 사용하면 안 됩니다.

10단계: 메모리와 시스템 파일 검사는 역할을 구분합니다

Windows 메모리 진단은 mdsched.exe로 실행할 수 있지만, 통과했다고 RAM·메모리 컨트롤러·XMP 안정성이 완전히 입증되는 것은 아닙니다. 오류가 발견되면 중요한 단서지만, 오류가 없다는 결과는 짧은 검사 동안 문제가 재현되지 않았다는 의미에 가깝습니다.

시스템 파일 손상이 의심될 때는 관리자 터미널에서 다음 순서로 실행합니다.

DISM.exe /Online /Cleanup-Image /RestoreHealth
sfc /scannow

목적: DISM은 Windows 구성 요소 저장소를 복구하고, SFC는 보호된 시스템 파일의 무결성을 검사·복구합니다.

적용 조건: Windows 구성 요소 손상, 업데이트 실패, 시스템 파일 관련 오류가 함께 있을 때 의미가 있습니다.

한계: PSU 순간 차단, RAM 물리 불량, GPU 과열을 고치는 명령이 아닙니다. Kernel-Power 41만 있다는 이유로 가장 먼저 실행할 필요는 없습니다.

증거 조합별 최종 판단표

전문 점검을 받아야 하는 경우

• 타는 냄새, 스파크, 비정상적인 전원 소리가 납니다.
• 노트북 배터리가 부풀거나 하판이 들뜹니다.
• 재부팅 빈도가 빠르게 증가하고 부팅조차 불안정합니다.
• WHEA 치명적 오류가 동일 장치에서 반복됩니다.
• 메모리 검사에서 오류가 발견됩니다.
• 저장장치 오류와 파일 손상이 함께 나타납니다.
• PSU·메인보드·GPU 교차 테스트가 필요하지만 안전한 예비 부품이 없습니다.
• 회사 PC이며 덤프와 로그에 민감한 업무 데이터가 포함될 수 있습니다.

서비스센터에 맡길 때는 “자꾸 꺼져요”만 전달하지 말고 발생 시각, 재현 작업, Event 41 XML, WHEA 메시지, Minidump 유무, 최근 변경 사항을 함께 제공합니다. 진단 시간이 크게 줄어듭니다.

재부팅 진단 체크리스트

• 발생 날짜와 시각을 분 단위로 기록했다.
• 블루스크린·검은 화면·완전 전원 차단을 구분했다.
• Event ID 41의 XML을 저장했다.
• BugcheckCode가 0인지 확인했다.
• PowerButtonTimestamp가 0인지 확인했다.
• 41번 직전 5분의 System 로그를 확인했다.
• WHEA-Logger의 Component와 Error Source를 확인했다.
• volmgr Event 46 유무를 확인했다.
• Minidump와 MEMORY.DMP 생성 여부를 확인했다.
• 신뢰성 모니터에서 반복 패턴을 비교했다.
• 최근 BIOS·드라이버·부품·주변기기 변경을 적었다.
• 오버클럭·언더볼팅을 기본값으로 비교했다.
• 초기화나 부품 구매 전에 최소 구성으로 재현했다.

자주 묻는 질문

Q1. Kernel-Power 41을 삭제하면 재부팅이 해결되나요?

아닙니다. 이벤트 로그를 지우면 기록만 없어지고 원인은 남습니다. 오히려 조사할 증거를 잃게 됩니다.

Q2. Event ID 41이면 파워서플라이 불량인가요?

그럴 가능성은 있지만 확정할 수 없습니다. Stop 오류, 강제 종료, 과열, 메모리 오류도 41로 남을 수 있습니다.

Q3. BugcheckCode가 0이면 블루스크린이 아니었나요?

반드시 그렇지는 않습니다. 전원이 너무 빨리 끊기거나 덤프 작성이 실패하면 코드가 기록되지 않을 수 있습니다.

Q4. WHEA-Logger가 하나라도 있으면 CPU가 고장 난 건가요?

아닙니다. WHEA는 CPU뿐 아니라 메모리, PCIe, 저장장치 등 다양한 하드웨어 오류 경로를 기록합니다. Component·Error Source·반복 시각을 확인해야 합니다.

Q5. Minidump가 없으면 무엇을 확인해야 하나요?

덤프 설정, 시스템 드라이브 여유 공간, 부팅 볼륨 페이지 파일, volmgr Event 46을 확인합니다. 순간 전원 차단이라면 덤프를 만들 시간 자체가 없었을 수도 있습니다.

Q6. WinDbg에서 ntoskrnl.exe가 나오면 Windows를 재설치해야 하나요?

아닙니다. 커널은 충돌을 감지한 최종 지점으로 자주 표시됩니다. Bugcheck 매개변수, 제3자 드라이버, 호출 스택을 함께 봐야 합니다.

Q7. 자동으로 다시 시작을 꺼도 안전한가요?

진단 중 Stop code를 읽기 위한 일시적 설정으로 사용할 수 있습니다. 다만 무인 운영 장비에서는 블루스크린 화면에 멈춰 서비스가 복구되지 않을 수 있습니다.

Q8. 포맷하면 하드웨어 재부팅도 해결되나요?

물리적인 전원·발열·RAM·메인보드 문제는 포맷으로 해결되지 않습니다. 소프트웨어 원인도 증거를 지운 뒤 재발하면 조사하기 더 어려워집니다.

Q9. 게임할 때만 꺼지면 그래픽카드 문제인가요?

GPU뿐 아니라 PSU 출력, CPU·GPU 온도, 메모리 안정성, 그래픽 드라이버가 동시에 후보가 됩니다. 로그와 부하 조건을 교차해야 합니다.

Q10. 이벤트 6008은 원인을 알려주나요?

6008 역시 이전 종료가 예기치 않았다는 결과 기록입니다. 원인을 특정하려면 그보다 앞선 이벤트를 확인해야 합니다.

Q11. 전체 메모리 덤프를 항상 켜 두는 것이 좋나요?

일반적으로 그렇지 않습니다. 용량과 민감정보 노출 부담이 크므로 표준 진단 후 전문가가 요청할 때 선택하는 편이 안전합니다.

Q12. 서비스센터에 어떤 자료를 가져가야 하나요?

발생 시각, 작업 상황, Event 41 XML, 직전 이벤트 목록, WHEA 메시지, 덤프 파일 유무, 최근 변경한 드라이버·BIOS·부품 목록을 준비합니다.

마무리: 41번을 고치는 것이 아니라 41번 앞의 사건을 찾아야 합니다

Kernel-Power 41은 재부팅의 범인을 지목하는 오류명이 아닙니다. Windows가 정상 종료를 확인하지 못했다는 사후 기록입니다. 정확한 진단은 재부팅 장면을 분류하고, 41번 XML과 직전 이벤트, WHEA, 덤프 파일, 재현 조건을 같은 시간축에서 맞추는 데서 시작합니다.

가장 중요한 원칙은 한 개의 로그를 부품 고장으로 번역하지 않는 것입니다. Bugcheck와 덤프가 있으면 충돌 경로를 분석하고, 값이 모두 0이면 전원 차단과 덤프 실패를 나누며, WHEA가 있으면 Component와 반복성을 봅니다. 이렇게 증거를 좁힌 뒤에야 드라이버 조치나 부품 점검의 우선순위를 정할 수 있습니다.

이 글을 보신 뒤 실제 PC에서 확인한 BugcheckCode, WHEA-Logger 유무, Minidump 생성 여부는 어떠셨나요? 비밀번호·사용자 이름·장치 일련번호 같은 개인정보를 가린 뒤 세 값과 발생 상황을 함께 정리하면 원인 범위를 훨씬 정확하게 좁힐 수 있습니다.

공식 참고 자료

• Microsoft Learn: Event ID 41 예기치 않은 종료·재시작 문제 해결
• Microsoft Learn: Windows 작은 메모리 덤프 파일 읽기
• Microsoft Learn: WHEA 하드웨어 오류 이벤트
• Microsoft Learn: 시스템 로그에서 WHEA 이벤트 조회
• Microsoft Learn: 커널 또는 전체 크래시 덤프 생성
• Microsoft 지원: Windows 보안의 장치 성능 및 상태