Windows 크래시 덤프 수집 입문 - WER/ProcDump/WinDbg

Windows 앱에서 「가끔만 죽는다」는 현상이 시작되면, 로그만으로는 따라가기 어려운 장면이 꽤 있습니다.

특히 힘든 것은 이런 경우입니다.

• 고객 환경에서만 발생한다
• 예외 메시지는 잡히지만, 호출 측 문맥이 부족하다
• C# / .NET의 managed 쪽만이 아니라, COM, P/Invoke, native DLL, vendor SDK가 얽힌다
• 장시간 가동 후에만 죽는다

이럴 때 효과가 있는 것이 크래시 덤프입니다. 크래시 시점의 프로세스 상태를 파일로 남겨 두면, 예외 코드, 죽은 스레드의 스택, 로드되어 있던 모듈, 메모리의 일부 또는 전부를 나중에 읽을 수 있습니다.

Windows에서는 먼저 WER의 LocalDumps, 필요하면 Sysinternals ProcDump, 더 세밀하게 제어하고 싶어지면 MiniDumpWriteDump를 쓴다는 순서로 생각하는 것이 이해하기 쉽습니다. 이 글에서는 Windows 데스크톱 앱, 상주 앱, Windows 서비스, 장치 연동 도구 등을 전제로, 크래시 덤프 수집의 첫걸음을 정리합니다.

flowchart TB
    accTitle: 수집 수단을 고민하는 순서
    accDescr: Windows의 크래시 덤프 수집은 먼저 WER의 LocalDumps, 필요하면 Sysinternals의 ProcDump, 더 세밀한 제어가 필요해지면 MiniDumpWriteDump라는 순서로 생각하는 것이 이해하기 쉽다는 점을 보여 주는 그림.
    w1["먼저 WER LocalDumps"] --> w2["필요하면 ProcDump"]
    w2 --> w3["더 제어하고 싶다면 MiniDumpWriteDump"]

그림1: 표준 기능부터 시작하고, 부족한 부분만 도구를 더해 가는 순서.

이 글에서 반복해서 나오는 용어

먼저 짧게 고정해 둡니다. 여기가 모호하면 이후 장이 흐려집니다.

1. 먼저 결론

먼저 잡아 두고 싶은 점만 앞에 늘어놓습니다.

• 우선 WER LocalDumps를 앱 단위로 설정하는 것이 무난합니다. 추가 도구 없이, 크래시 후에 로컬로 덤프를 남길 수 있습니다.
• 재현율이 낮은 현장 조사나, first chance exception / hang까지 보고 싶다면 ProcDump를 씁니다.
• 자체 수집은 마지막에 생각하는 정도가 적당합니다. 필요해진 뒤에 MiniDumpWriteDump를 검토하면 충분합니다.
• 덤프만큼 중요한 것이 PDB와 배포 바이너리의 보관입니다. 덤프만 있어도 심볼이 없으면 읽을 수 있는 양이 꽤 줄어듭니다.
• 풀 덤프는 강하지만, 크기와 기밀 정보 혼입 위험도 강합니다. 보관 위치, 보관 개수, 접근 권한, 공유 절차를 먼저 정합니다.

입문 단계의 권장 구성은 대체로 이 근처에 모입니다.

요컨대 처음은 WER, 다음은 ProcDump, 마지막은 자체 수집입니다. 여기를 역순으로 시작하면 대체로 설계가 무거워집니다.

이 글의 지식 맵

Windows 앱의 크래시 덤프 수집은 추가 도구 없이 앱 단위로 설정할 수 있는 WER LocalDumps를 먼저 넣고, hang이나 first chance exception까지 보고 싶을 때나 이미 기동 중인 프로세스를 감시하고 싶을 때 ProcDump를 더하며, 독자적인 진단 기능이 필요해졌을 때만 MiniDumpWriteDump에 의한 자체 수집을 검토한다는 순서로 생각하는 것이 안전합니다. 덤프의 종류는 미니 덤프와 풀 덤프에서 얻을 수 있는 정보의 깊이와 크기가 트레이드오프가 되며, .NET의 CLR 프로세스는 ProcDump의 MiniPlus 지정에서도 풀 덤프에 상당하는 크기가 됩니다. 저장 위치 폴더의 쓰기 권한을 확인하지 않으면 수집 자체가 헛손질이 되며, 취득한 덤프는 PDB와 조합해 WinDbg로 분석해야 비로소 읽을 수 있는 정보가 됩니다.

