이 글을 3줄로 요약하면
· DPC_WATCHDOG_VIOLATION은 고장 신호가 아니라 어떤 드라이버가 정해진 시간 안에 일을 끝내지 못했다는 감시 타이머의 신고입니다.
· 그 드라이버는 저장장치 쪽에서 나오는 경우가 압도적으로 많고, 나머지는 그래픽과 전원 관리로 갈립니다.
· 판별표에서 자기 증상을 찾아 해당 원인 섹션만 처리하면 됩니다. 네 가지를 순서대로 다 할 필요는 없습니다.
DPC_WATCHDOG_VIOLATION은 정확히 무슨 뜻인가
"드라이버가 시간을 못 지켰다"는 뜻입니다. 어느 드라이버인지는 매개 변수가 알려줍니다.
파란 화면에는 중지 코드 DPC_WATCHDOG_VIOLATION이 표시되고, 커널 내부 번호는 0x00000133입니다. DPC는 Deferred Procedure Call, 지연 프로시저 호출의 약자입니다.
장치가 인터럽트를 걸면 드라이버는 급한 처리만 즉시 끝내고 나머지를 DPC로 미뤄 둡니다. 미뤄 둔 이 작업은 다른 작업보다 높은 우선순위에서 실행되기 때문에, 오래 붙들고 있으면 시스템 전체가 멈춥니다. 그래서 커널에는 DPC 감시 타이머가 돌아가고, 정해진 시간을 넘기면 즉시 버그 체크를 냅니다.
마이크로소프트 문서가 제시하는 설계 기준은 DPC는 100마이크로초, 인터럽트 서비스 루틴은 25마이크로초를 넘기지 말 것입니다. 실제 감시 타이머는 이보다 훨씬 넉넉하게 잡혀 있으므로, 이 화면이 떴다는 것은 여유 시간을 한참 넘겨 붙들고 있었다는 뜻입니다.
여기서 중요한 갈래가 하나 있습니다. 이 버그 체크의 첫 번째 매개 변수가 0이냐 1이냐에 따라 성격이 완전히 다릅니다.
| 첫 매개 변수 | 의미 | 해석 |
|---|---|---|
| 0 | 단일 DPC 또는 ISR이 자기 시간 할당량을 넘김 | 범인 드라이버 하나가 특정된다. 스택 추적으로 이름이 나온다 |
| 1 | 높은 우선순위 구간에 누적으로 오래 머무름 | 여러 드라이버가 조금씩 겹쳐 누적된 경우. 한 개를 지목하기 어렵다 |
SSD를 새로 사기 전에 확인할 것
이 코드가 저장장치 쪽에서 자주 나온다고 해서 SSD가 죽었다는 뜻은 아닙니다. 대부분은 SSD 위에 얹힌 컨트롤러 드라이버가 윈도우 버전과 안 맞는 경우입니다. 부품 교체는 원인 A와 B를 지나온 뒤의 이야기입니다.
증상으로 원인 좁히기
어떤 작업을 할 때 뜨는지가 갈래를 거의 결정합니다.
| 증상 | 유력한 원인 | 먼저 볼 항목 |
|---|---|---|
| 대용량 파일 복사·설치·압축 해제 등 디스크가 바쁠 때 뜬다 | 저장장치 컨트롤러 드라이버가 표준이 아님 | 원인 A → 드라이버 파일 확인 |
| 읽기·쓰기 속도가 느려졌고 파일 탐색기가 자주 멈춘다 | 저장장치 자체의 상태·펌웨어 문제 | 원인 B → 상태·펌웨어 점검 |
| 영상 재생·게임 등 화면이 바쁠 때만 뜬다 | 그래픽 드라이버가 DPC를 오래 붙듦 | 원인 C → 그래픽 드라이버 |
| 노트북에서 배터리로 쓸 때나 절전에서 깨울 때 집중된다 | 링크 전원 관리가 장치를 늦게 깨움 | 원인 D → 전원 옵션 |
| 특정 USB 기기(허브·외장하드·독)를 꽂았을 때만 뜬다 | 주변기기 드라이버가 DPC를 붙듦 | 7번 → 덤프에서 이름 확인 |
| 규칙 없이 무작위이고 첫 매개 변수가 1로 찍힌다 | 여러 드라이버가 누적으로 겹침 | 7번 → 로그·덤프 먼저 |
해당하는 줄이 둘 이상이면 위쪽 줄부터 처리합니다. 원인 A는 되돌리기 쉬운 조치이고, B로 갈수록 시간과 준비가 필요합니다.
원인 A저장장치 컨트롤러 드라이버 불일치
이 코드에서 가장 먼저 봐야 할 자리입니다. 확인은 1분, 되돌리기도 쉽습니다.
SATA·NVMe 컨트롤러 드라이버는 디스크 요청 하나하나를 DPC로 처리합니다. 메인보드 제조사나 칩셋 제조사가 제공한 전용 드라이버가 지금 윈도우 버전과 어긋나 있으면, 이 처리에서 시간을 넘기는 일이 생깁니다. 윈도우에는 같은 역할을 하는 표준 드라이버가 들어 있으므로, 표준으로 바꿔 보는 것이 가장 빠른 판별법입니다.
1지금 어떤 드라이버가 붙어 있는지 확인한다
Win + R에 위 명령을 입력하고 "IDE ATA/ATAPI 컨트롤러" 또는 "저장소 컨트롤러"를 펼칩니다. 항목을 우클릭 → 속성 → "드라이버" 탭에서 드라이버 공급자와 버전, "드라이버 세부 정보"의 파일 이름을 봅니다.
파일 이름이 storahci.sys(SATA) 또는 stornvme.sys(NVMe)면 이미 윈도우 표준 드라이버입니다. iaStorA.sys·iaStorAC.sys 같은 제조사 전용 파일이면 아래 2번의 교체 대상입니다.
2표준 드라이버를 직접 골라 설치한다
같은 장치를 우클릭 → "드라이버 업데이트" → "내 컴퓨터에서 드라이버 찾아보기" → "내 컴퓨터의 사용 가능한 드라이버 목록에서 직접 선택"으로 들어갑니다. 목록에서 표준 SATA AHCI 컨트롤러(NVMe라면 표준 NVM Express 컨트롤러)를 고르고 다음을 누른 뒤 재부팅합니다.
3바꾼 뒤 며칠 관찰한다
이 오류는 하루에 여러 번 뜨다가도 며칠 조용한 경우가 있어, 재부팅 직후 한 번 멀쩡한 것으로는 판단할 수 없습니다. 평소 증상이 나던 작업(대용량 복사·게임 설치 등)을 일부러 한 번 시켜보고 이틀 이상 관찰합니다.
이 방법이 안 통하는 경우
이미 storahci.sys·stornvme.sys가 붙어 있거나, 표준으로 바꾼 뒤에도 같은 화면이 뜬다면 드라이버가 아니라 그 아래 장치 쪽입니다. 원인 B로 넘어갑니다. 목록에 표준 항목이 아예 안 보이는 경우는 RAID 모드로 구성된 시스템일 수 있으니, 이때는 드라이버를 건드리지 말고 원인 B부터 확인합니다.
원인 B저장장치 상태와 펌웨어
장치가 응답을 늦게 주는 경우입니다. 드라이버는 기다리다 시간을 넘깁니다.
드라이버가 시간을 못 지키는 이유가 반드시 드라이버에 있는 것은 아닙니다. 디스크가 요청에 늦게 답하면 그 응답을 기다리는 처리도 함께 늘어집니다. 불량 섹터를 여러 번 다시 읽거나, 펌웨어가 특정 명령을 비정상적으로 오래 붙드는 경우가 여기에 해당합니다.
1파일 시스템과 표면 상태를 검사한다
먼저 옵션 없이 읽기 전용으로 돌려 요약 블록의 "불량 섹터의 KB" 줄을 확인합니다. 0이 아니면 물리적 손상이 진행 중입니다. 시스템 드라이브는 chkdsk C: /f /r 후 Y를 입력하고 재부팅해야 검사됩니다.
2장치 자체의 건강 상태를 따로 본다
터미널(관리자)의 PowerShell에서 실행합니다. HealthStatus가 Healthy가 아니면 소프트웨어 조치로 해결될 문제가 아닙니다. 모델명을 여기서 확인해 두면 다음 단계에서 그대로 씁니다.
3펌웨어 버전을 제조사 도구로 확인한다
삼성은 매지션, 마이크론·크루셜은 스토리지 이그제큐티브, WD·샌디스크는 대시보드처럼 제조사마다 전용 도구가 있습니다. 설치 후 현재 펌웨어와 최신 펌웨어를 비교해 갱신 대상이면 올립니다.
펌웨어 갱신 전에 지켜야 할 세 가지
중요한 자료를 먼저 다른 저장장치로 복사하고, 노트북이라면 충전기를 꽂은 상태로 진행하며, 진행 중에는 전원을 끄거나 절전으로 넘기지 않습니다. 펌웨어 갱신은 중간에 끊기면 장치를 못 쓰게 만들 수 있는 작업입니다.
이 방법이 안 통하는 경우
chkdsk가 오류 0건이고 HealthStatus도 Healthy이며 펌웨어도 최신이라면 저장장치는 용의선상에서 빠집니다. 화면이 바쁠 때만 뜨는 패턴이었다면 원인 C, 절전·배터리 상황에 몰려 있으면 원인 D로 갑니다.
원인 C그래픽 드라이버
영상 재생·게임처럼 화면이 바쁠 때만 뜬다면 이 갈래입니다.
그래픽 드라이버도 DPC를 많이 쓰는 대표적인 계층입니다. 마이크로소프트 문답 게시판에도 nvlddmkm.sys가 원인으로 찍힌 0x133 사례가 올라와 있습니다. 저장장치 쪽을 다 확인했는데도 반복된다면 여기를 봅니다.
1지금 버전과 설치 날짜를 먼저 적어 둔다
바탕화면 빈 곳 우클릭 → 추가 옵션 표시 → 제조사 제어판 → 시스템 정보에서 드라이버 버전을 확인합니다. 되돌릴 때 필요한 값이므로 갱신 전에 적어 둡니다.
2증상 시작 시점과 겹치면 갱신이 아니라 되돌린다
드라이버를 새로 올린 날부터 시작됐다면 장치 관리자 → 디스플레이 어댑터 → 속성 → 드라이버 탭의 "이전 드라이버" 버튼으로 되돌립니다. 반대로 오래된 상태로 방치돼 있었다면 3번으로 갑니다.
3제조사 설치 프로그램으로 깨끗하게 다시 깐다
제조사 공식 페이지에서 그래픽카드 모델에 맞는 드라이버를 받아, 설치 옵션 중 기존 설정을 지우고 새로 설치하는 항목을 선택합니다. 이전 버전의 잔여 파일이 남아 있으면 갱신 후에도 같은 증상이 이어지는 경우가 있습니다.
내장 그래픽 드라이버도 같이 봅니다
노트북과 최근 데스크톱은 내장과 외장 그래픽이 함께 붙어 있고, 화면 출력이 둘 사이를 오갑니다. 외장만 갱신하고 내장을 몇 년 전 버전으로 두면 전환 순간에 문제가 남을 수 있으니 두 개를 같이 맞춥니다.
이 방법이 안 통하는 경우
드라이버를 되돌리고 다시 깔아도 같고, 화면이 한가할 때도 뜬다면 그래픽 쪽이 아닙니다. 노트북이거나 절전 상황에 몰려 있으면 원인 D, 그렇지 않으면 7번 섹션에서 덤프로 이름을 확인합니다.
원인 D링크 전원 관리와 절전 설정
장치를 재우는 설정이 깨우는 시간을 늘려 감시 시간을 넘기는 경우입니다.
윈도우는 전력을 아끼려고 저장장치와 USB 장치를 짧은 유휴 시간에도 저전력 상태로 내립니다. 다시 깨우는 데 걸리는 시간이 길면, 그 사이 요청을 붙들고 있는 처리가 감시 시간을 넘깁니다. 노트북에서 배터리로 쓸 때나 절전 해제 직후에 몰리는 증상이 이 갈래의 특징입니다.
1고급 전원 관리 설정을 연다
Win + R에 입력한 뒤 현재 선택된 전원 관리 옵션 오른쪽의 "설정 변경" → "고급 전원 관리 옵션 설정 변경"으로 들어갑니다.
2세 항목을 최대 성능 쪽으로 바꾼다
목록에서 하드 디스크 → 다음 시간 이후 하드 디스크 끄기를 0(사용 안 함)으로, USB 설정 → USB 선택적 절전 모드 설정을 사용 안 함으로, 항목이 보인다면 AHCI 링크 전원 관리를 최대 성능으로 바꿉니다. 배터리와 전원 연결 두 값을 모두 바꿔야 합니다.
3바꾼 뒤 증상이 멎으면 하나씩 되돌린다
세 항목을 동시에 바꿔 증상이 멎었다면 어느 것이 원인이었는지는 아직 모릅니다. 노트북 사용 시간이 아깝다면 하나씩 원래대로 돌려 가며 어떤 항목에서 증상이 돌아오는지 확인하고, 그 하나만 끈 채로 씁니다.
AHCI 링크 전원 관리 항목이 안 보인다면
이 항목은 기본 상태에서 목록에 숨겨져 있는 경우가 많습니다. 억지로 레지스트리를 고쳐 꺼내기 전에, 메인보드 설정(UEFI) 쪽의 저장장치 절전 옵션이 켜져 있는지부터 확인하는 편이 안전합니다. 항목이 없다고 해서 원인 D가 아닌 것은 아닙니다.
이 방법이 안 통하는 경우
절전 관련 항목을 모두 끈 상태에서도 같은 화면이 반복된다면 전원 관리는 원인이 아닙니다. 추측으로 좁힐 구간이 끝났다는 뜻이므로 7번 섹션에서 로그와 덤프로 드라이버 이름을 직접 확인합니다.
원인 드라이버를 이름으로 찾아내는 법
추측을 멈추고 기록을 읽는 단계입니다. 매개 변수와 덤프에 답이 들어 있습니다.
이 코드는 다른 블루스크린보다 원인 특정이 잘 되는 편입니다. 첫 매개 변수가 0인 경우 마이크로소프트 문서도 "스택 추적으로 문제 구성 요소를 대개 식별할 수 있다"고 적고 있습니다. 앞의 네 갈래를 헤매기 전에 이 섹션을 먼저 밟아도 됩니다.
1이벤트 로그에서 매개 변수를 읽는다
Windows 로그 → 시스템에서 원본이 BugCheck인 이벤트를 찾습니다. 본문에 "0x00000133 (0x…, 0x…, 0x…, 0x…)" 형태로 매개 변수가 그대로 적혀 있습니다. 괄호 안 첫 값이 0인지 1인지를 확인해 1번 섹션의 표와 맞춰 봅니다.
2덤프 파일이 실제로 쌓였는지 본다
파일 탐색기 주소창에 위 경로를 붙여넣습니다. 블루스크린 시각과 날짜가 맞는 .dmp 파일이 있으면 분석 대상이 확보된 것입니다. 폴더가 비어 있다면 sysdm.cpl → 고급 → 시작 및 복구 설정에서 "디버깅 정보 쓰기"를 작은 메모리 덤프 이상으로 바꿔 두고 다음 발생을 기다립니다.
3덤프에서 드라이버 파일 이름을 확인한다
마이크로소프트가 배포하는 디버깅 도구 WinDbg로 .dmp를 열고 !analyze -v를 입력하면 MODULE_NAME·IMAGE_NAME 줄에 파일 이름이 나옵니다. 이 이름이 곧 어느 원인 섹션으로 갈지를 정합니다.
| 덤프에 찍힌 파일 | 관련 장치 | 돌아갈 섹션 |
|---|---|---|
| iaStorA.sys / iaStorAC.sys / storahci.sys | SATA·저장장치 컨트롤러 | 원인 A → 표준 드라이버로 교체 |
| stornvme.sys / 제조사 NVMe 드라이버 | NVMe SSD | 원인 A·B → 드라이버와 펌웨어 함께 |
| nvlddmkm.sys / amdkmdag.sys / igdkmd64.sys | 그래픽 | 원인 C → 그래픽 드라이버 |
| Wdf01000.sys / usbxhci.sys | USB·주변기기 계층 | 원인 D + 해당 기기 분리 후 관찰 |
| ntoskrnl.exe만 찍힘 | 커널(범용 · 특정 실패) | 첫 매개 변수가 1인지 확인 후 누적형으로 접근 |
ntoskrnl.exe가 찍혔다고 윈도우가 문제인 것은 아닙니다
감시 타이머를 실제로 발동시킨 코드가 커널이라 이름이 커널로 남는 것뿐입니다. 이 경우 첫 매개 변수가 1일 확률이 높고, 그때는 한 드라이버를 지목하기 어려우므로 원인 D의 절전 설정을 먼저 정리하고 관찰 기간을 길게 잡는 편이 낫습니다.
자주 묻는 질문
본문에서 다루지 않은, 자주 갈리는 지점만 모았습니다.
Q.이 오류는 하드웨어 고장 신호인가요?
A.이 버그 체크 자체는 "시간을 못 지켰다"는 감시 결과일 뿐, 부품이 죽었다는 판정이 아닙니다. 드라이버·펌웨어·전원 설정처럼 소프트웨어 쪽에서 정리되는 경우가 훨씬 많습니다. 다만 원인 B에서 불량 섹터가 늘고 있거나 HealthStatus가 Healthy가 아니라면 그때는 하드웨어를 봐야 합니다.
Q.안전 모드에서는 안 뜨는데 무슨 뜻인가요?
A.안전 모드는 제조사 드라이버 대부분을 로드하지 않고 표준 드라이버로만 돕니다. 여기서 멀쩡하다면 커널이 아니라 제조사 드라이버 쪽이라는 신호라, 원인 A와 C를 우선으로 보면 됩니다.
Q.새로 산 SSD인데도 뜹니다. 왜 그런가요?
A.새 제품이어도 출고 시점 펌웨어가 최신이 아닐 수 있고, 메인보드 설정과 궁합이 안 맞는 경우가 있습니다. 원인 B의 펌웨어 확인과 원인 A의 표준 드라이버 확인을 함께 지나가 보고, 그래도 같으면 메인보드 제조사의 최신 펌웨어(UEFI) 배포 여부도 확인해 봅니다.
Q.sfc와 DISM도 돌려야 하나요?
A.돌려서 나쁠 것은 없지만, 이 코드에서 우선순위가 높은 조치는 아닙니다. 시스템 파일이 깨져 있으면 보통 다른 코드가 함께 나타납니다. 드라이버 교체와 전원 설정을 먼저 정리하고, 다른 오류가 같이 보일 때 sfc /scannow와 DISM 복구를 추가로 돌리는 순서가 낫습니다.
Q.초기화나 재설치까지 해야 하나요?
A.초기화는 제조사 드라이버를 한 번에 걷어내는 효과가 있어 증상이 멎기도 하지만, 복구 후 제조사 유틸리티를 다시 깔면 같은 드라이버가 돌아옵니다. 원인 A에서 드라이버 파일 이름만 확인해도 몇 분이면 끝나므로, 초기화는 7번 섹션까지 지나온 뒤에 판단하는 것이 좋습니다.
함께 보면 좋은 글
같은 방식으로 원인을 갈라 정리한 다른 블루스크린 글입니다.
CRITICAL_PROCESS_DIED 블루스크린(0x000000EF) 해결 순서 같은 저장장치 문제에서 번갈아 나타나는 코드입니다 · 눌러서 확인하기 → VIDEO_TDR_FAILURE 블루스크린 해결 순서 원인 C처럼 그래픽 드라이버가 응답을 늦게 줄 때 뜨는 코드입니다 · 눌러서 확인하기 → KMODE_EXCEPTION_NOT_HANDLED 블루스크린 해결 순서 덤프에 같은 드라이버 이름이 찍힐 때 함께 보면 좋은 글입니다 · 눌러서 확인하기 →참고 문서 · Microsoft Learn — Bug Check 0x133: DPC_WATCHDOG_VIOLATION
