Синий экран смерти с кодом IRQL_NOT_LESS_OR_EQUAL или PAGE_FAULT_IN_NONPAGED_AREA — типичная причина, по которой открывают WinDbg: минидамп из папки C:\Windows\Minidump хранит состояние системы в момент сбоя, и отладчик позволяет выяснить, какой драйвер или модуль спровоцировал падение. Без анализа дампа приходится действовать вслепую — менять память, драйверы и настройки наугад.
WinDbg — официальный отладчик от Microsoft, который входит в комплект Debugging Tools for Windows. Он работает в двух режимах: анализ файлов дампа (постмортем-отладка) и живая отладка ядра или пользовательских приложений. В этой статье разберём установку, настройку символов, базовые команды и типовой сценарий разбора дампа после BSOD.
Установка WinDbg
Существует две версии отладчика: классическая WinDbg (входит в Windows SDK и WDK) и современная WinDbg Preview, доступная в Microsoft Store. Для большинства задач по анализу дампов удобнее Preview-версия — у неё обновлённый интерфейс, подсветка синтаксиса и встроенная поддержка скриптов. Классический вариант пригодится, если нужна совместимость со старыми сценариями или специфическими расширениями.
При установке через Windows SDK достаточно отметить только компонент Debugging Tools for Windows — остальные части SDK для отладки не нужны и занимают лишнее место. После установки отладчик запускается из меню «Пуск» или напрямую исполняемым файлом.
Настройка путей к символам
Без символов отладки (файлов .pdb) WinDbg покажет только адреса в памяти вместо читаемых имён функций и модулей. Это самая частая причина «бессмысленного» вывода у новичков. Microsoft предоставляет публичный сервер символов, и отладчик умеет подгружать их автоматически.
Путь к символам задаётся через меню File → Settings → Debugging settings в Preview-версии или File → Symbol File Path в классической. Стандартная строка выглядит так:
SRV*C:\Symbols*https://msdl.microsoft.com/download/symbolsЗдесь C:\Symbols — локальный кэш, куда скачиваются символы, чтобы не загружать их повторно. Папку нужно создать заранее и убедиться, что у системы есть доступ в интернет при первом анализе.
⚠️ Внимание: если вывод команды анализа состоит из нечитаемых адресов и строк вида «symbols not found», сначала проверьте настройку путей к символам и доступность интернета — без символов выводы отладчика делать нельзя.
Открытие и анализ дампа памяти
Файлы минидампов сохраняются в C:\Windows\Minidump, а полный дамп ядра — в C:\Windows\MEMORY.DMP. Чтобы открыть дамп, используйте File → Open dump file и укажите нужный файл. Если папка Minidump пуста, проверьте настройки: Система → Дополнительные параметры системы → Загрузка и восстановление — там должен быть включён хотя бы малый дамп памяти.
После загрузки дампа ключевое действие — команда автоматического анализа:
!analyze -vКоманда !analyze -v выводит код ошибки (bug check code), её параметры, стек вызовов в момент сбоя и самое главное — строку IMAGE_NAME или MODULE_NAME, указывающую на вероятный виновный модуль. Если там фигурирует файл драйвера с расширением .sys (например, драйвер видеокарты, антивируса или сетевого фильтра), это отправная точка для дальнейшей диагностики.
☑️ Первичный анализ дампа после BSOD
Основные команды WinDbg
Помимо автоматического анализа, полезно знать базовые команды ручной отладки. Они вводятся в командную строку в нижней части окна отладчика.
| Команда | Назначение |
|---|---|
!analyze -v | Автоматический подробный анализ дампа |
lm | Список загруженных модулей и драйверов |
k / kb | Показать стек вызовов текущего потока |
!process 0 0 | Список процессов в момент сбоя |
lmvm имя_модуля | Подробная информация о модуле: версия, дата, путь |
Команда lmvm особенно полезна: по дате сборки драйвера можно понять, насколько он устарел. Старые драйверы сторонних утилит (например, от программ разгона, VPN или виртуализации) — частые кандидаты на роль источника сбоя.
- 🔍
!analyze -v— всегда первая команда при открытии дампа - 📋
lm t n— список модулей, отсортированный по имени - 🧵
!thread— информация о потоке, вызвавшем исключение - 💾
dd / dq— просмотр содержимого памяти по адресу
Интерпретация результатов анализа
Вывод !analyze -v нужно читать сверху вниз. Сначала идёт bug check code — шестнадцатеричный код ошибки с четырьмя параметрами. Затем секция STACK_TEXT показывает цепочку вызовов: верхние строки — это то, что выполнялось непосредственно перед падением. Имена функций вида модуль!функция+смещение позволяют определить, в каком драйвере произошло исключение.
Важно понимать ограничение метода: модуль, указанный в MODULE_NAME, — это вероятный виновник, а не доказанная причина. Драйвер мог оказаться жертвой порчи памяти, вызванной другим компонентом — например, нестабильной оперативной памятью или разгоном. Поэтому если в разных дампах виноваты разные модули, стоит проверить железо: память тестом MemTest86 или встроенным средством диагностики Windows, а также откатить разгон, если он применялся.
⚠️ Внимание: не удаляйте и не заменяйте системные файлы Windows по результатам анализа. Если виновным указан компонент ядра (например, ntoskrnl.exe), реальная причина почти всегда в стороннем драйвере или железе — само ядро сбоит крайне редко.
Живая отладка и дополнительные возможности
Помимо анализа дампов, WinDbg умеет подключаться к запущенным процессам (File → Attach to process) и отлаживать ядро второй машины по сети, COM-порту или USB. Режим kernel debugging требует включения отладки на целевой системе командой bcdedit /debug on и используется в основном разработчиками драйверов. Для диагностики BSOD на домашнем ПК он обычно не нужен — достаточно постмортем-анализа.
Отладчик поддерживает расширения — подключаемые DLL с дополнительными командами. Например, команды расширений загружаются через .load имя_библиотеки, а список уже загруженных показывает .chain. Для начинающих достаточно встроенного набора команд ядра.
Почему WinDbg долго «думает» при первом открытии дампа
При первом анализе отладчик скачивает символы с сервера Microsoft — это может занять несколько минут в зависимости от скорости соединения. Символы сохраняются в локальный кэш (папка из пути SRV*...), поэтому последующие анализы проходят заметно быстрее. Прерывать загрузку не стоит — без символов вывод будет неинформативным.
Типичные ошибки новичков
Первая распространённая ошибка — анализ без символов. Вывод выглядит загадочно, и пользователь делает неверные выводы. Вторая — доверие единственному дампу: для надёжного вывода желательно проанализировать несколько дампов от разных сбоев и искать повторяющийся модуль.
- 🚫 Анализ без настроенного пути к символам
- 🚫 Выводы по одному дампу без перекрёстной проверки
- 🚫 Игнорирование даты и версии драйвера в выводе
lmvm - 🚫 Попытки «починить» системные файлы вместо поиска стороннего драйвера
Часто задаваемые вопросы
Где взять дамп, если папка Minidump пуста?
Проверьте настройки записи отладочной информации: Система → Дополнительные параметры системы → Загрузка и восстановление. Там должен быть выбран хотя бы «Малый дамп памяти». Также убедитесь, что файл подкачки не отключён полностью — без него система может не создать дамп.
Что делать, если виновником указан ntoskrnl.exe?
Это ядро Windows, и само по себе оно сбоит редко. Такой результат обычно означает, что реальная причина — сторонний драйвер, повреждённая память или разгон. Проверьте оперативную память, откатите разгон и проанализируйте другие дампы на предмет повторяющихся сторонних модулей.
Чем WinDbg Preview отличается от классической версии?
Preview-версия из Microsoft Store имеет современный интерфейс, ленту команд, подсветку и встроенную поддержку скриптов, при этом набор отладочных команд совпадает. Для анализа дампов функционально обе версии равноценны.
Нужен ли интернет для работы WinDbg?
Для первой загрузки символов с сервера Microsoft — да. После того как символы закэшированы локально, анализ дампов той же версии Windows может выполняться офлайн.
Можно ли с помощью WinDbg отлаживать свои программы?
Да. WinDbg подключается к запущенным процессам и запускает исполняемые файлы под отладкой, поддерживает точки останова (команда bp), пошаговое выполнение и просмотр переменных при наличии символов вашего приложения.