flowchart LR
    accTitle: Windows 크래시 덤프 수집(WER/ProcDump/WinDbg)
    accDescr: WER LocalDumps와 ProcDump와 MiniDumpWriteDump가 이 순서로 검토해야 할 크래시 덤프 수집 수단이며, 덤프 종류의 선택, 저장 위치 ACL의 확인, PDB를 동반한 WinDbg에서의 분석까지가 하나로 이어진 흐름임을 보여주는 그림
    wer_localdumps["WER LocalDumps"]
    procdump["ProcDump"]
    windbg["WinDbg"]
    minidumpwritedump["MiniDumpWriteDump"]
    crash_dump["크래시 덤프"]
    minidump["미니덤프"]
    fulldump["풀 덤프"]
    miniplus_dump["MiniPlus 덤프"]
    native_boundary_crash_investigation["네이티브 경계의 원인 조사"]
    dump_folder_acl["덤프 저장 폴더의 ACL"]
    first_chance_exception["first chance exception"]
    second_chance_exception["second chance exception"]
    hang_detection["hang 감지"]
    postmortem_debugger["Postmortem 디버거"]
    pdb["PDB(프로그램 데이터베이스)"]
    custom_diagnostic_report["자체 진단 정보 저장 기능"]
    notmyfault["NotMyFault"]
    wer_localdumps -->|"보다 먼저 해야 한다"| procdump
    procdump -->|"보다 먼저 해야 한다"| minidumpwritedump
    wer_localdumps -->|"구현을 담당한다"| crash_dump
    procdump -->|"구현을 담당한다"| crash_dump
    wer_localdumps -.->|"이용한다"| minidump
    wer_localdumps -.->|"이용한다"| fulldump
    procdump -.->|"이용한다"| fulldump
    procdump -.->|"이용한다"| miniplus_dump
    fulldump -->|"권장되는 대응"| native_boundary_crash_investigation
    minidump -->|"사용은 비권장"| native_boundary_crash_investigation
    wer_localdumps -.->|"전제로 한다"| dump_folder_acl
    procdump -.->|"이용한다"| first_chance_exception
    procdump -.->|"이용한다"| second_chance_exception
    procdump -.->|"이용한다"| hang_detection
    wer_localdumps -->|"사용은 비권장"| hang_detection
    procdump -.->|"구현을 담당한다"| postmortem_debugger
    wer_localdumps -->|"보다 먼저 해야 한다"| postmortem_debugger
    crash_dump -.->|"전제로 한다"| pdb
    crash_dump -->|"에서 확인할 수 있다"| windbg
    minidumpwritedump -->|"권장되는 대응"| custom_diagnostic_report
    notmyfault -->|"사용은 비권장"| wer_localdumps

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 21건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 크래시 덤프로 무엇을 알 수 있는가

크래시 덤프는 「그 순간의 스냅샷」입니다. 감시 카메라라기보다, 사고 현장의 정지 화면에 가깝습니다.

그래서 이런 정보는 꽤 얻기 쉽습니다.

• 어떤 예외 코드로 죽었는가
• 어느 스레드가 죽었는가
• 그 시점의 콜 스택
• 로드되어 있던 모듈
• 얼마나 많은 메모리를 넣었는지에 따라, 힙의 상태나 객체의 내용

한편 덤프만으로는 부족하기 쉬운 것도 있습니다.

• 그 지점까지 이르는 시계열
• 몇 시간 전부터의 증가 경향
• 통신이나 장치와의 외부 상태
• 직전의 입력이나 업무 문맥

그래서 실무에서는 덤프만으로 끝내려고 하지 않고, 로그나 heartbeat와 조합하는 것이 기본입니다.

flowchart TB
    accTitle: 덤프와 로그의 조합
    accDescr: 크래시 덤프는 사고 현장의 정지 화면처럼 그 순간의 상태에 강하고, 그 지점까지 이르는 시계열이나 외부 상태는 로그나 heartbeat가 보완하므로, 둘을 조합해 쓰는 것이 기본임을 보여 주는 그림.
    d1["크래시 덤프〔순간의 정지 화면〕"] --> mix["조합해서 조사한다"]
    d2["로그나 heartbeat〔시계열〕"] --> mix
    d1 -.-> s1["예외 코드나 스택에 강하다"]
    d2 -.-> s2["이르기까지의 경과에 강하다"]

그림2: 정지 화면인 덤프와 시계열인 로그는, 잘하는 분야가 깔끔히 갈린다.

3. 수집 방법의 전체 그림

Windows 앱의 덤프 수집에서, 입문 단계에서 잡아 두고 싶은 방법은 다음 네 가지입니다.

초보자에게 가장 중요한 것은 「무엇으로 받을까」보다 먼저, 「어떤 조건으로」「어디로」「어떤 크기로」받을지를 정하는 것입니다.

