WinDBG: отладка и устранение проблем в Windows 10

Введение

Если вы пользователь или администратор Windows 10 и сталкиваетесь с падениями приложений, зависаниями, длительной загрузкой или медленной сетью, WinDBG поможет выявить корень проблемы. Этот материал проведёт вас через настройку, создание дампов, базовый анализ стеков вызовов и дальнейшие действия — в удобном последовательном формате.

Кратко о терминах:

Дамп памяти — файл, содержащий снимок памяти процесса или системы в момент ошибки.
User-mode / kernel-mode — режимы выполнения: пользовательский код и код ядра ОС.

Important: дампы могут содержать личные данные и пароли в памяти. Смотрите раздел «Конфиденциальность» внизу.

Зачем использовать WinDBG

WinDBG даёт детальную информацию, недоступную стандартным инструментам: стек вызовов, состояние потоков, захваченные блокировки, данные драйверов и модули, регистры процессора и содержимое памяти. Это главный инструмент при анализе сложных ошибок, когда простая переустановка или обновление драйвера не помогает.

Подготовка и требования

Установите WinDBG (WinDbg Preview или классический WinDBG) из Microsoft Store или пакета Windows SDK.
Настройте доступ к символам Microsoft Symbol Server (обязательно для корректного анализа стеков).
Выберите режим: локальный анализ дампа, прикрепление к процессу или удалённая отладка.

Совет: для быстрого старта используйте WinDbg Preview из Microsoft Store — он проще в установке и поддерживает UI-улучшения.

Женщина отдыхает возле компьютера

Быстрое руководство: основные сценарии

Аварии приложений (crash): собрать дамп процесса, открыть в WinDBG, запустить анализ и изучить стек.
Зависания (hang): прикрепиться к процессу, проанализировать состояние потоков и захваченные объекты.
Дедлоки: собрать глобальный дамп или использовать инструменты мониторинга потоков и блокировок.
Медленная загрузка / длинный POST: получить дамп при загрузке или использовать отладку по этапам загрузки.
Проблемы сети: собрать дампы сетевого стека/драйверов и посмотреть задержки на уровне драйверов.

Установка WinDBG

Перейдите на сайт Microsoft или откройте Microsoft Store и установите WinDbg Preview.
При необходимости установите Windows SDK, если нужен классический WinDBG из набора инструментов.

Предпросмотр WinDBG в Microsoft Store

Настройка символов (обязательно для корректного анализа)

Символы (PDB-файлы) дают имена функций и параметров в стеке вызовов. Без символов вы увидите только адреса.

В WinDBG выполните:

.symfix srv*c:\symbols*https://msdl.microsoft.com/download/symbols
.reload

Здесь c:\symbols — локальная папка для кеша символов; подставьте путь в соответствии с вашей политикой. Также можно задать символ-сервер в UI: File → Symbol File Path.

Примечание: в корпоративной среде используйте прокси/приватный symbol server при необходимости.

Сценарий: аварии приложения (crash)

Шаг 1 — Убедитесь, что система генерирует дампы

Откройте «Свойства системы» (Windows + R, введите sysdm.cpl). Перейдите на вкладку «Дополнительно» → «Параметры» в блоке «Загрузка и восстановление». В опции «Записывать сведения для отладки» выберите «Полный дамп памяти» или «Дамп памяти рабочего процесса / автоматический дамп» в зависимости от целей.

Локализация UI:

System Properties → Свойства системы
Advanced tab → Вкладка «Дополнительно»
Startup and Recovery → «Загрузка и восстановление»
Write debugging information → «Записывать сведения для отладки»
Complete memory dump → «Полный дамп памяти»

Вкладка «Дополнительно» в свойствах системы

Шаг 2 — Получите дамп

Для user-mode приложения можно настроить «LocalDumps» в реестре, чтобы Windows автоматически сохранял дамп при падении процесса.
Можно также создать дамп вручную через диспетчер задач: правый клик на процессе → «Создать дамп файла».

Шаг 3 — Откройте дамп в WinDBG

File → Open Dump File и укажите .dmp.

Открытие дампа в WinDBG

После загрузки запустите базовый автоматический анализ:

!analyze -v

Это даст initial bugcheck, вероятную ответственную библиотеку или модуль и стек вызовов.

Шаг 4 — Просмотрите стек вызовов

Команда kb покажет стек с параметрами и фреймами:

kb

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

Шаг 5 — Уточняйте информацию

Полезные команды:

lmvm     ; информация о модуле
!analyze -v      ; подробный анализ
.threads         ; список потоков
~* k             ; стеки всех потоков
!handle          ; исследование хендлов

