서천동 주민을 위한 WIN32K_LOCK_HELD_TOO_LONG 빠른 진단과 해결 7가지 꿀팁

커널의 취약 지점: 락이 오래 잡히면 무슨 일이 생기나

cancel spin lock 이란 무엇인가

cancel spin lock 은 커널이 IRP(입출력 요청 패킷)를 취소할 때 I/O 매니저가 획득하는 전역 락입니다. 이 락을 잡은 상태에서 취소 루틴이 호출되면 해당 취소 루틴은 반드시 락을 해제하고 반환해야 합니다. 만약 취소 루틴이 이 락을 해제하지 않고 반환하면 이후의 취소 호출들이 모두 실패하거나 대기 상태에 빠져 시스템 전반의 취소 경로가 막히게 되고, 심각한 경우 데드락이나 블루스크린(버그 체크)으로 이어집니다.

([learn.microsoft.com](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x11b—driver-returned-holding-cancel-lock?utm_source=openai))

왜 그래픽/입력·드라이버 영역에서 자주 발생하나

윈도우의 win32k 서브시스템은 그래픽·입력 스택에서 사용자 모드와 커널 모드가 자주 오가며 복잡한 동기화가 필요합니다. 특히 드라이버가 IRP를 취급하는 과정에서 취소 가능 상태를 잘못 관리하거나, 락 보유 시간을 길게 유지하는 동작(예: 긴 I/O 대기, 외부 리소스에서 블록)이 섞이면 cancel spin lock 이 장시간 유지될 가능성이 높아집니다.

결과적으로 GUI 스레드나 입력 처리 경로가 막혀 화면 멈춤/재부팅으로 이어지기 쉽습니다. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/points-to-consider-when-canceling-irps?utm_source=openai))

현상으로 확인할 수 있는 핵심 포인트

갑작스러운 화면 정지, 입력 무응답, 그리고 이벤트 로그나 메모리 덤프에서 WIN32K 관련 함수 또는 cancel 루틴 주소가 보이면 의심해볼 수 있습니다. 커널 덤프에서 bugcheck 코드(예: 0x11B 관련 메시지)와 함께 IRP 주소, 취소 루틴 주소 등이 파라미터로 나오면 cancel spin lock 보유 문제일 가능성이 큽니다.

이 부분은 덤프 분석으로 비교적 명확히 드러납니다. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x11b—driver-returned-holding-cancel-lock?utm_source=openai))

로그·던프에서 읽어내는 단서들

블루스크린 코드와 파라미터 해석

버그 체크 메시지에 표시되는 코드와 파라미터는 원인 추적의 첫 실마리입니다. 예를 들어 DRIVER_RETURNED_HOLDING_CANCEL_LOCK(0x11B) 같은 코드가 보이면 첫 번째 파라미터가 취소된 IRP 주소, 두 번째 파라미터가 취소 루틴의 주소로 해석되며, 이 정보로 어느 드라이버의 루틴이 문제인지 역추적을 시도합니다.

덤프의 모듈 목록과 심볼을 맞춰 해당 주소가 어느 드라이버의 함수인지 확인하세요. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x11b—driver-returned-holding-cancel-lock?utm_source=openai))

이벤트 뷰어와 시스템 로그에서 찾을 것

Event Viewer 의 시스템 로그에서 BSOD 발생 시각 전후의 오류(예: 드라이버 로드 실패, 디바이스 오류, WDF/UMDF 실패)를 확인하면 어떤 장치가 문제의 단초인지 좁힐 수 있습니다. 드라이버 업데이트나 최근 하드웨어 변경이 있던 시점과 겹치면 우선순위를 높이십시오.