flowchart TB
    accTitle: 도구보다 먼저 정할 것
    accDescr: 크래시 덤프 수집에서는 어떤 조건으로, 어디로, 어떤 크기로 받을지를 먼저 정한 뒤에, 무엇으로 받을까라는 도구 선택으로 나아가는 것이 중요함을 보여 주는 그림.
    c1["어떤 조건으로 받을까"] --> firstq["먼저 정하는 세 가지"]
    c2["어디로 낼까"] --> firstq
    c3["어떤 크기로 받을까"] --> firstq
    firstq --> tool["그다음에 도구를 고른다"]

그림3: 조건, 출력 위치, 크기를 정한 뒤라면, 도구 선택은 헤매지 않는다.

4. 첫 권장은 WER LocalDumps

4.1 먼저 볼 레지스트리 값

Windows Error Reporting(WER)에는, 크래시 후에 로컬로 사용자 모드 덤프를 저장하는 LocalDumps가 있습니다. 추가 도구를 배포하지 않아도 되므로, 첫 조치로 꽤 다루기 쉽습니다.

기본 키는 여기입니다.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

여기에 전역 설정을 둘 수도 있지만, 실무에서는 앱 단위 서브키로 모으는 편이 다루기 쉽습니다.

flowchart TB
    accTitle: LocalDumps 설정의 두는 곳
    accDescr: LocalDumps 키 바로 아래에 전역 설정을 둘 수도 있지만, 실무에서는 MyApp.exe처럼 앱 단위 서브키로 모으는 편이 다루기 쉽다는 점을 보여 주는 그림.
    key1["LocalDumps 키"] --> g1["바로 아래의 전역 설정"]
    key1 --> a1["앱 단위 서브키"]
    a1 -.-> a2["실무에서는 이쪽이 다루기 쉽다"]

그림4: 같은 키라도, 앱 이름 서브키로 모으면 영향 범위를 좁힐 수 있다.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe

먼저 볼 값은 세 가지입니다.

4.2 앱 단위로 설정하는 예

예를 들어 MyApp.exe에 대해, C:\CrashDumps\MyApp에 풀 덤프를 최대 10개 남기고 싶다면, 우선 다음과 같이 설정할 수 있습니다.

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpFolder /t REG_EXPAND_SZ /d "C:\CrashDumps\MyApp" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpCount /t REG_DWORD /d 10 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpType /t REG_DWORD /d 2 /f

이 예의 포인트는 네 가지입니다.

• 전역이 아니라 MyApp.exe로 한정하고 있다
• 출력 위치를 전용 폴더로 분리하고 있다
• 우선 풀 덤프로 두고 있다
• 보관 개수를 10으로 제한하고 있다

4.3 받아졌는지 확인한다

설정을 넣었으면, 운영에서 자연 발생을 기다리기 전에 검증 환경에서 반드시 한 번은 받아 내는 편이 안전합니다.

확인하고 싶은 것은 이 네 가지입니다.

1. 예상한 폴더에 .dmp가 나오는가
2. 크기가 운영 예상과 맞는가
3. WinDbg로 열리는가
4. Event Viewer의 Application 로그에서 crash가 보이는가

flowchart TB
    accTitle: 설정 후 검증의 흐름
    accDescr: 설정을 넣었으면 운영에서 자연 발생을 기다리기 전에 검증 환경에서 반드시 한 번 받아 내고, 폴더에 덤프가 나오는지, 크기가 예상과 맞는지, WinDbg로 열리는지, Event Viewer에서 crash가 보이는지를 확인하는 흐름을 보여 주는 그림.
    v1["설정을 넣는다"] --> v2["검증 환경에서 일부러 죽인다"]
    v2 --> v3["덤프 유무와 크기를 확인한다"]
    v3 --> v4["WinDbg로 열리는지 확인한다"]
    v4 --> v5["Event Viewer 로그를 확인한다"]

그림5: 운영의 자연 발생을 기다리기 전에, 검증 환경에서 한 번 받아 낸다.

4.4 일부러 죽이기 위한 최소 코드

「받아 낸다」고 해도, 진짜 크래시를 기다려서는 검증이 되지 않습니다. 검증용으로 의도적으로 죽기만 하는 작은 EXE를 준비해 두면 빠릅니다.

.NET이라면, 미처리 예외만 던지는 콘솔 앱으로 충분합니다. .NET의 매니지드 미처리 예외는 프로세스를 종료시키므로, 그대로 WER 대상이 됩니다.

// CrashTest.csproj: <TargetFramework>net8.0</TargetFramework>
using System;
using System.Threading;

internal static class Program
{
    private static void Main()
    {
        Console.WriteLine($"PID={Environment.ProcessId} / 3초 후에 죽입니다.");
        Thread.Sleep(3000);

        throw new InvalidOperationException("intentional crash for dump collection test");
    }
}

네이티브 쪽을 확인하고 싶다면, 액세스 위반(0xC0000005)을 일으키는 편이 가깝습니다. 최적화로 사라지지 않도록 volatile을 붙입니다.

