После синего экрана смерти (BSOD) Windows сохраняет дамп памяти — файл MEMORY.DMP в папке C:\Windows или минидампы в C:\Windows\Minidump, и именно их анализ позволяет узнать, какой драйвер или модуль вызвал сбой. Открыть такой файл обычным блокнотом бесполезно: это бинарный слепок оперативной памяти, который читается только специальными отладчиками и анализаторами.
В этой статье разберём, какие программы подходят для чтения дампов памяти, чем отличаются полный дамп и минидамп, и как пошагово добраться до причины критической ошибки — от простых утилит с готовым отчётом до профессионального отладчика WinDbg от Microsoft.
Какие бывают дампы памяти и где они лежат
Прежде чем выбирать инструмент, нужно понять, с каким типом файла вы имеете дело. Windows умеет создавать несколько видов дампов, и не все программы одинаково хорошо с ними справляются.
- 🔹 Малый дамп памяти (minidump) — компактный файл размером в сотни килобайт, хранится в
C:\Windows\Minidump. Содержит код ошибки, список загруженных драйверов и стек вызовов проблемного потока. - 🔹 Дамп памяти ядра — включает только память ядра системы, файл
MEMORY.DMPв корнеC:\Windows. - 🔹 Полный дамп памяти — слепок всей оперативной памяти, его размер сопоставим с объёмом установленной ОЗУ.
- 🔹 Автоматический дамп памяти — вариант по умолчанию в современных версиях Windows, близкий к дампу ядра.
Проверить, какой тип дампа создаёт ваша система, можно через Панель управления → Система → Дополнительные параметры системы → Загрузка и восстановление → Параметры. Там же указывается путь сохранения файла. Если дампы не создаются вовсе, причина обычно в отключённом файле подкачки или недостатке места на системном диске.
BlueScreenView — быстрый просмотр минидампов
Если вам нужно быстро понять, какой драйвер виноват в синем экране, начните с BlueScreenView от NirSoft. Утилита портативная, не требует установки и автоматически сканирует папку Minidump, показывая все зафиксированные сбои списком.
В нижней панели программа подсвечивает модули, которые находились в стеке вызовов на момент краха. Чаще всего виновник — это файл с расширением .sys, отличный от системных компонентов Windows: например, драйвер видеокарты, антивируса или сетевого адаптера. Официальные системные файлы вроде ntoskrnl.exe обычно лишь «последний в цепочке», а не первопричина.
Ограничение утилиты в том, что она работает в основном с минидампами и даёт поверхностную картину. Для детального разбора стека и параметров ошибки понадобится полноценный отладчик.
WinDbg — профессиональный анализ дампа
WinDbg — официальный отладчик Microsoft, который считается эталонным инструментом для чтения дампов памяти. Существует классическая версия, входящая в состав Windows SDK, и современная WinDbg Preview, доступная в Microsoft Store. Для разбора дампов обе подходят одинаково.
Чтобы открыть дамп, запустите программу и выберите File → Open Dump File, указав путь к файлу. Ключевой момент — настройка символов отладки: без них отладчик покажет только адреса вместо имён функций. Путь к серверу символов Microsoft задаётся через меню File → Symbol File Path:
srv*C:\Symbols*https://msdl.microsoft.com/download/symbolsПосле загрузки файла выполните команду автоматического анализа:
!analyze -vОтладчик выведет код ошибки (bug check code), её параметры, стек вызовов и строку IMAGE_NAME или MODULE_NAME с именем вероятного виновника. Именно поле MODULE_NAME в выводе !analyze -v чаще всего указывает на сбойный драйвер, хотя финальный вывод стоит делать с учётом всего стека.
☑️ Анализ дампа в WinDbg
⚠️ Внимание: при первом анализе WinDbg скачивает файлы символов с сервера Microsoft, поэтому требуется подключение к интернету. Без символов отчёт будет неинформативным — вы увидите адреса вместо названий функций и модулей.
WhoCrashed и альтернативные утилиты
Для пользователей, которым синтаксис отладчика кажется избыточным, существуют программы с готовым текстовым отчётом. WhoCrashed анализирует дампы и выдаёт заключение на понятном языке: какой драйвер предположительно вызвал сбой и какого типа была ошибка. Бесплатной версии достаточно для домашней диагностики.
Ещё один вариант — WinDbg Preview с его упрощённым интерфейсом: по сути это тот же движок анализа, но с более дружелюбной оболочкой. Некоторые пользователи также применяют Microsoft WinDbg через командную строку с утилитой kd.exe, но для разового разбора это излишне.
Сравнение программ для чтения дампов
Выбор инструмента зависит от задачи: быстро определить виновника или провести глубокий разбор. Сводная таблица поможет сориентироваться.
| Программа | Тип дампов | Сложность | Глубина анализа |
|---|---|---|---|
| BlueScreenView | Минидампы | Минимальная | Список модулей в стеке |
| WhoCrashed | Минидампы, полный дамп | Низкая | Готовое текстовое заключение |
| WinDbg Preview | Все типы | Средняя | Полный разбор стека и параметров |
| WinDbg (классический) | Все типы | Высокая | Профессиональная отладка |
Для разовой диагностики домашнего ПК разумная схема такая: сначала прогнать минидампы через BlueScreenView или WhoCrashed, а если имя модуля не даёт однозначного ответа — открыть дамп в WinDbg и выполнить !analyze -v.
Почему виновником часто показывается ntoskrnl.exe
Файл ntoskrnl.exe — это ядро Windows, через которое проходят почти все системные вызовы. Когда сбой происходит в стороннем драйвере, крах часто фиксируется уже внутри ядра, поэтому анализаторы показывают его как «место падения». Реальную причину нужно искать по сторонним .sys-файлам в стеке вызовов.
Как интерпретировать результат анализа
Найти имя сбойного модуля — только половина работы. Дальше нужно понять, чему он принадлежит и что с этим делать. Файл .sys с названием видеодрайвера указывает на проблемы с графическим адаптером или его ПО; модуль антивируса — на конфликт защитного ПО; драйвер контроллера хранения данных может намекать на проблемы с диском.
⚠️ Внимание: один и тот же код ошибки может иметь разные причины. Если анализ дампа указывает на разные модули при каждом сбое, возможна аппаратная проблема — например, нестабильная оперативная память. В таком случае стоит проверить ОЗУ средствами вроде встроенного средства диагностики памяти Windows или MemTest86.
Типичные шаги после определения виновника: обновить или откатить драйвер устройства, проверить системные файлы командой sfc /scannow, удалить недавно установленное ПО. Если сбои начались после разгона — вернуть штатные частоты в BIOS. Менять несколько вещей одновременно не стоит: так вы не поймёте, что именно помогло.
Часто задаваемые вопросы
Можно ли открыть дамп памяти без установки программ?
Полноценно — нет. Блокнот и подобные редакторы покажут лишь нечитаемый бинарный код. Минимально необходим портативный инструмент вроде BlueScreenView, который не требует установки, но саму программу скачать всё же придётся.
Чем открыть файл MEMORY.DMP большого размера?
Полный дамп и дамп ядра корректно открывает WinDbg — он рассчитан на файлы любого размера. Лёгкие утилиты вроде BlueScreenView ориентированы в основном на минидампы и с большими файлами могут не работать.
Дамп не создаётся после синего экрана. Что проверить?
Убедитесь, что в настройках «Загрузка и восстановление» выбран тип дампа, отличный от «Нет», проверьте наличие свободного места на системном диске и не отключён ли файл подкачки — для некоторых типов дампов он обязателен.
Безопасно ли отправлять дамп памяти третьим лицам?
Дамп может содержать фрагменты данных из оперативной памяти, включая конфиденциальную информацию. Минидамп в этом смысле менее рискован, чем полный дамп, но передавать файлы стоит только доверенным специалистам.
Что делать, если !analyze -v не указывает конкретный драйвер?
Проверьте, загружены ли символы (в выводе не должно быть ошибок загрузки символов для ключевых модулей). Изучите стек вызовов вручную командой kv или kn и обратите внимание на сторонние модули. Если сбои указывают на разные модули, проверьте оперативную память и стабильность системы.