Сбор дампов сбоев Windows — введение: WER, ProcDump, WinDbg

Когда Windows-приложение начинает падать «только иногда», одних логов очень часто не хватает, чтобы дойти до причины.

Особенно тяжело вот в таких случаях.

• Сбой бывает только в среде заказчика
• Сообщение об исключении есть, но не хватает контекста о том, откуда был вызов
• Затронуты не только managed-сторона C# / .NET, но и COM, P/Invoke, нативные DLL, SDK поставщика
• Падение случается только после долгой непрерывной работы

Именно здесь помогает дамп сбоя (crash dump). Если записать состояние процесса в момент сбоя в файл, потом можно прочитать код исключения, стек упавшего потока, загруженные модули и часть или всю память.

В Windows проще думать в таком порядке: сначала LocalDumps из WER, при необходимости — Sysinternals ProcDump, а если понадобится ещё больше контроля — MiniDumpWriteDump. В этой статье, ориентируясь на настольные Windows-приложения, постоянно работающие приложения, службы Windows и средства интеграции с оборудованием, разбираем первый шаг сбора дампов сбоев.

flowchart TB
    accTitle: В каком порядке думать о средствах сбора
    accDescr: Сбор дампов сбоев в Windows удобно рассматривать в таком порядке: сначала LocalDumps из WER, при необходимости Sysinternals ProcDump, а если понадобится ещё больше контроля — MiniDumpWriteDump.
    w1["Сначала WER LocalDumps"] --> w2["При необходимости ProcDump"]
    w2 --> w3["Если нужен больший контроль — MiniDumpWriteDump"]

Рис. 1: Начинаем со штатного механизма и добавляем инструменты только там, где его не хватает.

Термины, которые в этой статье будут повторяться

Сначала коротко зафиксируем их. Если оставить это размытым, следующие главы тоже размоются.

1. Сначала вывод

Сначала только то, что стоит удержать с самого начала.

• Разумнее всего настроить WER LocalDumps на уровне приложения. Без дополнительных инструментов после сбоя дамп остаётся локально.
• Для расследования на площадке, где воспроизведение редкое, и если нужно видеть ещё first chance exception / hang, берите ProcDump.
• Собственный сбор стоит оставлять напоследок — примерно такой и должна быть приоритетность. К MiniDumpWriteDump имеет смысл переходить, когда он действительно понадобится.
• Не менее важно, чем сами дампы, хранить PDB и те двоичные файлы, которые вы реально раздавали. Один дамп без символов сильно сужает то, что вообще можно прочитать.
• Полный дамп силён, но столь же сильны его размер и риск, что в него попадут секреты. Место хранения, число копий, права доступа и порядок передачи нужно решить заранее.

На начальном этапе рекомендуемая схема обычно сходится примерно к такому.

Коротко: сначала WER, затем ProcDump, в конце — своя реализация. Если начать в обратном порядке, архитектура почти всегда становится тяжелее, чем нужно.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 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 нужно оставлять до 10 полных дампов в C:\CrashDumps\MyApp, для начала можно настроить так.

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, а не глобальна
• Вывод вынесен в отдельную папку
• Сначала выбран полный дамп
• Число хранимых копий ограничено десятью

4.3 Проверить, что дамп действительно снимается

После настройки безопаснее обязательно один раз довести съём до конца в тестовой среде, а не ждать, пока сбой сам случится в продакшене.

Проверить стоит четыре вещи.

1. Появляется ли .dmp в ожидаемой папке
2. Совпадает ли размер с тем, на что вы рассчитываете в эксплуатации
3. Открывается ли файл в WinDbg
4. Виден ли сбой в журнале Application в Event Viewer

flowchart TB
    accTitle: Как проверять после настройки
    accDescr: После настройки, не дожидаясь естественного сбоя в продакшене, в тестовой среде один раз намеренно вызывают падение и проверяют, появился ли дамп, совпадает ли размер с ожиданием, открывается ли файл в WinDbg и виден ли crash в Event Viewer.
    v1["Внести настройки"] --> v2["Намеренно вызвать сбой в тестовой среде"]
    v2 --> v3["Проверить наличие и размер дампа"]
    v3 --> v4["Проверить, открывается ли в WinDbg"]
    v4 --> v5["Проверить журнал Event Viewer"]

Рис. 5: Не ждать естественного сбоя в продакшене: один раз снять дамп в тестовой среде заранее.

4.4 Минимальный код, чтобы намеренно вызвать сбой