// crash_test.cpp / C++17 / MSVC
int main()
{
    volatile int* p = nullptr;
    *p = 1;  // 여기서 STATUS_ACCESS_VIOLATION이 발생합니다
    return 0;
}

여기서 하나만, 빠지기 쉬운 점이 있습니다. LocalDumps의 서브키 이름은, 지금 죽이는 EXE의 파일 이름과 일치해야 합니다. MyApp.exe 키만 만들어 CrashTest.exe를 죽여도, 당연히 덤프는 나오지 않습니다. 검증 때는 CrashTest.exe 키를 일시적으로 만들거나, 전역 설정 쪽에서 시험하는 쪽 중 하나로 합니다.

flowchart TB
    accTitle: 서브키 이름 일치라는 함정
    accDescr: LocalDumps의 서브키 이름은 지금 죽이는 EXE의 파일 이름과 일치하지 않으면 덤프가 나오지 않으므로, 검증 때는 CrashTest.exe 키를 일시적으로 만들거나 전역 설정 쪽에서 시험함을 보여 주는 그림.
    t1["MyApp.exe 키만 만든다"] --> t2["CrashTest.exe를 죽인다"]
    t2 --> t3["덤프는 나오지 않는다"]
    t3 -.-> t4["키 이름은 죽이는 EXE 이름과 일치시킨다"]

그림6: 서브키 이름과 EXE 이름의 어긋남은, 검증이 헛도는 단골 함정.

Sysinternals의 NotMyFault도 「일부러 죽이기」위한 도구로 자주 거론되지만, 이것은 Windows 시스템 자체를 crash / hang시켜 블루스크린 덤프를 만들기위한 것이고, 관리자 권한도 필요합니다. 사용자 모드 앱의 LocalDumps 검증에는, 위와 같은 자체 작은 EXE가 더 안전하고 확실합니다.

5. ProcDump를 쓰는 장면

WER로 충분한 경우가 많지만, ProcDump가 편리한 장면도 있습니다.

• 레지스트리에 상시 설정을 두고 싶지 않다
• 이미 실행 중인 프로세스만 감시하고 싶다
• 다음 시작부터만 감시하고 싶다
• first chance exception을 보고 싶다
• hang을 받고 싶다
• 성능 카운터나 조건부 수집을 하고 싶다

5.1 자주 쓰는 옵션

입문 단계에서 자주 쓰는 것만 추리면, ProcDump는 다음을 기억해 두면 실무에서 꽤 쓸 수 있습니다.

5.2 대표적인 명령 예

이미 실행 중인 프로세스를, 미처리 예외에서 풀 덤프

procdump -accepteula -ma -e 1234 C:\CrashDumps\MyApp

다음 시작을 기다려, 미처리 예외에서 풀 덤프

procdump -accepteula -ma -e -w MyApp.exe C:\CrashDumps\MyApp

직접 시작해서, 그대로 감시

procdump -accepteula -ma -e -x C:\CrashDumps\MyApp MyApp.exe

first chance exception도 받고 싶다

procdump -accepteula -ma -n 3 -e 1 MyApp.exe C:\CrashDumps\MyApp

hang을 받고 싶다

procdump -accepteula -h MyApp.exe C:\CrashDumps\MyApp

5.3 -i를 첫 조치로 쓰지 않는 이유

ProcDump에는 -i로 postmortem debugger로 등록하는 쓰임새도 있습니다. 이것은 강력하지만, 머신 전체의 크래시 시 동작에 손을 대는 것이므로, 입문 단계의 첫 조치로는 조금 무겁습니다.

그래서 처음은 WER의 앱 단위 설정이나, ProcDump의 -w / -x / PID 지정부터 들어가는 편이 다루기 쉽습니다.

flowchart TB
    accTitle: -i를 첫 조치로 쓰지 않는 이유
    accDescr: ProcDump의 -i는 postmortem debugger로 등록하는 강력한 쓰임새이지만, 머신 전체의 크래시 시 동작에 손을 대므로, 입문 단계는 WER의 앱 단위 설정이나 ProcDump의 -w나 -x나 PID 지정부터 들어가는 편이 다루기 쉽다는 점을 보여 주는 그림.
    i1["ProcDump의 -i로 등록"] --> i2["머신 전체 동작에 손을 댄다"]
    i2 -.-> i3["입문의 첫 조치로는 무겁다"]
    i4["처음은 앱 단위 설정"] --> i5["WER의 앱 단위 설정"]
    i4 --> i6["ProcDump의 -w나 -x나 PID 지정"]

그림7: 영향 범위가 앱 단위로 남는 입구부터 시작한다.

6. 자체 수집에서 MiniDumpWriteDump를 쓸 때의 접근

