이 글의 목적은 윈도우에서 블루스크린(BSOD)이 발생했는데도 메모리 덤프 파일이 생성되지 않는 문제를 체계적으로 진단하고, 메모리 덤프 설정 및 관련 조건을 단계별로 점검하여 확실하게 덤프를 수집할 수 있도록 돕는 것이다.
1. 메모리 덤프 파일이 중요한 이유
블루스크린이 발생하면 화면에는 잠깐 오류 코드만 표시되고 시스템이 재부팅되는 경우가 많다. 현장에서 문제의 근본 원인을 분석하기 위해서는 당시 커널과 프로세스 상태를 그대로 담고 있는 메모리 덤프 파일이 필수이다. 메모리 덤프가 없으면 다음과 같은 제약이 생긴다.
- 드라이버 충돌, 메모리 손상, 스토리지 오류 등 근본 원인을 추적하기 어렵다.
- 마이크로소프트 또는 벤더 기술 지원에 로그를 제출하더라도 정확한 분석이 불가능하다.
- 장애 재발 시점까지 시간을 허비하면서 추측성 조치를 반복하게 된다.
따라서 “덤프 파일 생성 안됨” 문제는 단순 편의 기능이 아니라, 장애 관리 프로세스 전체에 영향을 주는 핵심 이슈라고 볼 수 있다.
2. 윈도우 메모리 덤프 종류 이해하기
먼저 어떤 종류의 메모리 덤프를 설정해야 하는지 이해해야 한다. 윈도우 10, 윈도우 11 기준으로 주요 유형은 다음과 같다.
| 덤프 종류 | 파일 크기 | 포함 내용 | 권장 용도 |
|---|---|---|---|
| 소형 메모리 덤프 (256KB~수MB) | 매우 작다. | 중요 커널 정보, 스택 일부, 드라이버 목록만 포함한다. | 간단한 드라이버 충돌 여부 확인에 적합하다. |
| 커널 메모리 덤프 | RAM의 1/3~절반 정도까지 커질 수 있다. | 커널 영역과 관련 메모리만 저장한다. | 대부분의 서버·업무용 PC에서 표준으로 권장한다. |
| 완전 메모리 덤프 | 물리 RAM 용량과 거의 동일하다. | 전체 물리 메모리를 그대로 저장한다. | 특수 케이스나 벤더 분석 요청 시에만 사용한다. |
| 자동 메모리 덤프 / 활성 메모리 덤프 | 시스템이 자동으로 크기를 조절한다. | 핵심 분석에 필요한 영역 위주로 저장한다. | 일반 사용자 및 노트북 등에서 권장한다. |
현업에서는 대부분 커널 메모리 덤프 또는 자동 메모리 덤프를 기본값으로 두고 운용하는 것이 일반적이다.
3. 덤프 파일이 생성되지 않는 대표 원인
덤프 파일이 생성되지 않을 때는 설정 문제뿐 아니라 시스템 환경 조건도 함께 살펴야 한다. 다음 표는 현장에서 자주 발생하는 원인을 정리한 것이다.
| 구분 | 세부 원인 | 점검 포인트 |
|---|---|---|
| 설정 문제 | 시작 및 복구 설정에서 “디버깅 정보 쓰기”가 없음으로 설정되어 있다. | sysdm.cpl > 고급 > 시작 및 복구에서 옵션 확인한다. |
| 설정 문제 | 덤프 파일 경로가 잘못되었거나 권한이 없다. | 기본값 C:\Windows\MEMORY.DMP 및 %SystemRoot%\Minidump 폴더 권한을 확인한다. |
| 디스크 조건 | 시스템 드라이브의 여유 공간 부족이다. | 덤프 크기 + 여유 버퍼를 포함해 최소 수십 GB 이상 확보한다. |
| 페이지 파일 | 페이지 파일이 없음 또는 수동 크기 설정으로 너무 작다. | 시스템 관리 크기 사용을 권장하고, 최소 RAM 크기 이상 확보한다. |
| 보안/유틸리티 | 백신, 보안 에이전트, 클린업 도구가 덤프 파일을 즉시 삭제한다. | 해당 제품의 예외 설정을 확인하고, 덤프 경로를 제외 처리한다. |
| 정책/레지스트리 | 그룹 정책 또는 레지스트리 CrashControl 값이 덤프 생성을 차단한다. | HKLM\SYSTEM\CurrentControlSet\Control\CrashControl 키를 점검한다. |
| 기타 | 강제 전원 차단, 하드웨어 결함 등으로 덤프 쓰기 단계 이전에 전원 상실이다. | 블루스크린 이후 자동 재시작 여부, 이벤트 로그를 함께 확인한다. |
4. GUI에서 메모리 덤프 설정 점검하기
4.1 시스템 속성에서 시작 및 복구 설정 열기
가장 기본적인 점검 항목은 “시작 및 복구” 창이다. 다음 순서로 확인한다.
- Windows 키를 누르고 검색창에
sysdm.cpl을 입력하여 실행한다. - 또는 “내 PC”를 마우스 오른쪽 버튼으로 클릭하고 “속성”을 선택한 후, “고급 시스템 설정”을 클릭한다.
- “고급” 탭에서 “시작 및 복구” 항목의 “설정” 버튼을 클릭한다.
이 창에서 다음 항목을 반드시 확인해야 한다.
- 시스템 실패에서 “자동으로 다시 시작” 체크 여부
- “디버깅 정보 쓰기” 드롭다운에서 덤프 타입
- 덤프 파일 경로 및 “기존 덤프 파일 덮어쓰기” 여부
주의 : “디버깅 정보 쓰기”가 “없음”으로 설정되어 있으면 블루스크린이 발생해도 어떤 덤프 파일도 생성되지 않는다. 문제 분석을 위해서는 최소한 “소형 메모리 덤프(256KB)” 이상으로 설정해야 한다.
4.2 권장 설정 예시
일반적인 업무용 PC 또는 서버 환경에서 권장되는 기본 설정 예시는 다음과 같다.
- 디버깅 정보 쓰기: 커널 메모리 덤프 또는 자동 메모리 덤프
- 덤프 파일:
%SystemRoot%\MEMORY.DMP - 소형 덤프 디렉터리:
%SystemRoot%\Minidump - 자동으로 다시 시작: 필요에 따라 선택하되, 장애 분석용 환경에서는 체크 해제도 고려한다.
서버와 같이 가용성이 중요한 시스템은 블루스크린 후 자동 재시작을 유지하되, 덤프 파일이 실제로 저장되는지 별도로 테스트하는 것이 좋다.
5. 레지스트리 CrashControl 값 점검
GUI 설정이 정상이어도 레지스트리 또는 그룹 정책에서 덤프 관련 값이 덮어써지는 경우가 있다. 기본적으로 다음 경로를 사용한다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl주요 값과 의미는 다음과 같다.
| 값 이름 | 형식 | 의미 | 대표 설정 값 |
|---|---|---|---|
| CrashDumpEnabled | DWORD | 덤프 생성 여부 및 덤프 종류를 정의한다. | 0=없음, 1=완전, 2=커널, 3=소형, 7=자동/활성 메모리 덤프 |
| DumpFile | REG_EXPAND_SZ | 주 덤프 파일 경로를 지정한다. | %SystemRoot%\MEMORY.DMP |
| MinidumpDir | REG_EXPAND_SZ | 소형 덤프 저장 폴더를 지정한다. | %SystemRoot%\Minidump |
| Overwrite | DWORD | 기존 덤프 덮어쓰기 여부를 제어한다. | 0=덮어쓰지 않음, 1=덮어씀 |
레지스트리로 설정값을 확인하기 위해서는 다음과 같이 명령 프롬프트 또는 PowerShell에서 쿼리할 수 있다.
reg query "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl"도메인 환경에서 GPO(그룹 정책)를 통해 CrashControl 값이 강제로 배포되는 경우, 로컬에서 값을 수정해도 재부팅 후 다시 덮어써질 수 있다. 이 경우에는 그룹 정책 관리 콘솔에서 관련 템플릿을 점검해야 한다.
주의 : 레지스트리를 직접 수정하기 전에 반드시 현재 설정을 내보내기 하여 백업해 두는 것이 좋다. 특히 서버 환경에서는 검증되지 않은 값 변경이 부팅 실패로 이어질 수 있다.
6. 페이지 파일 및 디스크 여유 공간 조건
6.1 페이지 파일과 덤프 생성의 관계
윈도우가 커널 또는 완전 메모리 덤프를 생성할 때는 페이지 파일(Pagefile.sys)을 임시 버퍼로 활용한다. 따라서 다음 조건이 만족되지 않으면 덤프 생성을 시작하지 않거나, 중간에 실패하고 이벤트 로그에 오류가 남는다.
- 시스템 드라이브(C:)에 페이지 파일이 존재해야 한다.
- 페이지 파일 크기가 일정 수준 이상이어야 한다.
- 디스크 여유 공간이 덤프를 저장할 만큼 충분해야 한다.
페이지 파일이 “없음”으로 설정되어 있거나, 다른 드라이브에만 존재하는 경우 덤프 파일이 생성되지 않는 사례가 매우 많다.
6.2 페이지 파일 설정 점검 방법
sysdm.cpl> “고급” 탭 > “성능” > “설정” 버튼을 클릭한다.- 성능 옵션 창에서 “고급” 탭을 선택한 후, “가상 메모리” 항목의 “변경”을 클릭한다.
- “모든 드라이브에 대한 페이징 파일 크기 자동 관리”를 체크하는 것이 가장 안전하다.
- 특수한 이유로 수동 설정이 필요한 경우에는 C: 드라이브에 최소 RAM 용량 이상을 확보해야 한다.
주의 : 완전 메모리 덤프를 사용하려면 페이지 파일의 최소 크기가 물리 메모리 크기 이상이어야 한다. 그렇지 않으면 완전 덤프 생성이 실패하고 이벤트 로그에 관련 오류가 기록될 수 있다.
6.3 디스크 여유 공간 확인
대용량 RAM을 사용하는 서버나 워크스테이션에서는 커널 덤프라도 수 GB 이상의 공간을 요구할 수 있다. 최소한 다음 기준을 권장한다.
- 업무용 PC: 시스템 드라이브 여유 공간 30GB 이상 확보한다.
- 서버: 예상되는 최대 덤프 크기 + 20GB 이상 추가 버퍼를 확보한다.
자동 클린업 유틸리티(시스템 정리 도구, 타사 클리너 등)가 TEMP, minidump 폴더, MEMORY.DMP를 자동 삭제하도록 설정되어 있지 않은지도 함께 확인해야 한다.
7. 보안 솔루션·클린업 도구와의 충돌
기업 환경에서는 EDR, 안티바이러스, DLP 등 다양한 보안 솔루션이 설치되어 있다. 일부 솔루션은 시스템 드라이브에 생성되는 대용량 덤프 파일을 다음과 같이 처리할 수 있다.
- 민감정보 유출 방지를 이유로 덤프 파일 생성을 차단한다.
- 실시간 감시에서 의심 파일로 판단하여 즉시 삭제한다.
- 디스크 용량 보호 정책으로 일정 크기 이상의 덤프를 자동 정리한다.
이 경우, 기술 지원 로그에서는 분명히 블루스크린이 발생했는데도 운영자가 확인할 때는 덤프가 존재하지 않는 현상이 반복된다. 이런 상황이라면 보안 솔루션 정책에서 다음 예외를 추가하는 것이 일반적이다.
C:\Windows\MEMORY.DMP파일 경로 예외 처리한다.C:\Windows\Minidump폴더 전체 예외 처리한다.- 필요 시 “크래시 덤프” 유형 파일을 허용하는 정책을 적용한다.
주의 : 보안 정책 변경은 반드시 정보보안 부서 또는 솔루션 담당자와 협의한 후 수행해야 한다. 덤프 파일에는 메모리 내용이 그대로 포함되므로 접근 권한을 최소화하고, 외부 반출 시 암호화 및 폐기 절차를 함께 마련해야 한다.
8. 덤프 생성 여부 검증을 위한 강제 크래시(고급)
실제 장애를 기다리지 않고도 덤프 생성 조건을 검증하고 싶을 때는 강제 크래시를 유도하는 방법을 사용할 수 있다. 이는 매우 위험한 작업이므로, 테스트 환경 또는 필수 자료가 모두 백업된 상태에서만 수행해야 한다.
8.1 키보드 강제 크래시 설정 (USB 키보드)
일부 환경에서는 레지스트리에서 설정을 변경한 후 특정 키 조합으로 강제 블루스크린을 발생시킬 수 있다. 예를 들어 USB 키보드의 경우 다음과 같이 설정할 수 있다.
- 레지스트리 편집기에서 다음 키로 이동한다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters - DWORD 값
CrashOnCtrlScroll을 만들고 값을1로 설정한다. - 재부팅한 뒤, 테스트 시 Ctrl 키를 누른 상태에서 Scroll Lock 키를 두 번 누른다.
정상적으로 설정되었다면 즉시 블루스크린이 발생하고, 재부팅 후 지정된 경로에 메모리 덤프가 생성되어야 한다. 이 과정을 통해 “설정은 되어 있는데 실제로는 덤프가 남지 않는다” 같은 상황을 재현 없이 검증할 수 있다.
주의 : 강제 크래시는 저장되지 않은 작업을 모두 잃게 만들며, 스토리지 상태에 따라 데이터 손상도 발생할 수 있다. 반드시 테스트용 장비에서 수행하고, 운영 서버에는 적용하지 않는 것이 안전하다.
9. 이벤트 로그와 함께 덤프 생성 실패 원인 분석
덤프 생성이 실패하면 윈도우 이벤트 로그에 관련 정보가 남는 경우가 많다. 다음 로그를 함께 확인하면 원인 분석에 도움이 된다.
- 시스템 로그에서 BugCheck 이벤트, 덤프 생성 관련 경고 또는 오류를 확인한다.
- 응용 프로그램 로그에서 보안 솔루션·클린업 도구 등의 삭제 기록을 확인한다.
- Windows Error Reporting 관련 이벤트에서 WER이 덤프를 처리했는지 여부를 확인한다.
로그와 실제 덤프 파일의 존재 여부를 함께 비교하면 다음과 같은 결론을 도출할 수 있다.
- 로그에는 BugCheck와 “덤프 쓰기 시작” 기록이 있는데 파일이 없다면, 보안 솔루션 또는 클린업에 의해 삭제되었을 가능성이 크다.
- 로그에 덤프 쓰기 시도 자체가 없다면 CrashDumpEnabled 값, 페이지 파일 조건, 디스크 여유 공간 문제일 가능성이 높다.
10. PowerShell·명령줄 기반 설정 점검 예시
여러 대의 PC를 동시에 점검해야 하는 환경에서는 GUI보다 명령줄 스크립트가 효율적이다. 다음은 대표적인 확인·설정 예시이다.
10.1 CrashControl 주요 값 확인 스크립트
PowerShell
CrashControl 주요 값 확인
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl"
| Select-Object CrashDumpEnabled, DumpFile, MinidumpDir, Overwrite10.2 디스크 여유 공간 및 페이지 파일 요약 조회
PowerShell
C: 드라이브 여유 공간 확인
Get-PSDrive C
페이지 파일 정보 확인
Get-CimInstance Win32_PageFileUsage | Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage10.3 기본 커널 덤프 설정 적용 예시
여러 PC에 동일한 기본 정책을 적용할 때는 다음과 같이 레지스트리를 일괄 설정할 수 있다.
PowerShell
커널 메모리 덤프 사용
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl"
-Name "CrashDumpEnabled" -Value 2
기본 경로 재지정
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl"
-Name "DumpFile" -Value "%SystemRoot%\MEMORY.DMP"주의 : 스크립트로 레지스트리를 수정하기 전에 테스트용 장비에서 사전 검증을 반드시 수행해야 한다. 잘못된 값은 재부팅 실패, 부팅 루프 등의 심각한 문제를 유발할 수 있다.
11. 실무 운영 관점에서의 메모리 덤프 관리 팁
메모리 덤프는 문제 분석에 매우 유용하지만, 저장 및 보관 정책을 정하지 않으면 디스크를 금방 소모하거나 개인정보 보호 이슈를 야기할 수 있다. 다음과 같은 운영 팁을 고려할 수 있다.
- 서버·핵심 업무 PC는 최소 한 번 이상 실제 덤프가 생성되는지 주기적으로 검증한다.
- 주요 장애 사례의 덤프는 별도 보안 저장소에 암호화하여 보관하고, 분석이 끝난 덤프는 정해진 절차에 따라 삭제한다.
- 장애 재발 가능성이 낮은 경우에는 오래된 덤프를 주기적으로 정리하여 디스크를 확보한다.
- 개인정보가 포함될 수 있으므로 외부에 전달할 때는 NDA(비밀유지계약) 및 처리 범위를 명확히 한다.
- 내부 운영 문서에 “메모리 덤프 생성 조건 및 점검 체크리스트”를 포함하여, 새 담당자가 투입되어도 동일한 절차를 따라갈 수 있도록 한다.
결론적으로, “덤프 파일 생성 안됨” 문제는 단순히 옵션 한두 개를 켜는 수준이 아니라, 설정 값 + 디스크·페이지 파일 조건 + 보안 정책 + 운영 절차를 함께 점검해야 완전히 해결된다. 위 단계들을 체계적으로 점검하면 대부분의 환경에서 안정적으로 메모리 덤프를 확보할 수 있다.
FAQ
Q1. 소형 메모리 덤프와 커널 메모리 덤프 중 무엇을 우선 사용해야 하나?
일반적으로 업무용 PC나 서버에서는 커널 메모리 덤프를 우선 권장한다. 소형 덤프만으로는 복잡한 메모리 손상이나 드라이버 간 상호작용을 분석하기 어렵다. 다만 디스크 용량이 매우 제한된 환경이라면 소형 덤프를 기본으로 두고, 필요 시 추가로 커널 덤프를 요청하는 방식도 가능하다.
Q2. 자동 메모리 덤프와 활성 메모리 덤프는 무엇이 다른가?
자동 메모리 덤프와 활성 메모리 덤프는 윈도우가 상황에 따라 덤프 크기를 자동으로 조절하는 방식이다. 전체 메모리 덤프보다는 작지만, 커널 덤프보다 더 많은 정보를 포함하도록 설계되어 있다. 일반 사용자나 노트북 환경에서는 이 옵션을 기본으로 사용하는 것이 합리적인 선택이다.
Q3. 덤프 파일이 SSD 수명에 나쁜 영향을 주지 않는가?
대형 덤프 파일을 자주 생성하면 SSD에 쓰기 부하가 증가하는 것은 사실이다. 그러나 일반적인 업무 환경에서 블루스크린 발생 빈도가 높지 않다면 실질적인 수명 감소 영향은 제한적인 편이다. 블루스크린이 너무 자주 발생한다면 SSD 수명보다 시스템 안정성 문제가 더 큰 위험이므로, 우선 원인 분석을 통해 장애를 줄이는 것이 중요하다.
Q4. 덤프 파일 저장 위치를 다른 드라이브로 옮겨도 되는가?
레지스트리의 DumpFile 값을 변경하거나 시작 및 복구 설정에서 경로를 바꾸면 다른 드라이브로 덤프를 저장할 수 있다. 다만 페이지 파일과 시스템 드라이브의 특성 때문에, 일부 유형의 덤프에서는 C: 드라이브가 여전히 관여할 수 있다. 운영 절차상 별도 드라이브 사용이 꼭 필요하다면 사전에 충분한 테스트를 수행해야 한다.
Q5. 블루스크린이 떴는데도 이벤트 로그에 BugCheck 이벤트가 없다.
블루스크린처럼 보였지만 실제로는 GPU 드라이버 리셋 또는 펌웨어 수준의 오류일 수도 있다. 이 경우 윈도우가 정상적인 BugCheck 절차를 거치지 않기 때문에 이벤트와 덤프가 남지 않을 수 있다. BIOS·펌웨어 로그, 하드웨어 벤더 진단 도구, 전원 이력 등 다른 자료와 함께 교차 확인하는 것이 필요하다.