Даже если сказано «доведите съём до конца», ждать настоящего крушения для проверки бессмысленно. Для тестов быстрее завести маленький EXE, который только и делает, что намеренно падает.

На .NET достаточно консольного приложения, которое бросает необработанное исключение. Необработанное managed-исключение в .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 тоже часто упоминают как инструмент «намеренно уронить», но он crash / hang-ает уже саму систему Windows и делает дамп синего экрана, плюс нужны права администратора. Для проверки 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

Снять зависание

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

5.3 Почему не начинать с -i

У ProcDump есть и сценарий с -i: регистрация как postmortem debugger. Это мощно, но затрагивает поведение всей машины в момент сбоя, поэтому как самый первый шаг на начальном этапе это тяжеловато.

Поэтому проще начать либо с настройки WER на уровне приложения, либо с -w / -x / указания PID в ProcDump.

flowchart TB
    accTitle: Почему -i не должен быть первым шагом
    accDescr: Регистрация ProcDump через -i как postmortem debugger мощная, но затрагивает поведение всей машины при сбое, поэтому на начальном этапе проще войти через настройку WER на приложение или через -w, -x и указание PID в ProcDump.
    i1["Регистрация через ProcDump -i"] --> i2["Затрагивает поведение всей машины"]
    i2 -.-> i3["Для первого шага на старте тяжеловато"]
    i4["Сначала — настройка на приложение"] --> i5["WER на уровне приложения"]
    i4 --> i6["ProcDump: -w, -x или PID"]

Рис. 7: Входить лучше с того места, где область действия остаётся на уровне приложения.

6. Как думать о собственном сборе через MiniDumpWriteDump

Собственный сбор уместен, например, в таких ситуациях.

• Из UI нужна кнопка «Сохранить диагностическую информацию»
• Дамп нужно сложить вместе с логами, настройками и trace ID
• Заодно снять связанные дочерние или вспомогательные процессы
• Перед загрузкой нужно своё маскирование или сжатие

Центральный API здесь — MiniDumpWriteDump.

Но у него есть свои особенности. На начальном этапе особенно не стоит пропускать два пункта.

1. По возможности вызывать его из процесса, отличного от того, чей дамп снимаете
2. Семейство API DbgHelp по умолчанию считать single-threaded

flowchart TB
    accTitle: Два пункта, которые нельзя упустить при своём сборе
    accDescr: При своём сборе через MiniDumpWriteDump нельзя упускать два пункта: по возможности вызывать API из процесса, отличного от цели дампа, и считать семейство DbgHelp single-threaded.
    md1["Свой сбор через MiniDumpWriteDump"] --> md2["Вызывать из другого процесса"]
    md1 --> md3["DbgHelp считать single-threaded"]
    md2 -.-> md4["Небрежная реализация сама ломает процесс"]
    md3 -.-> md4

Рис. 8: Особенности своего сбора в основном сводятся к тому, откуда вызывать API и как работать с потоками.

7. Как выбирать минидамп, полный дамп и промежуточный размер

Здесь спотыкаются довольно часто. Практический способ выбора — таблицей.

Рекомендация для старта довольно простая.

• На машине разработчика / тестовой — полный дамп
• В среде заказчика выбирать мини или полный по условиям эксплуатации
• Если подозреваете повреждение памяти, нативные DLL, COM, P/Invoke или аномалии состояния после долгой работы — ближе к полному

flowchart TB
    accTitle: С чего выбирать тип дампа
    accDescr: На машине разработчика и тестовой берут полный дамп, в среде заказчика выбирают мини или полный по условиям эксплуатации, а при подозрении на повреждение памяти, native-границу или аномалии после долгой работы склоняются к полному.
    e1{"В какой среде снимать"}
    e1 -->|"машина разработчика / тестовая"| f1["Полный дамп"]
    e1 -->|"среда заказчика"| f2["По условиям: мини или полный"]
    f2 -.->|"повреждение или native-граница"| f1

Рис. 9: Если сомневаетесь, решайте по среде; чем сильнее подозрение, тем ближе к полному дампу.

7.1 Как на самом деле задают MiniPlus / Custom

У третьей строки таблицы способ указания чуть менее очевиден, поэтому дополним.

Для WER LocalDumps ставят DumpType в 0 (custom) и в 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 MiniPlus — это -mp, custom — -mc <Mask>.

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

MiniPlus по имени звучит «чуть больше мини», а по содержимому довольно близок к полному. По документации он включает всю private-память и всю read/write image / mapped-память, и уже затем ужимает размер, исключая только самую большую private-область, которая превышает 512MB. В итоге это «почти так же подробно, как полный дамп, но размер — 10%–75% от полного».