Шаг 6 — Исправление и проверка

После идентификации причины (ошибка памяти, неверное использование API, неправильная работа драйвера) внесите изменения в код или настройки. Пересоберите/обновите и воспроизведите ситуацию. Дамп больше не должен создаваться, и приложение должно работать стабильно.

Зависания (hang) и прикрепление к процессу

Шаг 1 — Прикрепитесь к процессу

File → Attach to a Process и выберите проблемный процесс.

Страница прикрепления к процессу в WinDBG

Шаг 2 — Проанализируйте зависание

Запустите:

!analyze -hang
~* k

Ищите потоки, которые ожидают блокировки, и функции, содержащие блокирующие вызовы (мьютексы, ожидание ввода-вывода, синхронизацию с GUI и т.п.).

Шаг 3 — Найдите причину и исправьте

Идентифицируйте поток-виновник и ресурс, которого он ждёт.
Проверьте использование блокировок: порядок захвата, время удержания, возможность взаимной блокировки (deadlock).
Рассмотрите использование таймаутов, неблокирующих структур данных или переработку логики синхронизации.

Дедлоки: как диагностировать и устранять

Окно Диспетчера задач поверх других окон

Дедлок — ситуация, когда потоки/процессы ждут друг друга бесконечно. Шаги для расследования:

Используйте диспетчер задач / Process Explorer чтобы найти зависшие процессы.
Создайте глобальный дамп или несколько дампов во время проблемы.
В WinDBG используйте команды:

!process 0 0
!thread 
!locks
~* k

Определите граф захвата блокировок: кто держит ресурс, кто ждёт. Часто помогает анализ последовательности захвата мьютексов.
Исправьте порядок захвата, вводите дедлок-безопасные протоколы, таймауты или избегайте вложенных блокировок.

Медленная загрузка и длительное время старта

Конфигурация дампов для проблем при загрузке

Чтобы отлаживать длинную загрузку, полезно получать дампы во время процесса загрузки или сразу после завершения основного цикла инициализации.

Настройте системные дампы (см. раздел «Убедитесь, что система генерирует дампы»).
Если проблема проявляется при конкретном сервисе, используйте дамп-снимок сервиса или инструменты для отладки служб.

Анализ

Откройте дамп в WinDBG и проверьте, какие драйверы/сервисы тратят больше всего времени. Команды:

!analyze -v
lmvm 
!sysinfo smss

Ищите самую «дорогую» инициализацию драйверов, долгие таймауты сети или обращения к недоступным ресурсам.

Медленная сеть: диагностика и WinDBG

Тест скорости интернета с низкой скоростью

Шаги:

Определите симптомы: потеря пакетов, высокая латентность, плохие скорости загрузки/выгрузки.
Соберите сетевые логи, трассировки и дампы сетевого стека/драйверов.
В WinDBG выполните анализ дампа и используйте:

!analyze -v
lmvm

Обновите драйверы сетевой карты, проверьте настройки offload, автоскалирование и антивирусные фильтры, которые могут вмешиваться в сетевой стек.

Чек-листы по ролям

Разработчик:

Собрать минимальный воспроизводимый пример.
Настроить символы и локальный кеш символов.
Сгенерировать дамп и воспроизвести в контролируемой среде.
Проанализировать стек, указать точную строку/модуль, написать юнит/интеграционный тест.

Системный администратор / SRE:

Включить системные дампы и мониторинг доступности.
Настроить централизованный сбор дампов и политику хранения.
Проверить драйверы, прошивки и конфигурации служб.

Служба поддержки:

Снять дамп клиента или получить инструкции по его созданию.
Собрать системные логи и событие из Event Viewer.
Выполнить предварительный анализ и эскалировать разработчикам с описанием и стеком.

Шаблон SOP (операция при получении жалобы на падение приложения)

Получить описание проблемы и шаги для воспроизведения.
Попросить пользователя прислать дамп или создать его вручную.
Проверить наличие последних обновлений ОС и драйверов.
Открыть дамп в WinDBG, запустить !analyze -v.
Сохранить вывод, выгрузить интересующие фреймы/модули.
Сопоставить с исходным кодом/символами, создать задачу разработчикам.
Проверить решение на тестовой машине, закрыть тикет после валидации.

Карта принятия решения (mermaid)