또한 메모리 덤프가 생성되었다면 덤프 파일 생성 경로와 파일명을 확보해 WinDbg 로 분석을 진행하는 것이 좋습니다. ([support.microsoft.com](https://support.microsoft.com/en-US/windows/resolving-blue-screen-errors-in-windows-60b01860-58f2-be66-7516-5c45a66ae3c6?utm_source=openai))

WinDbg 로 보는 락/데드락 단서 (!locks 등)

커널 덤프를 WinDbg 로 열었을 때 !analyze -v, !locks, !qlocks, !deadlock 같은 명령을 사용하면 현재 시스템이 잡고 있는 락 목록과 데드락 여부, 락 소유 스레드 및 대기 스레드를 파악할 수 있습니다. 특히 !locks 출력은 각 리소스의 소유 쓰레드와 기다리는 쓰레드 목록을 보여주므로, 어떤 락이 오래 잡혀 있고 어느 스레드가 해제하지 못했는지 좁히는 데 결정적입니다.

WinDbg 의 !analyze -hang 옵션은 시스템 전반의 락 상태와 DPC 큐를 스캔해 힌트를 줍니다. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-analyze?utm_source=openai))

현장 대응 — 우선 순위별 점검 체크리스트

즉시 시도할 수 있는 빠른 조치

시스템이 재부팅되는 상태라면 안전 모드로 부팅해 장치 관리자의 의심 드라이버를 비활성화하거나, 최근 설치한 소프트웨어·드라이버를 제거해 재현 여부를 확인하세요. 또한 Windows Update 와 드라이버 제조사 페이지에서 최신 드라이버로 교체하는 것만으로 문제가 해결되는 경우가 많습니다.

간단한 파일 무결성 검사(sfc /scannow)나 DISM 복구도 병행하면 시스템 파일 문제 여부를 배제할 수 있습니다. ([support.microsoft.com](https://support.microsoft.com/en-US/windows/resolving-blue-screen-errors-in-windows-60b01860-58f2-be66-7516-5c45a66ae3c6?utm_source=openai))

심장부 점검 항목(권장 순서)

아래 표는 현장에서 빠르게 체크할 우선순위와 권장 커맨드를 정리한 것입니다. 각 항목은 영향 범위가 크니 한 단계씩 꼼꼼히 진행하세요.

우선순위	무엇을 확인할지	권장 명령/조치	목적
1	최근 드라이버/하드웨어 변경	장치 관리자에서 문제 드라이버 비활성화, 제조사 드라이버 설치	가장 흔한 원인 배제
2	시스템 파일 무결성	sfc /scannow, DISM /Online /Cleanup-Image /RestoreHealth	OS 손상 여부 확인
3	메모리·디스크 상태	Windows Memory Diagnostic, chkdsk C: /f /r	하드웨어 결함 배제
4	덤프 수집·분석	WinDbg: !analyze -v, !locks, !deadlock, lm	원인 드라이버·스택 추적
5	악성코드 검사	정상 AV/안티멀웨어 검사	외부 간섭 배제

현장에서 시간 없을 때의 핵심 팁

우선 재현성이 낮으면 안전 모드에서 최소 구성으로 부팅 후 드라이버를 하나씩 활성화해 재현해보는 방법(이분법적 제거)을 권합니다. 재현이 가능하면 덤프를 확보해 WinDbg 로 분석하고, 재현이 불가능하면 이벤트 로그와 드라이버 설치/업데이트 이력을 기준으로 의심 후보를 좁히세요.

([support.microsoft.com](https://support.microsoft.com/en-US/windows/resolving-blue-screen-errors-in-windows-60b01860-58f2-be66-7516-5c45a66ae3c6?utm_source=openai))

덤프 분석 실무 — WinDbg 중심으로

덤프 열기와 첫 단계 명령어

덤프를 WinDbg 로 연 뒤 가장 먼저 !analyze -v 를 실행해 기본적인 버그 체크 요약과 의심 모듈을 확인합니다. 이어서 lm(모듈 리스트)로 드라이버 심볼 매칭을 확인하고, !locks 로 락 상태, ~*k 로 모든 스레드 스택을 훑어 어느 스레드가 긴 시간을 소비하는지 확인합니다.

필요한 경우 !analyze -hang 을 사용해 잠긴 리소스와 DPC 큐 상태를 추가로 점검합니다. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-analyze?utm_source=openai))

락 소유 스레드와 취소 루틴 역추적

!locks 출력에서 특정 리소스의 owning thread 에 <*> 표시가 있는 항목을 찾았다면 해당 스레드의 스택(~/

kv)을 분석해 어떤 함수가 락을 잡고 있는지 역추적합니다. BUGCHECK 파라미터로 나온 취소 루틴 주소가 특정 드라이버의 함수라면 그 드라이버의 코드 경로(예: 어떤 조건에서 락을 풀지 못하는지)를 중심으로 코드를 리뷰하거나 제조사에 리포트하세요. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-deadlock?utm_source=openai))