자체 수집이 맞는 것은, 예를 들어 이런 장면입니다.

• UI에서 「진단 정보 저장」 버튼을 내고 싶다
• 덤프와 함께 로그, 설정, 트레이스 ID를 묶고 싶다
• 관련된 자식 프로세스나 보조 프로세스도 모으고 싶다
• 업로드 전에 자체 마스킹이나 압축을 넣고 싶다

여기서 중심이 되는 API가 MiniDumpWriteDump입니다.

다만 여기는 조금 까다로운 점이 있습니다. 입문에서 특히 놓치고 싶지 않은 것은 다음 두 가지입니다.

1. 가능하면 dump 대상과는 별도 프로세스에서 호출한다
2. DbgHelp 계열은 single-threaded 전제로 다룬다

flowchart TB
    accTitle: 자체 수집에서 놓치고 싶지 않은 두 가지
    accDescr: MiniDumpWriteDump에 의한 자체 수집에서는, 가능하면 dump 대상과는 별도 프로세스에서 호출할 것과, DbgHelp 계열을 single-threaded 전제로 다룰 것 두 가지를 빠뜨리지 않도록 함을 보여 주는 그림.
    md1["MiniDumpWriteDump로 자체 수집"] --> md2["별도 프로세스에서 호출한다"]
    md1 --> md3["DbgHelp는 single-threaded 전제"]
    md2 -.-> md4["대충 구현하면 오히려 깨진다"]
    md3 -.-> md4

그림8: 자체 수집의 까다로운 점은, 호출하는 곳과 스레드 두 가지로 모인다.

7. 미니 덤프 / 풀 덤프 / 중간 크기 고르는 법

여기서 헤매는 사람은 꽤 많습니다. 실무에서의 고르는 법을 표로 둡니다.

초보자용 권장은 꽤 단순합니다.

• 개발기 / 검증기에서는 풀 덤프
• 고객 환경에서는 미니나 풀을 운영 조건으로 고른다
• 메모리 파괴, 네이티브 DLL, COM, P/Invoke, 장시간 가동 후의 상태 이상이 의심되면 풀 쪽

flowchart TB
    accTitle: 덤프 종류의 우선 고르는 법
    accDescr: 개발기나 검증기에서는 풀 덤프, 고객 환경에서는 운영 조건으로 미니나 풀을 고르고, 메모리 파괴나 네이티브 경계, 장시간 가동 후의 상태 이상이 의심되면 풀 쪽으로 한다는 고르는 법을 보여 주는 그림.
    e1{"어느 환경에서 받을까"}
    e1 -->|"개발기 / 검증기"| f1["풀 덤프"]
    e1 -->|"고객 환경"| f2["운영 조건으로 미니나 풀"]
    f2 -.->|"파괴가 의심되거나 네이티브 경계"| f1

그림9: 헤매면 환경으로 정하고, 의심이 짙을수록 풀 쪽으로 모은다.

7.1 MiniPlus / Custom은, 실제로는 어떻게 지정하는가

표의 3행만, 지정 방법이 조금 알기 어려우므로 보충합니다.

WER LocalDumps의 경우는, DumpType을 0(커스텀)으로 한 다음, CustomDumpFlags에 MINIDUMP_TYPE의 비트 조합을 넣습니다. CustomDumpFlags는 DumpType=0일 때만 쓰이는 값이고, 기본값은 0x00000121(MiniDumpWithDataSegs MiniDumpWithUnloadedModules MiniDumpWithProcessThreadData의 조합)입니다.

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpType /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v CustomDumpFlags /t REG_DWORD /d 0x121 /f

ProcDump의 경우는, -mp가 MiniPlus, -mc <Mask>가 커스텀입니다.

procdump -accepteula -mp -e MyApp.exe C:\CrashDumps\MyApp

MiniPlus는, 이름에 비해 내용이 꽤 풀에 가깝습니다. 문서에 따르면, private 메모리 전부와, read/write인 image / mapped 메모리 전부를 포함하고, 그다음에 512MB를 넘는 최대 private 영역만 제외해서 크기를 줄입니다. 결과적으로 「풀 덤프만큼 자세하지만, 크기는 풀의 10%〜75%」라는 위치가 됩니다.

다만 주의점이 두 가지 있습니다.

• CLR 프로세스는 디버깅상의 제약으로, -mp를 지정해도 풀(-ma)로 수집됩니다. .NET 앱에서 MiniPlus의 크기 축소를 기대하는 것은, 대개 빗나갑니다
• 크기를 줄이려는 동기가 「기밀 정보 혼입을 줄이고 싶다」라면, MiniPlus가 아니라 미니 덤프 쪽으로 생각하는 편이 맞습니다