flowchart TD
  A[Поступила жалоба] --> B{Происходит падение или зависание?}
  B -->|Падение| C[Собрать дамп]
  B -->|Зависание| D[Прикрепиться к процессу / собрать дамп]
  C --> E[Открыть в WinDBG]
  D --> E
  E --> F{!analyze -v даёт явную причину?}
  F -->|Да| G[Исправление в коде / обновление драйвера]
  F -->|Нет| H[Глубокий анализ стеков/символов]
  H --> G
  G --> I[Тестирование и валидация]
  I --> J[Закрыть инцидент]

Команды-«шпаргалка» WinDBG

!analyze -v — подробный автоматический анализ.
kb, k, kp — различные варианты просмотра стека.
lm, lmv, lmvm — список модулей и информация.
.symfix и .reload — работа с символами.
~* k — стеки всех потоков.
!locks — анализ захваченных блокировок.
!process и !thread — информация о процессах и потоках.

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

Когда WinDBG может не помочь (ограничения)

Если символы недоступны и код закрыт, анализ может быть неполным.
Некорректные/повреждённые дампы дадут неполные данные.
Проблемы, зависящие от распределённых систем (сеть/серверы) возможны, но требуют дополнительных трассировок вне WinDBG.
Аппаратные проблемы (неисправная память, нестабильный CPU) могут требовать оборудования/BIOS-инструментов.

Альтернативные подходы

ProcDump — для автоматического снятия дампов при падении/зависании.
Windows Performance Recorder (WPR) и Windows Performance Analyzer (WPA) — для анализа производительности и длительных задержек.
Process Explorer и Resource Monitor — для быстрого визуального мониторинга.

Примеры тест-кейсов и критерии приёмки

Тест-кейсы:

Повторяемость падения: до исправления — приложение падает в 3 из 3 попыток по шагам. После — 0 из 10.
Время отклика: до — >5 с, после — <1 с.
Загрузка ЦП/памяти: не превышает допустимые пороги при типичной нагрузке.

Критерии приёмки:

Crash больше не происходит при тех же входных данных и среде.
Нет регрессий в производительности.
Логи и дампы показывают, что прошлый сценарий исправлен.

Конфиденциальность и GDPR — важные заметки

Дампы памяти содержат снимки оперативной памяти, которые могут включать персональные данные, пароли, маркеры сеансов и т.п. Политика обращения с дампами:

Храните дампы в зашифрованном хранилище с ограниченным доступом.
Старайтесь сократить объём сохраняемых данных (минимальные дампы для user-mode процесса).
При передаче дампов третьим лицам удаляйте или маскируйте чувствительные данные, если это возможно.
Выполняйте обработку в рамках юридической политики вашей организации и требований GDPR/локального законодательства.

Безопасность: дополнительные рекомендации

Не открывайте дампы на машинах с доступом в общую сеть без ограничений.
При использовании символов с public symbol server — убедитесь, что политика вашей организации позволяет это.
Проверяйте подписанные драйверы и не доверяйте неподписанным бинарникам в продакшене.

Сводка — как действовать при проблеме

Включите и настройте дампы и символы.
Соберите дамп при воспроизведении ошибки.
Откройте дамп в WinDBG и запустите !analyze -v.
Изучите стеки потоков и идентифицируйте виновный модуль/функцию.
Исправьте код/обновите драйверы/настройки и верифицируйте решение.

Часто задаваемые вопросы (FAQ)

Какой тип дампа выбрать — полный или частичный?

Полный дамп даёт полную информацию, но занимает много места и может содержать чувствительные данные. Для user-mode отладки часто достаточно дампа рабочего процесса (mini-dump с пользовательской информацией). Выбор зависит от необходимой глубины анализа.

Нужно ли всегда настраивать symbol server?

Да — без символов многие стеки будут непонятны. Настройка символов значительно ускоряет и повышает точность анализа.

Можно ли анализировать дампы удалённо?

Да. Обычно дамп передаётся на машину аналитика с WinDBG и локальным кешем символов, либо настраивается удалённый symbol server и приватный storage.

Что делать, если `!analyze -v` не даёт явной причины?

Проверяйте стеки вручную, смотрите все потоки (~* k), исследуйте модули (lmv) и используйте дополнительные инструменты (WPA, ProcDump, логирование).

Как безопасно передавать дамп третьим лицам?

Убедитесь в шифровании передачи, удалении персональных данных, подписанном соглашении об обработке данных и минимально необходимых правах доступа.

Если нужна помощь по конкретному дампу или вы хотите чек-лист для автоматизации процедуры сбора дампов в корпоративной сети — напишите детали: версия ОС, тип приложения (desktop/service/driver) и пример шага воспроизведения. Я подготовлю специализированный playbook и команды для автоматизации.