이 글을 3줄로 요약하면
· 블루스크린 원인은 화면에 잠깐 뜨는 중지 코드와, 재부팅 뒤 남는 덤프 파일·이벤트 로그에 기록돼요.
· 원인은 타사 드라이버, 하드웨어, 윈도우 구성 요소, 기록이 남지 않는 전원 문제의 네 갈래로 나눠서 확인해요.
· 중지 코드와 문제 모듈 이름을 먼저 확보하고, 판별표에서 해당하는 원인 섹션의 조치만 확인하면 돼요.
블루스크린(중지 오류)은 윈도우가 더 이상 안전하게 실행을 이어갈 수 없다고 판단했을 때 시스템을 멈추고 다시 시작하는 동작이에요. Microsoft 고급 문제 해결 문서는 중지 오류의 약 70%가 타사 드라이버 코드, 약 10%가 하드웨어, 약 5%가 Microsoft 코드에서 생기고, 나머지 약 15%는 메모리 손상이 심해 원인을 판단하기 어렵다고 설명해요. 원인 후보가 이렇게 넓기 때문에 드라이버 재설치나 윈도우 초기화부터 시도하면 시간이 오래 걸리고, 원인이 그대로 남는 경우도 생겨요. 이 글은 해결 방법을 위에서부터 나열하는 대신, 중지 코드와 덤프 파일로 원인을 먼저 좁힌 뒤 그 원인에 맞는 조치만 하는 순서로 구성했어요. 메뉴 이름과 경로는 Microsoft Learn·Microsoft 지원 문서에서 확인한 표기를 기준으로 옮겼어요.
목차
블루스크린이 정확히 무엇을 기록하는가
중지 코드와 덤프 파일이 무엇을 남기는지부터 짚어요.
화면에 뜨는 파란(또는 검은) 오류 화면을 Microsoft 문서에서는 중지 코드 오류 또는 버그 검사(bug check) 라고 불러요. 화면 아래쪽에는 PAGE_FAULT_IN_NONPAGED_AREA나 MEMORY_MANAGEMENT 같은 중지 코드가 표시되고, 윈도우 11 지원 문서는 이때 실행 중이던 코드의 모듈 이름도 함께 표시된다고 안내해요.
중지 코드는 16진수 번호로도 관리돼요. 예를 들어 Microsoft Learn의 버그 검사 코드 참조에서 0x0000000A는 IRQL_NOT_LESS_OR_EQUAL, 0x00000050은 PAGE_FAULT_IN_NONPAGED_AREA, 0x0000009F는 DRIVER_POWER_STATE_FAILURE, 0x00000124는 WHEA_UNCORRECTABLE_ERROR에 해당해요. 코드마다 원인 범위가 다르기 때문에, 이 이름 하나만 정확히 알아도 확인할 범위가 크게 줄어요.
화면 모양은 버전에 따라 달라요. Microsoft 지원 문서는 윈도우 11 24H2 이후는 검은 화면, 23H2 이하는 기존 파란 화면으로 오류 정보를 보여 준다고 설명해요. 새 검은 화면은 약 2초 정도만 표시된다는 보도도 있어서, 화면을 보고 코드를 받아 적기가 예전보다 어려워졌어요.
그래서 실제 판단은 재부팅 뒤 남는 기록으로 하는 편이 정확해요. 기록은 세 곳에 남아요. 첫째는 %SystemRoot%\Minidump 폴더의 작은 메모리 덤프 파일, 둘째는 %SystemRoot%\MEMORY.DMP의 커널·자동 메모리 덤프, 셋째는 이벤트 뷰어의 시스템 로그예요. Microsoft 문서에 따르면 작은 메모리 덤프에는 중지 메시지와 매개 변수, 로드된 드라이버 목록, 멈춘 스레드의 커널 모드 호출 스택 등이 들어가요.
덤프 파일은 오류가 날 때마다 새로 생겨요
작은 메모리 덤프는 컴퓨터 오류가 발생할 때마다 날짜가 들어간 서로 다른 이름으로 새로 만들어지고, 이전 파일도 보존된다고 문서에 적혀 있어요. 여러 파일의 중지 코드와 모듈 이름이 같은지 비교하면 우연한 한 번인지, 같은 원인이 반복되는지가 드러나요.
증상과 기록으로 원인 먼저 좁히기
기록된 코드나 상황에 가까운 줄을 찾아 오른쪽 칸의 섹션으로 이동하세요.
아래 표는 Microsoft 문서에 나온 중지 코드별 안내와 일반 문제 해결 단계를 원인별로 묶은 거예요. 중지 코드를 아직 모른다면 표를 보기 전에 7번 섹션의 확인 절차로 코드와 모듈 이름부터 확보하는 편이 빨라요.
| 증상 | 유력한 원인 | 먼저 볼 항목 |
|---|---|---|
분석 결과 모듈 이름이 그래픽·네트워크 등 특정 .sys 드라이버로 나옴 |
타사 드라이버 | 원인 A → 해당 드라이버 업데이트·롤백 |
| 드라이버나 프로그램을 설치한 직후부터 반복됨 | 드라이버·소프트웨어 | 원인 A → 최근 설치 항목 되돌리기 |
| 덤프마다 코드·모듈이 달라지거나 WHEA_UNCORRECTABLE_ERROR 같은 하드웨어 오류 보고 코드 | 메모리·하드웨어 | 원인 B → 메모리 진단, 추가 부품 분리 |
| NTFS_FILE_SYSTEM, PAGE_FAULT_IN_NONPAGED_AREA와 디스크 경고가 함께 보임 | 저장 장치·파일 시스템 | 원인 B → chkdsk /f /r |
| 윈도우 업데이트 직후, 또는 시스템 파일 관련 코드 | 업데이트·시스템 파일 | 원인 C → 최신 누적 업데이트, sfc /scannow |
| 갑자기 꺼졌는데 덤프 파일이 없고 Kernel-Power 41만 남음 | 전원·강제 종료·덤프 설정 | 원인 D → BugcheckCode 값 확인 |
원인이 하나로 딱 떨어지지 않을 때도 있어요. 예를 들어 메모리 불량이 있으면 멀쩡한 드라이버가 손상된 메모리를 읽다가 멈추면서 매번 다른 드라이버 이름이 기록될 수 있어요. 덤프 파일 여러 개에서 모듈 이름이 계속 바뀐다면 원인 A보다 원인 B를 먼저 의심하는 편이 합리적이에요.
반대로 모듈 이름이 여러 번 같은 드라이버로 나온다면 그 드라이버가 가장 유력한 후보예요. 표의 코드 이름은 대표적인 예시일 뿐이므로, 여기에 없는 코드가 나왔다면 Microsoft Learn의 버그 검사 코드 참조에서 코드 번호로 해당 문서를 찾아 원인 범위를 확인하면 돼요.
원인 A드라이버·소프트웨어가 원인인 경우
Microsoft 문서 기준으로 가장 비중이 큰 원인이에요.
Microsoft 고급 문제 해결 문서가 중지 오류의 약 70%를 타사 드라이버 코드로 보는 만큼, 덤프 분석에서 특정 드라이버 이름이 나오면 그 드라이버부터 확인하는 것이 순서예요. 드라이버 파일은 보통 .sys 확장자로 끝나고, WinDbg 분석 결과의 IMAGE_NAME 항목에 표시돼요.
1분석 결과의 드라이버 파일 이름으로 장치를 특정하기
IMAGE_NAME에 나온 파일 이름을 검색하면 어느 제조사의 어떤 장치 드라이버인지 확인할 수 있어요. 그래픽 카드, 네트워크 어댑터, 오디오, 백신·가상화 프로그램의 드라이버가 자주 보이는 편이에요.
2장치 관리자에서 드라이버를 이전 버전으로 되돌리기
최근 드라이버 업데이트 뒤부터 증상이 시작됐다면 장치 관리자에서 해당 장치를 마우스 오른쪽 단추로 눌러 속성을 열고, 드라이버 탭의 드라이버 롤백을 선택해요. 롤백 버튼이 비활성화돼 있다면 이전 버전 정보가 남아 있지 않은 상태예요.
롤백이 불가능하거나 오래된 드라이버가 원인이라면 반대로 장치 제조사 사이트에서 최신 드라이버를 받아 설치해요. Microsoft 문서도 드라이버와 애플리케이션 업데이트가 필요하면 제조업체에 문의하라고 안내해요. 윈도우 11 지원 문서는 장치 관리자에서 느낌표 등으로 표시된 장치가 있는지 확인하는 단계도 기본 문제 해결에 넣어 두었어요.
3부팅 직후 바로 멈춘다면 안전 모드에서 작업하기
안전 모드는 최소한의 드라이버만 불러오므로 문제 드라이버를 제거하거나 되돌릴 수 있어요. 윈도우 11은 설정 > 시스템 > 복구, 윈도우 10은 설정 > 업데이트 및 보안 > 복구의 고급 시작 옵션에서 지금 다시 시작을 누른 뒤 문제 해결 > 고급 옵션 > 시작 설정 > 다시 시작 순서로 들어가 4 또는 F4를 눌러요.
최근에 설치한 프로그램 뒤부터 블루스크린이 시작됐다면 그 프로그램도 같은 방식으로 후보에 올려요. 백신, 게임 보안 모듈, 가상 드라이브처럼 커널 드라이버를 함께 설치하는 프로그램은 앱 목록에서 제거하는 것만으로 드라이버까지 정리되는 경우가 많아요.
이 방법이 안 통하는 경우
드라이버를 되돌리거나 새로 설치했는데도 같은 오류가 나고, 다음 덤프에서 전혀 다른 드라이버 이름이 나온다면 드라이버 자체보다 메모리 손상일 가능성이 커요. 이때는 원인 B의 메모리 진단을 먼저 확인하세요.
원인 B메모리·저장 장치 같은 하드웨어가 원인인 경우
코드가 매번 바뀌거나 하드웨어 계열 코드가 나올 때 확인해요.
Microsoft 문서가 하드웨어 원인으로 보는 비율은 약 10%지만, 하드웨어 문제는 소프트웨어 조치로 해결되지 않기 때문에 일찍 걸러내는 것이 중요해요. 고급 문제 해결 문서의 일반 단계에는 메모리와 하드 디스크를 진단하는 하드웨어 테스트가 포함돼 있고, 윈도우 11 지원 문서는 새로 추가한 하드웨어를 먼저 분리하라고 안내해요.
1최근 추가한 부품이나 외부 장치를 분리하기
램, 그래픽 카드, 외장 드라이브, 도킹 스테이션처럼 블루스크린이 시작되기 직전에 추가한 장치가 있다면 분리한 상태로 증상이 사라지는지 확인해요.
2Windows 메모리 진단으로 램 검사하기
실행 창(Win + R)에 mdsched.exe를 입력하면 Windows 메모리 진단 도구가 열리고, 다시 시작하면서 메모리 검사를 진행해요. 검사 도중에는 컴퓨터를 사용할 수 없으므로 작업 중인 파일을 먼저 저장해요.
3디스크 오류 검사하기
NTFS_FILE_SYSTEM이나 PAGE_FAULT_IN_NONPAGED_AREA가 나오면 Microsoft 문서는 디스크 오류 검사를 권해요. 관리자 권한 명령 프롬프트에서 아래 명령을 실행하고, 시스템 드라이브라면 다음 재부팅 때 검사하도록 예약하는 안내가 나와요.
/r 옵션은 불량 섹터까지 찾기 때문에 드라이브 용량에 따라 시간이 오래 걸려요. 검사를 시작하기 전에 중요한 파일은 다른 저장 장치에 백업해 두는 편이 안전해요. 이미 드라이브 상태가 나쁘다면 긴 검사 자체가 부담이 될 수 있기 때문이에요.
BIOS·펌웨어도 확인 대상이에요
Microsoft 고급 문제 해결 문서는 BIOS와 펌웨어가 최신 버전인지 확인하는 것도 일반 단계로 안내해요. 업데이트 방법은 메인보드·노트북 제조사마다 다르므로 제조사 지원 페이지의 절차를 따르고, 진행 중에는 전원이 끊기지 않게 해야 해요.
이 방법이 안 통하는 경우
메모리 진단과 디스크 검사에서 이상이 없고, 덤프에서 같은 드라이버가 반복해 나온다면 하드웨어보다 원인 A가 유력해요. 반대로 진단에서 오류가 보고됐다면 소프트웨어 조치를 이어가기보다 제조사 서비스 센터에 점검을 의뢰하는 편이 맞아요.
원인 C윈도우 업데이트·시스템 파일이 원인인 경우
업데이트 직후 시작됐거나 시스템 파일 손상이 의심될 때 봐요.
Microsoft 코드 자체가 원인인 비율은 약 5%로 작지만, 업데이트가 덜 끝났거나 시스템 파일이 손상된 상태에서는 여러 종류의 중지 코드가 나올 수 있어요. Microsoft 문서는 DRIVER_IRQL_NOT_LESS_OR_EQUAL(0xD1) 같은 코드에 대해서도 최신 누적 업데이트 적용을 첫 조치로 안내해요.
1최신 누적 업데이트 설치하기
윈도우 11은 설정 > Windows 업데이트에서 업데이트 확인을 누르고, 윈도우 10은 설정 > 업데이트 및 보안 > Windows 업데이트에서 같은 버튼을 눌러요. 설치 후 다시 시작하라는 안내가 있으면 재부팅까지 마쳐야 적용돼요.
업데이트 직후부터 블루스크린이 시작됐다면 반대로 해당 업데이트가 원인일 수도 있어요. 이런 경우는 같은 증상을 겪는 사용자가 많아 Microsoft가 알려진 문제로 공지하는 일이 있으므로, 업데이트 번호(KB 번호)로 Microsoft의 릴리스 상태 안내를 검색해 확인하는 편이 정확해요.
2시스템 파일 검사하기
Microsoft 문서는 시스템 파일 손상이 의심되는 경우 시스템 파일 검사기를 실행하라고 안내해요. 관리자 권한 명령 프롬프트에서 아래 명령을 차례로 실행하면 윈도우 구성 요소 저장소를 먼저 복구한 뒤 시스템 파일을 검사해요.
sfc /scannow
3디스크 여유 공간 확보하기
Microsoft 문서는 정상 작동을 위해 디스크 여유 공간 10~15% 를 권장해요. 여유 공간이 부족하면 업데이트 설치와 덤프 파일 생성이 모두 실패할 수 있어요.
이 방법이 안 통하는 경우
업데이트와 시스템 파일 검사를 마쳤는데도 같은 코드가 반복된다면 윈도우 구성 요소보다 드라이버나 하드웨어 쪽일 가능성이 높아요. 덤프 분석 결과의 모듈 이름을 다시 확인해 원인 A 또는 원인 B로 돌아가세요. 윈도우 11 지원 문서는 마지막 단계로 시스템 복원이나 복구 옵션을 안내하지만, 그 전에 중요한 데이터를 백업해야 해요.
원인 D덤프가 남지 않거나 전원 문제로 꺼지는 경우
기록이 남지 않으면 원인을 판단할 수 없으니 이것부터 해결해요.
컴퓨터가 갑자기 꺼졌는데 Minidump 폴더가 비어 있다면, 블루스크린이 아니라 전원이 끊긴 것일 수도 있고 덤프 설정에 문제가 있을 수도 있어요. Microsoft Learn은 이런 상황에서 이벤트 뷰어의 Kernel-Power 이벤트 ID 41 을 확인하라고 안내해요. 이 이벤트는 시스템이 정상 종료 없이 다시 시작됐을 때 시스템 로그에 기록돼요.
판단 기준은 이벤트 41의 세부 정보에 있는 BugcheckCode 값이에요. 값이 0이 아니면 중지 오류 때문에 다시 시작된 것이고, 문서의 예시처럼 159라는 값은 16진수 0x0000009F로 바꿔 코드를 찾으면 돼요. 값이 0이면 중지 오류가 기록되지 않은 것이어서 배터리 방전·전원 차단, 전원 공급 장치 고장이나 용량 부족, 시스템 멈춤, 전원 버튼 강제 종료 같은 원인을 먼저 봐야 해요.
1덤프 파일 설정 확인하기
작업 표시줄 검색 상자에 고급 시스템 설정 을 입력해 시스템 속성 을 열고, 고급 탭의 시작 및 복구 에서 설정 을 눌러요. 디버깅 정보 쓰기 목록에서 자동 메모리 덤프 를 선택하고 확인 을 누른 뒤 컴퓨터를 다시 시작해요.
Microsoft 문서에 따르면 메모리 덤프 파일을 만들려면 부팅 볼륨에 최소 2MB 이상의 페이징 파일이 있어야 해요. 페이징 파일을 끈 상태라면 블루스크린이 나도 덤프가 남지 않으므로 가상 메모리 설정을 시스템 관리 크기로 되돌려 두는 편이 안전해요. 이벤트 로그에 volmgr 원본의 이벤트 ID 46(크래시 덤프 초기화 실패)이 있다면 이 설정 문제를 의심할 수 있어요.
2전원 쪽 원인 확인하기
BugcheckCode가 0이라면 데스크톱은 전원 공급 장치 용량과 멀티탭·콘센트 상태를, 노트북은 배터리와 어댑터 연결을 먼저 확인해요. 고사양 게임처럼 부하가 클 때만 꺼진다면 전원 용량 부족을 의심할 수 있어요.
이 방법이 안 통하는 경우
덤프 설정과 전원을 확인했는데도 기록 없이 꺼진다면 소프트웨어로 원인을 좁히기 어려운 상태예요. 메인보드·전원 공급 장치 같은 부품 점검이 필요할 수 있으므로 제조사 서비스 센터에 문의하세요. 설정 이후 덤프가 남기 시작했다면 7번 섹션의 분석 절차로 넘어가면 돼요.
문제를 정확히 찾아내는 법
추측 대신 이벤트 로그와 덤프 분석으로 코드와 모듈을 확인해요.
원인 섹션을 고르려면 중지 코드와 문제 모듈 이름이 필요해요. 아래 순서는 간단한 확인에서 정밀 분석으로 넘어가도록 배치했어요. 앞 단계에서 코드가 확인되면 뒤 단계는 필요할 때만 진행해도 돼요.
1이벤트 뷰어에서 발생 시각과 코드 확인하기
실행 창에 eventvwr.msc를 입력해 이벤트 뷰어를 열고 Windows 로그 > 시스템 을 선택해요. 블루스크린 뒤에는 보통 원본이 BugCheck 인 이벤트(이벤트 ID 1001)에 버그 검사 코드와 덤프 파일 경로가 기록되고, Kernel-Power 41 이벤트의 BugcheckCode 값으로도 코드를 확인할 수 있어요.
2안정성 모니터로 반복 패턴 보기
실행 창에 perfmon /rel을 입력하면 안정성 모니터가 열려요. 날짜별 그래프에 치명적 이벤트가 표시되므로 블루스크린이 특정 프로그램 설치나 업데이트 직후부터 시작됐는지 한눈에 비교할 수 있어요.
3덤프 파일 위치 확인하기
작은 메모리 덤프는 C:\Windows\Minidump, 커널·자동 메모리 덤프는 C:\Windows\MEMORY.DMP에 저장돼요. 이 폴더는 관리자 권한이 필요하므로, 분석할 파일을 바탕 화면 같은 일반 폴더로 복사해 두면 다루기 편해요.
4WinDbg 설치하고 덤프 파일 열기
WinDbg는 Microsoft Learn의 설치 페이지, Microsoft Store, 또는 아래 winget 명령으로 설치할 수 있어요. 지원 운영체제는 윈도우 11과 윈도우 10 1607 이상이에요. 실행 뒤 File 메뉴에서 크래시 덤프 열기를 선택하거나 Ctrl + D를 눌러 복사해 둔 .dmp 파일을 열어요.
5!analyze -v로 자동 분석하기
덤프가 열리면 아래쪽 명령 입력 칸에 다음 명령을 입력해요. 기호(심볼) 경로가 설정돼 있지 않으면 분석 결과가 부정확할 수 있어서, 먼저 Microsoft 기호 서버를 지정하고 다시 불러오는 명령을 함께 실행하는 편이 좋아요.
.reload
!analyze -v
분석 결과는 길지만 원인을 고르는 데 필요한 항목은 몇 개뿐이에요. Microsoft Learn의 !analyze 확장 문서 기준으로 아래 항목을 먼저 읽으면 돼요.
| 항목 | 의미 | 이 글에서 보는 곳 |
|---|---|---|
| BUGCHECK_CODE | 버그 검사(중지) 코드 | 2번 판별표, 코드 참조 문서 |
| MODULE_NAME | 오류가 발생한 모듈(드라이버 등) 이름 | 원인 A 후보 특정 |
| IMAGE_NAME | 드라이버·실행 파일의 파일 이름 | 원인 A 장치 특정 |
| FAILURE_BUCKET_ID | 오류를 분류한 구체적인 버킷 | 같은 원인 반복 여부 비교 |
| STACK_TEXT | 오류 시점의 호출 스택 | 관련 구성 요소 확인 |
IMAGE_NAME이 ntoskrnl.exe처럼 윈도우 핵심 파일로만 나온다면 그 파일 자체가 원인이라기보다 다른 요인이 드러난 결과일 수 있어요. 이때는 STACK_TEXT에 함께 나오는 다른 드라이버 이름과, 여러 덤프의 결과가 같은지를 함께 비교해요.
드라이버 검증 도구는 마지막에 신중하게 써요
Microsoft 문서는 원인 드라이버를 찾는 고급 도구로 드라이버 검증 도구(verifier.exe)를 소개하지만, CPU 사용률이 높아지고 성능이 떨어질 수 있다고 경고해요. 의심되는 드라이버만 10~20개씩 나눠 검사하라고 안내하며, 부팅이 안 되면 안전 모드에서 도구를 끌 수 있다고 적혀 있어요. 실행 전에 중요 데이터를 백업하고 복원 지점을 만들어 두는 것이 안전해요.
자주 묻는 질문
블루스크린 원인을 찾을 때 자주 나오는 질문만 모았어요.
Q.블루스크린이 한 번 떴는데 바로 조치해야 하나요?
A.Microsoft 지원 문서는 예기치 않게 다시 시작된 경우 대부분 다시 시작하는 것으로 해결된다고 안내해요. 같은 오류가 반복될 때 이 글의 확인 순서를 진행하면 되고, 한 번뿐이라도 이벤트 뷰어에서 중지 코드는 기록해 두는 편이 나중에 비교하기 좋아요.
Q.Minidump 폴더가 아예 없거나 비어 있어요.
A.블루스크린이 한 번도 기록되지 않았거나, 덤프 설정이 꺼져 있거나, 페이징 파일·디스크 공간이 부족한 경우예요. 원인 D의 덤프 설정과 이벤트 ID 41의 BugcheckCode 값을 먼저 확인하세요.
Q.화면이 너무 빨리 사라져서 중지 코드를 못 봤어요.
A.윈도우 11 24H2 이후의 검은 오류 화면은 표시 시간이 짧아요. 재부팅 뒤 이벤트 뷰어의 시스템 로그나 perfmon /rel의 안정성 모니터에서 같은 시각의 기록을 확인하면 코드를 찾을 수 있어요.
Q.덤프 파일을 다른 사람에게 보내 분석을 부탁해도 되나요?
A.덤프에는 오류 시점의 메모리 일부가 들어가므로 작은 메모리 덤프라도 공유 전에 신뢰할 수 있는 곳인지 확인하는 편이 안전해요. 커널·자동 메모리 덤프(MEMORY.DMP)는 크기가 크고 담긴 정보도 많아요.
Q.WinDbg 결과에 나온 드라이버를 바로 삭제해도 되나요?
A.저장 장치·칩셋 같은 드라이버를 지우면 부팅이 안 될 수 있어요. 삭제보다 드라이버 롤백이나 제조사 최신 버전 설치를 먼저 확인하고, 작업 전에 복원 지점을 만들어 두세요.
여러 덤프에서 같은 드라이버가 반복되는데 제조사 최신 버전으로도 해결되지 않는다면, 분석 결과(BUGCHECK_CODE·IMAGE_NAME)를 정리해 해당 장치 제조사 고객센터에 전달하는 것이 다음 단계예요. 진단 도구에서 하드웨어 오류가 확인됐다면 PC 또는 부품 제조사의 서비스 센터가 확인 주체가 돼요.
참고 문서 · Microsoft Learn – 중지 코드 오류 또는 블루 스크린 오류 고급 문제 해결
참고 문서 · Microsoft 지원 – Windows 예기치 않은 다시 시작 및 중지 코드 오류 문제 해결
참고 문서 · Microsoft Learn – Read small memory dump files
참고 문서 · Microsoft Learn – Event ID 41 unexpected restart
참고 문서 · Microsoft Learn – Install WinDbg
참고 문서 · Microsoft Learn – Analyze a Kernel-Mode Dump File by Using WinDbg
참고 문서 · Microsoft Learn – Using the !analyze Extension
참고 문서 · Microsoft Learn – Bug Check Code Reference
참고 문서 · Microsoft Learn – perfmon 명령
※ 이 글은 정보 제공 목적이며, 기기·OS·프로그램 버전과 환경에 따라 해결 방법이 다를 수 있습니다. 레지스트리·시스템 파일 수정 등은 위험할 수 있으니 중요 데이터를 백업한 뒤 진행하시고, 해결되지 않으면 제조사 고객센터나 전문가에게 문의하세요.
'컴퓨터·윈도우' 카테고리의 다른 글
| 프린터 오프라인 해결 – 드라이버 문제 vs 포트·네트워크 문제 가르는 법 (0) | 2026.10.04 |
|---|---|
| 작업표시줄 먹통일 때, 탐색기 재시작으로 안 풀리면 볼 곳 (0) | 2026.09.28 |
| 디스크 사용량 100%가 부팅 후에도 계속된다면 – 원인 4가지 확인 순서 (윈도우 10·11 공통) (0) | 2026.09.17 |
| 0xc0000142 오류, 프로그램이 안 열릴 때 원인별 확인법 (1) | 2026.08.21 |
| msvcp140.dll이 없어 코드 실행을 진행할 수 없습니다 – 재설치 전 확인할 3가지 (0) | 2026.08.14 |
