Проблема
Синий экран смерти (Blue Screen of Death) та самая неприятность, которая вынуждает администратора отрываться от текущих задач и ломать голову над внезапной перезагрузкой сервера или рабочей станции. Экран с «печальным смайликом» и сообщением Your PC ran into a problem содержит критически важную информацию: шестнадцатеричный STOP-код, параметры ошибки и, при удачной настройке, имя проблемного модуля. Однако большинство пользователей и начинающих сисадминов эту информацию игнорируют, просто перезагружая систему в надежде, что «само пройдёт». Такой подход приводит к накоплению нерешённых проблем и повторяющимся сбоям. BSOD Windows это не приговор, а диагностический инструмент, который при правильной расшифровке позволяет быстро локализовать неисправное оборудование, сбойный драйвер или повреждённый системный файл. В этой статье мы разберём алгоритм анализа дампа памяти и научимся интерпретировать самые частые STOP-коды. Ранее я уже писал о диагностике «синего экрана» (BSOD), будет также полезно.
Решение
Для системного подхода к диагностике BSOD необходимо настроить автоматическое сохранение аварийных дампов памяти, обеспечить доступ к инструменту отладки (WinDbg) и освоить базовые приёмы чтения вывода анализатора. Такой подход регламентирован официальной документацией Microsoft Analyze a Kernel-Mode Dump File with WinDbg и руководством по отладке Blue Screen Data. Алгоритм работает на всех поддерживаемых версиях Windows 10 и 11, а также на Windows Server 2016/2019/2022, и не требует переустановки системы.
Пошаговая инструкция
Шаг 1. Настройка сохранения дампов памяти
По умолчанию Windows может автоматически перезагружаться после BSOD, не оставляя следа для анализа. Первым делом проверяем и настраиваем политику записи дампов.
- Нажмите
Win + R, введитеsysdm.cplи нажмите Enter. - Перейдите на вкладку Дополнительно (Advanced), в разделе Загрузка и восстановление (Startup and Recovery) нажмите Параметры (Settings).
- В блоке Отказ системы (System failure):
- Убедитесь, что стоит галочка Записать событие в системный журнал.
- Снимите галочку Автоматически выполнять перезагрузку, чтобы успеть прочитать STOP-код на экране.
- В выпадающем списке Запись отладочной информации выберите Автоматический дамп памяти (Automatic memory dump) или Активный дамп памяти (Active memory dump) для современных систем. Для серверов с большим объёмом ОЗУ можно оставить Дамп памяти ядра (Kernel memory dump).
- Убедитесь, что путь к файлу дампа —
%SystemRoot%\MEMORY.DMP.
- Для углублённого анализа включите запись малого дампа (Minidump): установите переключатель в Малый дамп памяти (256 КБ) и укажите директорию, например,
%SystemRoot%\Minidump. Малые дампы занимают минимум места и пишутся при каждом сбое, тогда как полный дамп перезаписывается. - Нажмите ОК и перезагрузите компьютер, если система этого попросит.
Дополнительные сведения о типах дампов приведены в статье Varieties of Kernel-Mode Dump Files.
Шаг 2. Установка инструментов отладки (WinDbg)
WinDbg бесплатный отладчик от Microsoft, распространяемый через Windows SDK.
- Скачайте установщик Windows SDK с официального сайта Windows SDK.
- Запустите
winsdksetup.exeи на этапе выбора компонентов оставьте только Debugging Tools for Windows, снимите остальные галочки. - После установки откройте WinDbg от имени администратора (через меню «Пуск»).
Альтернативно можно использовать WinDbg Preview из Microsoft Store, но классическая версия из SDK предоставляет максимальный набор команд.
Шаг 3. Открытие и анализ дампа памяти
- Запустите WinDbg, нажмите
Ctrl + Dили выберите File → Open Crash Dump. - Укажите путь к файлу
MEMORY.DMPв папкеC:\Windowsили к последнему минидампу изC:\Windows\Minidump(рекомендуется брать самый свежий по дате). - Дождитесь загрузки дампа и автоматического выполнения начальных команд. Вы увидите строку типа:textLoading Dump File [C:\Windows\MEMORY.DMP] Kernel Bitmap Dump File: Kernel address space is available
- В нижней панели команд введите центральную команду анализа:text!analyze -vКлюч
-v(verbose) заставляет WinDbg выдать максимально подробный отчёт.
Шаг 4. Интерпретация вывода !analyze -v
Отчёт содержит несколько ключевых секций, которые следует читать сверху вниз.
4.1. Первичный STOP-код и параметры
Первая строка после BugCheck сообщает шестнадцатеричный код ошибки, например:
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
В скобках указан код 0x000000D1. Запоминаем его.
4.2. Сбойный модуль
Ищем строку Probably caused by: или MODULE_NAME:. Пример:
Probably caused by : nvlddmkm.sys ( nvlddmkm+2a1c4 )
Имя файла (nvlddmkm.sys) указывает на драйвер видеокарты NVIDIA. Именно этот драйвер спровоцировал BSOD.
4.3. Стек вызова
Секция STACK_TEXT показывает последовательность вызовов функций ядра и драйверов, предшествовавших сбою. Адреса без символов обозначены знаками вопроса, но после настройки символов (см. шаг 5) имена функций станут читаемыми. Обращайте внимание на самые верхние строки стека — они указывают на код, исполнявшийся в момент краха.
4.4. FAILURE_BUCKET_ID и анализ
Строка FAILURE_BUCKET_ID содержит идентификатор ошибки в формате AV_nvlddmkm!unknown_function. Это хеш-сигнатура, которую можно загуглить для поиска аналогичных случаев. Также в секции IMAGE_NAME и FAILURE_BUCKET_ID уточняется проблемный бинарный файл.
Шаг 5. Настройка символов для точного анализа
Для получения читаемых имён функций в стеке требуется подключиться к серверу символов Microsoft.
- В WinDbg выберите File → Settings → Debugging settings или в командной строке выполните:text.sympath SRV*c:\symbols*https://msdl.microsoft.com/download/symbols .reload /f
- Первая команда задаёт путь для локального кеширования символов (
c:\symbols) и URL сервера символов. Вторая принудительно перезагружает символы для всех модулей. - После этого повторите
!analyze -v. Стек станет существенно информативнее.
Официальная справка по символам: Symbol Path for Windows Debuggers.
Шаг 6. Расшифровка распространённых STOP-кодов
Ниже перечислены коды, с которыми сталкивается 90% администраторов, их типичные причины и направления диагностики.
| STOP-код (hex) | Символическое имя | Типичная причина |
|---|---|---|
0x000000D1 | DRIVER_IRQL_NOT_LESS_OR_EQUAL | Драйвер обратился к странице памяти по недопустимому IRQL. Чаще всего драйвер сетевой карты или антивируса. |
0x0000001E | KMODE_EXCEPTION_NOT_HANDLED | Необработанное исключение в режиме ядра. Часто указывает на баг в драйвере или неисправную оперативную память. |
0x00000050 | PAGE_FAULT_IN_NONPAGED_AREA | Обращение к отсутствующей или повреждённой странице памяти. Виновник сбойный модуль ОЗУ, жёсткий диск или драйвер. |
0x0000007F | UNEXPECTED_KERNEL_MODE_TRAP | Аппаратная проблема: перегрев процессора, неисправность ОЗУ, разгон, повреждение кеша CPU. |
0x0000009F | DRIVER_POWER_STATE_FAILURE | Сбой управления питанием (обычно при выходе из сна/гибернации). Виновник драйвер чипсета, видеокарты или USB-устройства. |
0x00000133 | DPC_WATCHDOG_VIOLATION | Драйвер слишком долго выполняет отложенный вызов процедуры (DPC). Часто вызывается драйверами SSD/HDD, реже — беспроводных адаптеров. |
0x0000003B | SYSTEM_SERVICE_EXCEPTION | Исключение при выполнении системной службы. Виновник драйвер графики или несовместимый антивирус. |
0x000000EF | CRITICAL_PROCESS_DIED | Критический системный процесс (csrss.exe, wininit.exe) аварийно завершён. Часто указывает на повреждение системных файлов или заражение вредоносным ПО. |
0x0000001A | MEMORY_MANAGEMENT | Серьёзная проблема с управлением памятью: неисправность модуля ОЗУ, конфликт драйверов, повреждение файла подкачки. |
0x00000109 | CRITICAL_STRUCTURE_CORRUPTION | Обнаружено повреждение критических структур данных ядра. Часто вызывается вредоносным ПО или драйвером, модифицирующим код ядра. |
При обнаружении любого из этих кодов в первую очередь проверяйте оборудование (ОЗУ через MemTest86, диск через chkdsk /f /r), обновляйте или откатывайте подозрительные драйверы и запускайте sfc /scannow для восстановления системных файлов.
Устранение распространённых проблем
| Симптом | Вероятная причина | Решение |
|---|---|---|
| WinDbg не находит файл дампа | Система не создала дамп из-за отсутствия файла подкачки или недостатка места на диске | Проверьте, что размер файла подкачки не менее объёма ОЗУ + 1 МБ на системном томе. Освободите место на диске C:. В sysdm.cpl в том же окне настройки дампа убедитесь, что выбранный диск имеет достаточно свободного пространства. |
В выводе !analyze -v нет имени драйвера | Система не смогла определить виновника; возможно, повреждён стек или дамп неполный | Включите верификатор драйверов (verifier.exe) для подозрительных модулей. Это приведёт к более детальному сбору информации при следующем BSOD. Подробнее: Driver Verifier. |
Анализ указывает на ntoskrnl.exe, но драйвер не указан | Ошибка произошла в ядре системы из-за воздействия стороннего драйвера, который не записался в стек | Используйте команду !thread и k, чтобы изучить полный стек вызовов. Сравните время сбоя с журналом событий Windows (eventvwr.msc): фильтруйте по System с источником Kernel-Power и BugCheck. Это даст дополнительный контекст. |
| Дамп создаётся, но WinDbg не может его открыть | Повреждённый файл дампа | Попробуйте открыть минидамп из папки Minidump они менее подвержены повреждению. Если все дампы битые, выполните проверку диска: chkdsk C: /f /r. |
После настройки символов часть имён функций остаётся неизвестной (unknown) | Отсутствуют символы для сторонних драйверов | Добавьте дополнительные пути к символам: .sympath+ SRV*c:\mysymbols*https://driver-symbols.example.com. Производители драйверов (NVIDIA, AMD) предоставляют символы на своих сайтах, но для публичного анализа обычно достаточно сервера Microsoft. |
Итог
BSOD Windows перестаёт быть пугающей неожиданностью, когда в руках администратора есть чёткий алгоритм: сохранить дамп, открыть в WinDbg, выполнить !analyze -v и расшифровать код. Опыт показывает, что в 70% случаев вина лежит на сторонних драйверах, и решение сводится к их обновлению или откату. Остальные проценты приходятся на аппаратные неисправности и повреждения системных файлов. Ведение собственной базы STOP-кодов и частых виновников для вашего парка машин существенно ускоряет диагностику и минимизирует простои.