flowchart TB
    accTitle: MiniPlus의 위치와 제약
    accDescr: MiniPlus는 private 메모리 전부와 read/write인 image나 mapped 메모리를 포함하고, 512MB를 넘는 최대 private 영역만 제외해서 풀의 10%에서 75% 정도 크기에 들어가지만, CLR 프로세스에서는 -mp를 지정해도 풀로 수집됨을 보여 주는 그림.
    mp1["MiniPlus로 수집"] --> mp2["private 메모리는 거의 전부 포함"]
    mp2 --> mp3["거대한 private 영역만 제외"]
    mp3 --> mp4["풀보다 작고 자세하다"]
    mp1 -.->|"CLR 프로세스인 경우"| mp5["풀로 수집된다"]

그림10: MiniPlus는 내용이 풀에 가깝고, .NET 앱에서는 크기 축소가 먹지 않는다.

8. 운영에서 먼저 정해 둘 것

덤프 수집은, 구현보다 운영에서 실패하는 경우가 꽤 있습니다. 먼저 정해 두고 싶은 것을 듭니다.

8.1 PDB와 바이너리를 어떻게 남길 것인가

이것이 가장 중요합니다.

• 배포한 EXE / DLL의 정확한 버전
• 그 버전에 대응하는 PDB
• 어느 커밋 / 어느 빌드 파이프라인에서 만들었는가
• 설치 프로그램이나 배포물의 버전 정보

8.2 어디로 내고, 몇 개 남길 것인가

풀 덤프는 꽤 커집니다. 출력 위치와 보관 방침은 처음부터 정해 두는 편이 안전합니다.

• 시스템 드라이브 바로 아래에 그대로 두지 않는다
• 전용 폴더로 분리한다
• DumpCount나 -n으로 상한을 자른다
• 장기 보관과 1차 보관을 나눈다

8.3 누가 봐도 되는가

풀 덤프에는, 기밀 정보나 개인 정보가 섞일 가능성이 있습니다.

• 평문 설정
• 연결 문자열
• 토큰이나 자격 증명
• 직전에 다루던 업무 데이터
• 파일 경로나 사용자 이름

그래서 「받는」 설계와 동시에 「누가 만져도 되는가」도 정해야 합니다.

flowchart TB
    accTitle: 운영에서 먼저 정하는 세 가지
    accDescr: 크래시 덤프 수집은 구현보다 운영에서 실패하기 쉬우므로, PDB와 바이너리 보관, 출력 위치와 보관 개수, 누가 봐도 되는가라는 접근 방침을 먼저 정해 둘 것을 보여 주는 그림.
    op1["PDB와 바이너리 보관"] --> op4["먼저 정해 둔다"]
    op2["출력 위치와 보관 개수"] --> op4
    op3["누가 봐도 되는가"] --> op4
    op4 -.-> op5["구현보다 운영에서 실패하기 쉽다"]

그림11: 덤프 수집의 실패는, 대개 운영 결정 사항의 부족에서 온다.

9. 받은 뒤의 최단 분석 흐름

덤프를 받은 뒤, 먼저 할 일은 의외로 소박합니다.

9.1 WinDbg를 설치한다

지금의 WinDbg는 Microsoft Store나 winget으로 설치하기 쉬워져 있습니다.

winget install Microsoft.WinDbg

9.2 덤프를 연다

windbg -z C:\CrashDumps\MyApp\MyApp_YYMMDD_HHMMSS.dmp

여기 파일 이름은 ProcDump가 붙이는 기본 이름입니다. ProcDump의 기본 파일 이름은 PROCESSNAME_YYMMDD_HHMMSS.dmp이고, PROCESSNAME / PID / EXCEPTIONCODE / YYMMDD / HHMMSS를 치환 토큰으로 쓸 수 있습니다.

한편 WER LocalDumps는 ProcDump와는 다른 이름 규칙으로 파일을 만듭니다. 이름 규칙은 Microsoft Learn에 명시되어 있지 않으므로, 이름을 추측해서 찾기보다 출력 폴더를 수정 일시 순으로 보는 편이 확실합니다.

dir /o-d "C:\CrashDumps\MyApp\*.dmp"

DumpFolder를 설정하지 않은 경우, 기본 출력 위치는 %LOCALAPPDATA%\CrashDumps입니다. 다만 서비스의 크래시는 실행 계정마다의 프로필 폴더로 나갑니다. System 서비스라면 %WINDIR%\System32\Config\SystemProfile, Network Service / Local Service라면 %WINDIR%\ServiceProfiles 아래입니다. 「덤프가 안 나왔다」고 생각하면, 먼저 여기를 의심합니다.

