이 글을 3줄로 요약하면
· CRITICAL_PROCESS_DIED는 고장 진단명이 아니라 윈도우가 중요로 표시해 둔 시스템 프로세스가 예기치 않게 끝났다는 신고입니다.
· 그래서 찾아야 할 것은 "무엇이 망가졌나"가 아니라 무엇이 그 프로세스를 끝냈나이고, 그 갈래는 네 가지로 좁혀집니다.
· 판별표에서 자기 증상을 먼저 찾고, 해당하는 원인 섹션 하나만 처리하면 됩니다. 순서대로 전부 할 필요는 없습니다.
CRITICAL_PROCESS_DIED는 정확히 무슨 뜻인가
"중요한 프로세스가 죽었다"는 문장 그대로의 뜻입니다. 범인 이름은 아직 나오지 않은 상태입니다.
파란 화면에는 보통 "PC에 문제가 발생하여 다시 시작해야 합니다"라는 문구와 함께 중지 코드 CRITICAL_PROCESS_DIED가 표시됩니다. 커널 내부 번호로는 0x000000EF입니다.
윈도우는 일부 프로세스에 "중요(critical)" 표시를 걸어 둡니다. 이 표시가 붙은 프로세스는 살아 있는 것이 운영체제 동작의 전제이므로, 하나라도 예기치 않게 끝나면 커널이 시스템 무결성이 깨졌다고 판단하고 즉시 버그 체크를 냅니다.
마이크로소프트 문서가 중요 프로세스로 나열한 것은 csrss.exe wininit.exe logonui.exe smss.exe services.exe conhost.exe winlogon.exe 입니다. 화면에는 이 이름이 나오지 않기 때문에, 어느 것이었는지는 뒤에서 로그로 확인해야 합니다.
버그 체크에는 매개 변수가 함께 기록됩니다. 두 번째 매개 변수가 0이면 프로세스가, 1이면 스레드가 종료된 경우입니다. 이 값은 7번 섹션에서 이벤트 로그로 그대로 읽을 수 있습니다.
이 코드만 보고 부품을 사러 가지 않습니다
CRITICAL_PROCESS_DIED는 램·SSD 고장에서도 나오고, 드라이버 하나가 파일 하나를 잠근 것만으로도 나옵니다. 원인 범위가 넓다는 뜻이지 하드웨어 고장 신호라는 뜻이 아닙니다. 부품 교체는 아래 네 갈래를 다 지나온 뒤의 선택지입니다.
증상으로 원인 좁히기
언제부터, 어떤 상황에서 뜨는지가 갈래를 거의 결정합니다.
| 증상 | 유력한 원인 | 먼저 볼 항목 |
|---|---|---|
| 드라이버나 윈도우 업데이트를 설치한 그날부터 시작됐다 | 최근 변경분과 기존 구성의 충돌 | 원인 A → 롤백·업데이트 제거 |
| 로그인 화면까지도 못 가고 재부팅을 반복한다(부팅 루프) | 시스템 파일·구성 요소 저장소 손상 | 원인 B → 오프라인 sfc·DISM |
| 큰 파일을 복사하거나 프로그램을 설치할 때 유독 자주 뜬다 | 저장장치 배드섹터·파일 시스템 오류 | 원인 C → chkdsk·SMART |
| 특정 게임·프로그램을 켤 때만, 다른 때는 멀쩡하다 | 보안 프로그램·가상 드라이브 등 서드파티 충돌 | 원인 D → 클린 부팅 |
| 절전에서 깨울 때나 재부팅 직후에만 뜬다 | 빠른 시작이 남긴 이전 세션 상태 + 드라이버 | 원인 A → 빠른 시작 끄기 |
| 시간대·상황에 규칙이 없고 완전히 무작위다 | 추측으로 좁힐 수 없는 구간 | 7번 → 로그·미니덤프 먼저 |
해당하는 줄이 두 개 이상이라면 위쪽 줄부터 처리합니다. 원인 A와 B는 되돌리기 쉬운 조치이고, C와 D는 확인에 시간이 걸립니다.
원인 A최근 드라이버·업데이트 변경
증상 시작일과 설치일이 겹친다면 여기부터 봅니다. 되돌리기가 가장 쉽습니다.
드라이버는 커널 권한으로 돌아갑니다. 새로 올린 드라이버가 이전 버전이 쓰던 구조와 어긋나면, 그 드라이버가 붙잡고 있던 자원을 정리하는 과정에서 중요 프로세스가 함께 끝나는 일이 생깁니다. 그래서 가장 먼저 확인할 것은 고장이 아니라 변경 이력입니다.
1증상 시작일과 설치일을 맞춰본다
설정 → Windows 업데이트 → 업데이트 기록에서 최근 설치된 누적 업데이트·드라이버 업데이트의 날짜를 확인합니다. 첫 블루스크린 날짜와 같거나 하루 이내라면 그 항목이 후보입니다.
2해당 드라이버를 이전 버전으로 되돌린다
Win + R에 위 명령을 입력해 장치 관리자를 열고, 해당 분류를 펼쳐 장치를 우클릭 → 속성 → "드라이버" 탭으로 들어갑니다. "이전 드라이버" 버튼이 활성화되어 있으면 눌러 되돌린 뒤 재부팅합니다.
3윈도우 업데이트가 원인 후보면 그 항목만 제거한다
설정 → Windows 업데이트 → 업데이트 기록 → 맨 아래 "업데이트 제거"에서 증상 시작일에 설치된 항목을 골라 제거합니다. 전체 롤백이 아니라 한 개씩 지우고 재부팅해 관찰합니다.
4절전 해제·재부팅 직후에만 뜬다면 빠른 시작을 끈다
Win + R에 위 명령 입력 → 좌측 "전원 단추 작동 설정" → "현재 사용할 수 없는 설정 변경" 클릭 → "빠른 시작 켜기" 체크 해제 → 변경 내용 저장. 빠른 시작은 이전 세션의 커널 상태를 그대로 되살리기 때문에, 드라이버가 어긋난 상태까지 함께 되살립니다.
이 방법이 안 통하는 경우
"이전 드라이버" 버튼이 회색으로 비활성 상태라면 이전 버전 정보가 시스템에 남아 있지 않은 것이라 롤백 자체가 불가능합니다. 이때는 제조사 사이트에서 이전 버전을 직접 받아 설치하고, 그래도 같으면 원인 B로 넘어갑니다. 증상 시작일이 어떤 설치와도 겹치지 않는 경우도 원인 A가 아닙니다.
원인 B시스템 파일·구성 요소 저장소 손상
중요 프로세스가 읽어야 할 파일 자체가 깨진 경우입니다. 부팅 루프의 대표 원인입니다.
csrss.exe나 services.exe는 시작하면서 여러 시스템 DLL을 불러옵니다. 그중 하나가 손상돼 있으면 프로세스가 초기화 도중 끝나고, 커널은 그것을 "중요 프로세스가 죽었다"로 처리합니다. 마이크로소프트 문서가 이 버그 체크의 기본 조치로 시스템 파일 검사기를 지목하는 이유입니다.
1시스템 파일 검사를 먼저 돌린다
시작 버튼 우클릭 → "터미널(관리자)"에서 실행합니다. 결과 문장이 세 갈래입니다. "위반이 없습니다"면 이 원인이 아니고, "복구했습니다"면 재부팅 후 관찰, "복구할 수 없는 파일이 있습니다"면 아래 2번으로 갑니다.
2복구 원본 자체를 고친 뒤 다시 검사한다
sfc /scannow
sfc는 구성 요소 저장소의 원본을 꺼내 파일을 되돌립니다. 그 원본이 함께 손상돼 있으면 sfc만으로는 끝나지 않으므로, DISM으로 저장소를 복구한 뒤 sfc를 한 번 더 돌립니다.
DISM은 인터넷 연결이 필요합니다
DISM은 부족한 파일을 윈도우 업데이트에서 받아옵니다. 오류 0x800f081f로 끝난다면 원본을 못 찾은 것이므로, 같은 빌드의 ISO를 마운트해 /Source: 옵션으로 경로를 직접 지정해야 합니다.
3윈도우로 못 들어가면 오프라인으로 같은 검사를 건다
부팅 도중 강제 종료를 세 번 반복하면 자동 복구 화면이 뜹니다. 고급 옵션 → 문제 해결 → 고급 옵션 → 명령 프롬프트에서 위 명령을 실행합니다. 복구 환경에서는 드라이브 문자가 바뀔 수 있으니 diskpart → list volume로 실제 윈도우 드라이브를 먼저 확인합니다.
이 방법이 안 통하는 경우
sfc가 "위반이 없습니다"로 끝나거나, 복구 직후 다시 손상이 발견된다면 파일이 저장된 자리가 문제일 가능성이 큽니다. 같은 파일이 반복해서 깨진다는 것은 디스크가 값을 제대로 붙들지 못한다는 신호이므로 원인 C로 넘어갑니다.
원인 C저장장치 결함과 파일 시스템 오류
파일이 아니라 파일이 놓인 자리가 문제인 경우입니다. 복구보다 백업이 먼저입니다.
중요 프로세스는 실행 중에도 디스크를 계속 읽습니다. 읽으려는 섹터가 불량이거나 파일 시스템 메타데이터가 어긋나 있으면 읽기가 실패하고, 그 프로세스는 그 자리에서 끝납니다. 대용량 복사나 설치 중에 유독 자주 뜬다면 이 갈래일 확률이 높습니다.
1먼저 읽기 전용으로 상태만 본다
옵션 없이 실행하면 고치지 않고 검사만 합니다. 마지막 요약 블록의 "불량 섹터의 KB" 줄을 봅니다. 0이 아니면 물리적 손상이 이미 진행 중이라는 뜻입니다.
2시스템 드라이브는 재부팅 검사로 건다
C 드라이브는 사용 중이라 즉시 검사할 수 없다는 안내가 뜹니다. Y를 입력하고 재부팅하면 부팅 과정에서 진행됩니다. 용량이 크면 몇 시간 걸리므로 시간 여유가 있을 때 시작합니다.
3디스크 자체의 건강 상태를 따로 확인한다
터미널(관리자)의 PowerShell 탭에서 실행합니다. HealthStatus가 Healthy가 아니면 파일 시스템 복구로 될 문제가 아닙니다. SSD라면 제조사 도구(삼성 매지션, 크루셜 스토리지 이그제큐티브 등)에서 수명과 펌웨어 버전도 함께 확인합니다.
불량 섹터가 나왔다면 순서가 바뀝니다
chkdsk는 불량 섹터를 고치는 것이 아니라 쓰지 않도록 표시할 뿐입니다. 숫자가 검사할 때마다 늘어나는 중이라면 복구를 계속 시도하는 것보다 데이터를 먼저 다른 저장장치로 옮기는 편이 안전합니다.
이 방법이 안 통하는 경우
chkdsk가 오류 0건으로 끝나고 HealthStatus도 Healthy라면 저장장치는 용의선상에서 빠집니다. 이때는 커널 위에 얹혀 도는 소프트웨어를 봐야 하므로 원인 D로 넘어갑니다.
원인 D서드파티 서비스·보안 프로그램 충돌
특정 프로그램을 쓸 때만 뜬다면, 지우는 것보다 끄고 관찰하는 쪽이 빠릅니다.
백신·가상 드라이브·백업 도구·게임 보안 모듈은 파일 시스템 위에 자기 계층을 얹어 모든 접근을 가로챕니다. 이 계층이 중요 프로세스가 여는 핸들을 잘못 처리하면, 프로세스는 접근 거부를 받고 그대로 종료됩니다. 프로그램이 나쁜 것이 아니라 여러 개가 같은 지점을 동시에 가로챌 때 생기는 문제입니다.
1마이크로소프트 것만 남기고 서비스를 끈다
Win + R에 입력해 시스템 구성을 열고 "서비스" 탭 → 하단 "모든 Microsoft 서비스 숨기기"를 먼저 체크한 뒤 "모두 사용 안 함"을 누릅니다. 체크를 빼먹고 누르면 윈도우 자체 서비스까지 꺼져 부팅이 더 이상해집니다.
2시작 프로그램도 함께 끈다
Ctrl + Shift + Esc → "시작 프로그램 앱"에서 사용으로 되어 있는 항목을 모두 사용 안 함으로 바꿉니다. 서비스만 끄고 시작 프로그램을 남기면 절반만 끈 상태가 되어 판별이 흐려집니다.
3절반씩 되켜며 범인을 좁힌다
이 상태로 재부팅해 평소처럼 며칠 씁니다. 오류가 안 뜨면 꺼둔 항목 중에 원인이 있다는 뜻입니다. 하나씩 켜지 말고 절반씩 켜서 재부팅하면 열 몇 개짜리 목록도 네다섯 번이면 좁혀집니다.
4백신은 제거 전용 도구로 지운다
범인이 보안 프로그램으로 좁혀졌다면 설정 → 앱에서 지우는 것만으로는 커널 드라이버가 남는 경우가 많습니다. 제조사가 배포하는 전용 제거 도구를 받아 실행한 뒤 재부팅합니다.
이 방법이 안 통하는 경우
서비스와 시작 프로그램을 모두 끈 상태에서도 같은 화면이 뜬다면 서드파티 소프트웨어는 원인이 아닙니다. 추측으로 좁힐 구간이 끝났다는 뜻이므로 7번 섹션에서 로그와 미니덤프로 대상을 직접 확인합니다.
어떤 프로세스가 끝났는지 찾아내는 법
파란 화면은 이름을 알려주지 않지만, 로그와 덤프 파일에는 남아 있습니다.
여기까지가 이 오류에서 가장 중요한 부분입니다. 앞의 네 갈래는 확률로 좁히는 방법이고, 이 섹션은 실제로 무엇이 끝났는지 확인하는 방법입니다. 재현이 불규칙할수록 이 순서를 먼저 밟는 편이 시간이 덜 듭니다.
1이벤트 로그에서 버그 체크 기록을 찾는다
Windows 로그 → 시스템에서 원본이 BugCheck인 이벤트(ID 1001)를 찾습니다. 본문에 "0x000000ef (0x…, 0x…, 0x…, 0x…)" 형태로 매개 변수가 그대로 적혀 있습니다. 발생 시각도 함께 남으므로, 바로 앞뒤의 오류 항목이 실마리가 됩니다.
괄호 안 두 번째 값이 0이면 프로세스가, 1이면 스레드가 종료된 경우입니다. 1로 찍혀 있다면 프로그램 하나가 통째로 죽은 것이 아니라 그 안의 작업 한 줄기가 끊긴 것이라, 드라이버 쪽을 먼저 보는 편이 맞습니다.
2덤프가 남도록 설정을 먼저 확인한다
"고급" 탭 → "시작 및 복구"의 설정 버튼에서 디버깅 정보 쓰기가 "없음"으로 되어 있으면 아무리 블루스크린이 떠도 분석할 파일이 안 생깁니다. "작은 메모리 덤프" 이상으로 바꾸고, 아래 덤프 파일 경로를 확인해 둡니다.
3덤프 파일이 실제로 쌓였는지 본다
파일 탐색기 주소창에 위 경로를 붙여넣습니다. 날짜가 블루스크린 시각과 맞는 .dmp 파일이 있으면 분석 대상이 확보된 것입니다. 폴더가 비어 있다면 2번 설정이나 페이지 파일 크기 문제입니다.
4덤프에서 프로세스 이름을 읽는다
마이크로소프트가 배포하는 디버깅 도구 WinDbg로 .dmp 파일을 열고 !analyze -v를 입력하면 PROCESS_NAME 줄에 끝난 프로세스 이름이, MODULE_NAME 줄에 관련 모듈이 나옵니다. 이름이 서드파티 제품이면 원인 D, 저장장치 드라이버면 원인 C 쪽으로 다시 들어갑니다.
덤프 폴더가 계속 비어 있다면
페이지 파일이 꺼져 있거나 크기가 너무 작으면 덤프를 못 씁니다. sysdm.cpl → 고급 → 성능 설정 → 고급 → 가상 메모리에서 시스템이 관리하는 크기로 되돌려 두고 다음 발생을 기다립니다.
자주 묻는 질문
본문에서 다루지 않은, 자주 갈리는 지점만 모았습니다.
Q.이 화면이 뜨면 저장해 둔 파일도 사라지나요?
A.이미 디스크에 기록이 끝난 파일은 지워지지 않습니다. 사라지는 것은 저장하지 않은 작업 내용입니다. 다만 쓰기 도중에 강제 종료가 반복되면 그 파일만 깨질 수 있으므로, 반복될 때는 원인을 찾기 전에 중요한 자료를 먼저 복사해 두는 편이 안전합니다.
Q.부팅 자체가 안 되는데 어디서부터 손대야 하나요?
A.전원 버튼으로 부팅 도중 강제 종료를 세 번 반복하면 자동 복구 화면으로 들어갑니다. 여기서 시작 복구를 먼저 돌리고, 실패하면 명령 프롬프트에서 원인 B의 오프라인 sfc를 실행합니다. 안전 모드로 들어가지는 경우라면 원인 D의 클린 부팅과 사실상 같은 상태이므로, 안전 모드에서 멀쩡하다면 서드파티 쪽을 의심하면 됩니다.
Q.sfc와 DISM은 어느 것을 먼저 돌려야 하나요?
A.sfc를 먼저 돌립니다. "복구할 수 없는 파일이 있습니다"가 나온 경우에만 DISM으로 원본을 고치고 sfc를 다시 돌리면 됩니다. 처음부터 DISM만 돌리는 것은 시간이 더 걸리고, 손상 위치도 알 수 없습니다.
Q.메모리 진단도 해야 하나요?
A.매개 변수나 덤프에 특정 드라이버·프로세스가 반복해서 찍히지 않고 코드가 매번 달라진다면 램을 확인할 값어치가 있습니다. Win + R에 mdsched.exe를 입력해 윈도우 메모리 진단을 돌리고, 여기서 이상이 없어도 의심이 남으면 부팅 USB로 도는 검사 도구로 몇 시간 돌려봅니다. 다만 CRITICAL_PROCESS_DIED 하나만 반복해서 뜨는 상황이라면 램보다 앞의 네 갈래가 먼저입니다.
Q.초기화나 재설치가 마지막 답인가요?
A.초기화는 원인 A·B·D를 한 번에 지워버리는 방법이라 대개 증상이 멎습니다. 다만 원인 C, 즉 저장장치 결함이면 초기화 후 며칠 만에 같은 화면이 돌아옵니다. 초기화를 결정하기 전에 원인 C의 chkdsk와 디스크 상태 확인만큼은 반드시 지나가는 것이 좋습니다.
함께 보면 좋은 글
같은 방식으로 원인을 갈라 정리한 다른 블루스크린 글입니다.
DPC_WATCHDOG_VIOLATION 블루스크린(0x00000133) 해결 순서 저장장치 드라이버가 원인일 때 함께 나타나는 코드입니다 · 눌러서 확인하기 → MEMORY_MANAGEMENT 블루스크린(0x0000001A) 해결 순서 덤프에 특정 모듈이 안 잡히고 코드가 매번 바뀔 때 함께 볼 글입니다 · 눌러서 확인하기 → 윈도우 자동 복구를 준비하는 중 무한루프 해결 순서 이 오류가 부팅 루프로 이어져 복구 화면만 반복될 때 볼 글입니다 · 눌러서 확인하기 →참고 문서 · Microsoft Learn — Bug Check 0xEF: CRITICAL_PROCESS_DIED