Есть, однако, два ограничения.

• Для CLR-процесса из-за ограничений отладки даже с -mp снимается полный дамп (-ma). Закладываться на уменьшение размера MiniPlus в .NET-приложении обычно не срабатывает
• Если уменьшать размер хочется затем, чтобы реже тащить секреты, логичнее думать не про MiniPlus, а про сторону минидампа

flowchart TB
    accTitle: Место MiniPlus и его ограничения
    accDescr: MiniPlus включает почти всю private-память и read/write image и mapped-память и ужимает размер, исключая только самую большую private-область свыше 512MB, так что получается 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
• Разделить долгосрочное хранение и первичное

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 не задан, по умолчанию это CrashDumps в LOCALAPPDATA, а сбой службы пишется в папку профиля учётной записи, под которой она работает; если дампа «нет», сначала проверяют эти места.
    fq1["Дамп не находится"] --> fq2{"Как процесс был запущен"}
    fq2 -->|"обычное приложение"| fp1["CrashDumps в LOCALAPPDATA"]
    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 Не проверили ACL папки DumpFolder

У служб и процессов с разделением прав здесь легко промахнуться мимо цели. Сначала стоит проверить, действительно ли этот процесс может туда писать. В 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) наследует ACE файлам внутри, (CI) — вложенным папкам. Область наследования напрямую становится ответом на вопрос «кто может читать дампы», поэтому перед тем как выдавать права, сверьте это с политикой из 8.3.

flowchart TB
    accTitle: Как проверять ACL у DumpFolder
    accDescr: У служб и процессов с разделением прав запись легко промахивается, поэтому сначала смотрят текущий ACL через icacls, при нехватке выдают учётной записи изменение с наследованием и сверяют область наследования с политикой доступа.
    ac1["Смотрим текущий ACL через icacls"] --> ac2{"Может ли писать учётная запись"}
    ac2 -->|"не может"| ac3["Выдать изменение с наследованием"]
    ac2 -->|"может"| ac4["Оставить как есть"]
    ac3 -.-> ac5["Сверить область наследования с политикой доступа"]

Рис. 14: Проверку «можно ли писать» и «кто сможет читать» делают в одном месте.

10.3 Непрерывно писать полные дампы на системный диск рабочей машины

Это классический инцидент с нехваткой места. Ограничение числа копий и отдельный каталог вывода стоит закладывать с самого начала.

10.4 Пытаться закрыть все hang одним только WER

WER LocalDumps в первую очередь силён для crash. Для hang и first chance exception во многих случаях лучше подходит ProcDump.

10.5 Держать -e 1 постоянно и получить шторм исключений

First chance exception полезны, но их обычно очень много. Реалистичный подход — ограничивать число дампов, включать опцию ненадолго и сужать цель.

11. Итог

Дамп сбоя — довольно сильная точка наблюдения для отказов, которые плохо воспроизводятся. Особенно если в Windows-приложении задействованы COM, P/Invoke, нативные 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.

Где настраивается LocalDumps в WER?

В реестре, в разделе HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps. На практике удобнее не глобальная настройка, а подключ на конкретное приложение, например MyApp.exe. Сначала смотрят три значения: DumpFolder (каталог вывода), DumpCount (сколько дампов хранить) и DumpType (тип дампа). Так можно оставлять дамп локально после сбоя, не разнося дополнительные инструменты.

Что выбрать — минидамп или полный дамп?

Ориентир такой: на машине разработчика и на тестовой — полный дамп (DumpType=2), в среде заказчика — минидамп (DumpType=1) или полный, исходя из объёма и требований к конфиденциальности. Если подозреваете повреждение памяти, нативные DLL, COM, P/Invoke или аномалии состояния после долгой работы, выгоднее полный дамп. Но он большой и в него могут попасть строки подключения, токены и прочие секреты, поэтому место хранения, число копий и права доступа нужно решить заранее.

Когда использовать ProcDump?

WER LocalDumps рассчитан в основном на сбои, поэтому ProcDump уместен, когда нужно ещё увидеть hang или first chance exception, не оставлять постоянную настройку в реестре или следить только за уже запущенным процессом. Из типичных опций: -ma (полный дамп), -e (съём при необработанном исключении), -h (обнаружение зависания), -w (ожидание запуска). -e 1, который целится в first chance exception, обычно даёт много срабатываний, поэтому реалистичнее ограничивать число дампов через -n и включать это ненадолго и точечно.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.