flowchart TB
    accTitle: 덤프가 안 보일 때의 찾는 곳
    accDescr: DumpFolder를 설정하지 않은 경우의 기본은 LOCALAPPDATA 아래 CrashDumps이고, 서비스 크래시는 실행 계정마다의 프로필 폴더로 나가므로, 안 나왔다고 생각하면 그곳을 의심함을 보여 주는 그림.
    fq1["덤프가 안 보인다"] --> fq2{"어떤 형태로 돌고 있었는가"}
    fq2 -->|"일반 앱"| fp1["LOCALAPPDATA 아래 CrashDumps"]
    fq2 -->|"서비스"| fp2["실행 계정의 프로필 아래"]
    fp2 -.-> fp3["SystemProfile이나 ServiceProfiles"]

그림12: 기본 출력 위치는 계정마다 다르므로, 찾는 곳부터 의심한다.

9.3 심볼을 설정한다

먼저 Microsoft 공개 심볼을 쓸 수 있는 상태로 만들고, 그다음에 자신의 PDB 위치를 더합니다.

.symfix C:\Symbols\Microsoft
.sympath+ C:\Symbols\MyApp
.reload

9.4 먼저 자동 분석을 본다

!analyze -v

그다음에,

• 어떤 예외 코드인가
• faulting module은 무엇인가
• 자신의 코드가 어디까지 스택에 보이는가
• 예외 스레드 이외에 의심스러운 대기나 막힘이 없는가

를 차례로 봅니다.

flowchart TB
    accTitle: 받은 뒤의 최단 분석 흐름
    accDescr: WinDbg를 설치하고, 덤프를 열고, Microsoft 공개 심볼과 자신의 PDB를 설정하고, 먼저 analyze -v의 자동 분석을 본 뒤에, 예외 코드나 faulting module, 자신의 코드가 어디까지 보이는지, 다른 스레드의 막힘을 차례로 확인하는 흐름을 보여 주는 그림.
    an1["WinDbg를 설치한다"] --> an2["덤프를 연다"]
    an2 --> an3["심볼과 PDB를 설정한다"]
    an3 --> an4["먼저 자동 분석을 본다"]
    an4 --> an5["예외 코드와 스택을 차례로 읽는다"]

그림13: 열고, 심볼을 연결하고, 자동 분석부터 읽기 시작하는 것이 최단.

10. 흔한 함정

10.1 덤프는 받았지만, PDB가 없다

이것은 꽤 많습니다. 덤프 수집은 성공했어도, 읽을 재료가 부족합니다. 수집 설정과 같은 타이밍에, PDB 보관 설계도 넣는 편이 좋습니다.

10.2 DumpFolder의 ACL을 보지 않는다

서비스나 권한이 분리된 프로세스에서는, 여기서 헛돌기 쉽습니다. 「그 프로세스가 정말로 쓸 수 있는가」를 먼저 확인합니다. Microsoft Learn도, 기본값이 아닌 경로를 쓴다면 「크래시한 프로세스가 쓸 수 있는 ACL인지」를 확인하라고 적고 있습니다.

지금 ACL은 icacls로 볼 수 있습니다.

icacls C:\CrashDumps\MyApp

쓰기 권한이 부족하면, 실행 계정에 M(변경)을 더합니다. 덤프 폴더는 하위 파일에도 같은 권한이 필요하므로, (OI)와 (CI)를 붙여 상속시킵니다.

rem 예: Network Service로 도는 서비스의 경우
icacls C:\CrashDumps\MyApp /grant "NT AUTHORITY\NETWORK SERVICE:(OI)(CI)M"

(OI)는 하위 파일로, (CI)는 하위 폴더로 ACE를 상속시키는 지정입니다. 상속 범위가 그대로 「누가 덤프를 읽을 수 있는가」가 되므로, 8.3에서 정한 방침과 어긋나지 않는지, 붙이기 전에 한 번 확인합니다.

flowchart TB
    accTitle: DumpFolder ACL 확인의 흐름
    accDescr: 서비스나 권한이 분리된 프로세스에서는 쓰기로 헛돌기 쉬우므로, icacls로 지금 ACL을 확인하고, 부족하면 실행 계정에 상속 포함 변경 권한을 부여하며, 그 상속 범위를 열람 방침과 맞추는 흐름을 보여 주는 그림.
    ac1["icacls로 지금 ACL을 본다"] --> ac2{"실행 계정은 쓸 수 있는가"}
    ac2 -->|"쓸 수 없다"| ac3["상속을 붙여 변경 권한을 부여"]
    ac2 -->|"쓸 수 있다"| ac4["그대로 운영"]
    ac3 -.-> ac5["상속 범위는 열람 방침과 맞춘다"]

그림14: 쓸 수 있는지의 확인과, 누가 읽을 수 있는지의 확인은 같은 자리에서 끝낸다.

10.3 풀 덤프를 운영 장비의 시스템 드라이브에 계속 저장한다

