원칙 — 현장에서 판단하지 않는다
PC 버벅임 분석의 핵심 원칙은 **"현장에서 결론내지 않는다"**입니다. 증상이 16~17시에 보이더라도 다른 시간대 가능성을 열어두고, 하루치 데이터를 통째로 수집한 뒤 사후에 분석합니다.
원인 프로세스 vs 원인 드라이버
드라이버가 원인일 때는 "원인 프로세스"를 단순 지목할 수 없습니다. CPU 시간이 어디에 귀속되는지로 구분합니다.
| 유형 | CPU 시간 귀속 | 실제 원인 | 식별 방법 |
|---|---|---|---|
| 유저모드 프로세스가 직접 원인 | 해당 프로세스 | 그 프로세스 | Process Explorer CPU% |
| 미니필터가 I/O 경로에서 지연 | 피해자 프로세스의 커널 시간 | 미니필터(.sys) | WPA FileIO + fltmc 대조 |
| 드라이버 자체 스레드 | System(PID 4) | 드라이버(.sys) | ProcExp → System → Threads → Start Address |
| DPC/ISR 과점유 | 어디에도 귀속 안 됨 | 드라이버(.sys) | LatencyMon, WPA DPC/ISR |
최종 리포트에서는 "원인 프로세스"와 "원인 드라이버"를 구분해서 보고합니다.
의심 원인 전체 체크리스트
CPU — 유저모드 과점유 / 커널 드라이버 과점유(DPC·ISR) / DPC 지연(오디오 끊김·UI 멈춤의 주범) / 과열 스로틀링 / WMI·백신 시스템 프로세스의 간헐 스파이크
메모리 — 물리 메모리 부족에 따른 하드 페이지폴트 급증 / commit charge 초과로 인한 pagefile 스래싱 / 워킹셋 지속 증가(누수) / 논페이지드 풀·페이지드 풀 고갈
디스크 I/O — 특정 프로세스의 과부하 / 미니필터의 동기 콜백 블로킹 / 미니필터 altitude 충돌 / 인덱서·Defender 실시간 검사 병목 / HDD SMART 경고 / SSD TRIM·펌웨어 이슈
GPU — dwm.exe 과점유 / GPU 큐 기아 / 드라이버 TDR 반복 / 하드웨어 가속 비활성으로 CPU fallback 렌더링
네트워크 — NDIS 드라이버 DPC 과점유 / 대량 I/O로 인한 전반 지연 / DNS 지연
커널/드라이버 — spinlock·ERESOURCE 장시간 보유(락 경합) / 동기 I/O 콜백에서 네트워크·유저모드 대기 / 부적절한 IRQL 사용 / 절전 정책의 성능 제한
프로세스/스레드 — 핸들 누수 / 스레드 폭증으로 컨텍스트 스위칭 과다 / GUI 스레드 블로킹 / 동기 RPC·COM 체인 연쇄 hang
파일시스템/볼륨 — NTFS MFT 단편화 / $UsnJrnl 비대화 / VSS 스냅샷 중 I/O freeze / 디스크 큐 깊이 포화
정리
버벅임은 단일 원인보다 여러 계층(유저·커널·하드웨어)의 상호작용인 경우가 많습니다. 모든 데이터를 먼저 모으고, CPU 시간 귀속으로 프로세스/드라이버를 가른 뒤, 계층별 체크리스트로 좁혀가는 절차가 오진을 막습니다. Orange Platform은 하루치 상시 수집 데이터로 이 사후 분석을 뒷받침합니다.
Orange Platform 현장 분석 방법론을 정리한 가이드입니다.