Driver Verifier 와 Deadlock Detection 활용

재현 가능한 케이스라면 Driver Verifier 의 Deadlock Detection 을 켜고 다시 재현해보면 더 상세한 데드락 토폴로지와 스택을 얻을 수 있습니다. 이 경우 !deadlock 명령으로 드라이버 검증기가 기록한 락 위반 정보를 보며 어느 드라이버가 락 계층을 어겼는지 판단할 수 있습니다.

다만 Verifier 는 시스템 부하를 크게 올리므로 테스트 머신에서만 사용하는 게 안전합니다. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-deadlock?utm_source=openai))

드라이버·하드웨어 관점의 해결법

드라이버 업데이트와 롤백 전략

가장 먼저 공식 제조사 드라이버로 업데이트하거나, 최근 드라이버가 문제를 일으키기 시작했다면 이전 버전으로 롤백해 확인하세요. 드라이버 서명 문제나 테스트되지 않은 베타 드라이버는 안전 모드에서 제거하는 것이 좋습니다. 또한 커널 모드에서 동작하는 필터 드라이버(보안 소프트웨어, 파일시스템 필터 등)는 간헐적 락 문제를 만들기 쉬우니 우선순위로 점검합니다.

([support.microsoft.com](https://support.microsoft.com/en-US/windows/resolving-blue-screen-errors-in-windows-60b01860-58f2-be66-7516-5c45a66ae3c6?utm_source=openai))

하드웨어 검사와 교체 고려사항

메모리 오류나 디스크 불량이 드물게 드라이버/커널 오류와 결합돼 복합 문제를 만들기도 합니다. Windows Memory Diagnostic, 제조사 메모리·스토리지 진단 툴을 돌려 하드웨어 결함을 배제하세요. 물리적 연결 문제(케이블, 전원 공급)도 I/O 타임아웃과 락 보유를 유발할 수 있어 간과하지 마세요.

([support.microsoft.com](https://support.microsoft.com/en-US/windows/resolving-blue-screen-errors-in-windows-60b01860-58f2-be66-7516-5c45a66ae3c6?utm_source=openai))

제조사와 협업할 때 준비할 자료

델, HP, 그래픽·입력 장치 제조사에 리포트할 때는 덤프 파일, !analyze 출력, 이벤트 로그 타임스탬프, 재현 절차(재현 가능하면 재현 단계)를 정리해 전달하면 원인 파악이 훨씬 빨라집니다. 문제가 드라이버 코드 내부라면 심볼이 맞는 덤프와 해당 드라이버의 버전 정보는 거의 필수입니다.

([learn.microsoft.com](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/getting-started-with-windbg–kernel-mode-?utm_source=openai))

예방과 모니터링으로 문제 다시 안 생기게 하기

운영 환경에서의 모니터링 포인트

운영 중인 시스템이라면 이벤트 뷰어에서 커널-레벨 경고, 드라이버 관련 오류, I/O 타임아웃 로그 등을 정기적으로 모니터링하세요. 또한 드라이버·펌웨어 업데이트를 중앙에서 통제하고, 대규모 배포 전에는 테스트 그룹에서 충분히 검증하는 절차를 권합니다. 자동화된 모니터링(예: SIEM이나 시스템 관리 도구)에 BSOD 발생 이벤트를 알람으로 연결해 빠르게 대응할 수 있게 하십시오.

([support.microsoft.com](https://support.microsoft.com/en-US/windows/resolving-blue-screen-errors-in-windows-60b01860-58f2-be66-7516-5c45a66ae3c6?utm_source=openai))

테스트 환경에서의 권장 관행

드라이버 개발이나 시스템 통합 테스트 시에는 Driver Verifier 의 적절한 옵션(특히 Deadlock Detection, I/O 검사)을 켜서 사전에 락 관련 문제를 발견하도록 하세요. 또한 커널 심볼을 정확히 관리하고 덤프 수집 체계를 자동화해 재현 없이도 원인 분석에 필요한 데이터를 확보해 두는 것이 좋습니다.

([learn.microsoft.com](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-deadlock?utm_source=openai))

현장 사례에서 배운 실무 팁

제가 작업하면서 자주 본 케이스는 서드파티 필터 드라이버가 IRP를 취급하면서 IoSetCancelRoutine/IoReleaseCancelSpinLock 호출을 짝맞춰 하지 않아 문제가 된 경우였습니다. 이런 경우는 드라이버 업데이트·롤백으로 해결되거나 제조사와의 코드 리뷰 끝에 패치로 고쳐졌습니다.

재현 가능한 상황이면 Driver Verifier 와 WinDbg 로 락 소유 스택을 확보해 제조사에 전달하는 것이 가장 빠른 해결책입니다. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/points-to-consider-when-canceling-irps?utm_source=openai))

글을 마치며

cancel spin lock 을 오래 잡고 반환하지 않는 문제는 단순한 성능 저하를 넘어 시스템 전체의 취소 경로를 막아 데드락이나 블루스크린을 유발할 수 있습니다. 덤프와 이벤트 로그에서 WIN32K 또는 취소 루틴 관련 주소가 보이면 우선적으로 락 보유 여부를 의심하세요. 재현 가능한 경우 WinDbg 와 Driver Verifier 로 락 소유 스택을 확보해 문제 드라이버를 특정하는 것이 가장 빠른 해결책입니다. 문제 드라이버가 확인되면 즉시 패치·롤백 또는 제조사와의 협업을 통해 취소 루틴에서 반드시 IoReleaseCancelSpinLock 이 호출되도록 수정해야 합니다.

알아두면 쓸모 있는 정보

1. 안전 모드로 부팅해 의심 드라이버를 비활성화하고 재현 여부를 먼저 확인하세요.

2. 블루스크린 발생 시 메모리 덤프를 확보하고 WinDbg 의 !analyze -v, !locks, !deadlock 등을 사용해 초기 단서를 확보하세요.

3. 재현 가능한 문제라면 Driver Verifier 의 Deadlock Detection 을 켜서 상세한 락 위반 정보를 얻으세요.

4. 드라이버는 최신 안정 버전으로 업데이트하거나, 최근 설치된 드라이버가 원인으로 의심되면 이전 버전으로 롤백해 비교하세요.

5. 운영 환경에서는 이벤트 로그와 I/O 타임아웃을 모니터링하고, 드라이버·펌웨어 배포 전에 테스트 그룹에서 검증 절차를 거치세요.

중요 사항 정리

취소 루틴은 호출될 때 항상 cancel spin lock 을 해제해야 하며, 이를 위반하면 이후의 모든 취소 호출이 실패하거나 시스템 전반에 걸친 데드락/BSOD로 이어질 수 있습니다. 덤프 분석으로 문제가 된 취소 루틴의 주소를 확인하고 드라이버 측에서 IoReleaseCancelSpinLock 호출 누락이나 락 보유 시간이 길어지는 경로를 우선 점검·수정해야 합니다.