이것은 용량 사고의 단골입니다. 보관 개수 제한과 출력 위치 분리는 처음부터 넣습니다.

10.4 WER만으로 hang도 전부 보려고 한다

WER LocalDumps는 우선 crash에 강합니다. hang이나 first chance exception은 ProcDump가 더 맞는 장면이 있습니다.

10.5 -e 1을 상시 넣어, 예외 폭풍이 된다

first chance exception은 편리하지만, 원래 많습니다. 건수 제한을 붙이고, 짧은 시간만 넣고, 대상을 한정하는 것이 현실적입니다.

11. 정리

크래시 덤프는, 재현율이 낮은 장애에 대해 꽤 강한 관측점입니다. 특히 Windows 앱에서 COM, P/Invoke, native DLL, 장시간 가동이 얽히면, 처음부터 「죽으면 무엇이 남는가」를 정해 둘 가치가 있습니다.

권장 순서는 단순합니다.

1. 먼저 WER LocalDumps를 앱 단위로 넣는다
2. 필요하면 ProcDump를 더한다
3. 더 제어하고 싶어지면, 별도 프로세스 전제로 MiniDumpWriteDump를 쓴다

이 순서로 진행하면, 크게 빗나가기 어렵습니다.

12. 참고 자료

• 사용자 모드 덤프 수집 - Win32 apps | Microsoft Learn
• ProcDump v11.1 - Sysinternals | Microsoft Learn
• MiniDumpWriteDump function (minidumpapiset.h) - Win32 | Microsoft Learn
• User-mode dump files - Windows drivers | Microsoft Learn
• 사용자 모드 덤프 파일 분석 - Windows drivers | Microsoft Learn
• Windows 디버거 설치 - Windows drivers | Microsoft Learn
• Symbol path for Windows debuggers - Windows drivers | Microsoft Learn
• !analyze (WinDbg) - Windows drivers | Microsoft Learn
• Troubleshoot processes by using Task Manager - Windows Server | Microsoft Learn
• Enabling Postmortem Debugging - Windows drivers | Microsoft Learn
• MINIDUMP_TYPE enumeration (minidumpapiset.h) - Win32 | Microsoft Learn
• icacls - Windows commands | Microsoft Learn
• NotMyFault - Sysinternals | Microsoft Learn

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

크래시 덤프란 무엇인가요? 무엇을 알 수 있나요?

크래시가 난 순간의 프로세스 상태를 파일로 저장한 것으로, 사고 현장의 정지 화면과 같은 스냅샷입니다. 예외 코드, 죽은 스레드와 그 콜 스택, 로드되어 있던 모듈, 포함한 메모리 양에 따라 힙의 객체 내용까지 나중에 확인할 수 있습니다. 한편 그 지점까지 이르는 시계열이나 통신·장치와의 외부 상태는 부족하기 쉬우므로, 실무에서는 로그나 heartbeat와 함께 쓰는 것이 기본입니다.

WER의 LocalDumps는 어디에 설정하나요?

레지스트리의 HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps 아래에서 설정합니다. 실무에서는 전역 설정이 아니라 MyApp.exe처럼 앱 단위 서브키로 모으는 편이 다루기 쉽습니다. 먼저 볼 값은 출력 위치 DumpFolder, 보관 개수 DumpCount, 종류 DumpType 세 가지이며, 추가 도구를 배포하지 않고도 크래시 후 덤프를 로컬에 남길 수 있습니다.

미니 덤프와 풀 덤프 중 어느 쪽을 골라야 하나요?

개발기·검증기에서는 풀 덤프(DumpType=2), 고객 환경에서는 용량과 기밀 요건을 보고 미니 덤프(DumpType=1)나 풀 덤프를 고르는 것이 기준입니다. 메모리 파괴, 네이티브 DLL, COM, P/Invoke, 장시간 가동 후의 상태 이상이 의심되면 풀 덤프 쪽이 유리합니다. 다만 풀 덤프는 크기가 크고 연결 문자열이나 토큰 같은 기밀 정보가 섞일 위험도 있으므로, 보관 위치·보관 개수·접근 권한을 먼저 정해 두어야 합니다.

ProcDump는 어떤 때 쓰나요?

WER LocalDumps는 기본적으로 크래시용이라, hang이나 first chance exception까지 보고 싶을 때, 레지스트리에 상시 설정을 두고 싶지 않을 때, 이미 실행 중인 프로세스만 감시하고 싶을 때 ProcDump가 맞습니다. 대표적인 옵션은 풀 덤프의 -ma, 미처리 예외 수집 -e, hang 검출 -h, 시작 대기 -w 등입니다. first chance exception을 대상으로 하는 -e 1은 건수가 많아지기 쉬우므로, -n으로 상한을 두는 등 짧은 시간·한정적으로 쓰는 것이 현실적입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.