После синего экрана смерти Windows сохраняет файл MEMORY.DMP или минидамп в папке C:\Windows\Minidump — и именно в нём зафиксирован драйвер или модуль, вызвавший критическую ошибку. Пока этот файл не открыт в отладчике, причина BSOD остаётся догадкой: код остановки на экране даёт лишь общее направление, тогда как анализ дампа показывает конкретный виновник, например nvlddmkm.sys или ntoskrnl.exe.
Дампы бывают разных типов: малый дамп памяти (обычно до нескольких сотен килобайт), дамп ядра и полный дамп памяти. Для большинства случаев достаточно минидампа — он содержит стек вызовов, список загруженных драйверов и код ошибки. В этой статье разберём, как открыть и прочитать дамп штатными и сторонними инструментами, на что смотреть в первую очередь и как отличить аппаратную проблему от программной.
Где Windows хранит файлы дампов
Прежде чем анализировать дамп, его нужно найти. По умолчанию система складывает файлы в стандартные расположения, но путь можно изменить в настройках отказа системы.
- 📁
C:\Windows\Minidump— папка с минидампами, каждый файл назван по дате сбоя; - 📁
C:\Windows\MEMORY.DMP— полный дамп или дамп ядра, перезаписывается при каждом новом критическом сбое; - 📁
%LOCALAPPDATA%\CrashDumps— дампы аварийно завершённых пользовательских приложений (если включён WER); - 📁 Папка, указанная в настройках конкретной программы — некоторые приложения (например, браузеры или игры) пишут собственные дампы.
Проверить, включено ли создание дампов, можно так: Панель управления → Система → Дополнительные параметры системы → Загрузка и восстановление → Параметры. В поле «Запись отладочной информации» должен быть выбран хотя бы «Малый дамп памяти». Если там стоит «Нет», после следующего сбоя анализировать будет нечего.
⚠️ Внимание: если на системном диске мало свободного места или файл подкачки отключён, полный дамп памяти может не создаться. Для записи дампа ядра файл подкачки должен находиться на системном разделе — это требование Windows, а не рекомендация.
Быстрый анализ через BlueScreenView
Для первичной диагностики не обязательно осваивать отладчик. Утилита BlueScreenView от NirSoft сканирует папку минидампов и показывает по каждому сбою код ошибки, время, параметры и список драйверов, причём модули, найденные в стеке на момент падения, подсвечиваются.
Вам нужно запустить программу от имени администратора, дождаться загрузки списка и посмотреть на нижнюю панель: розовым выделены файлы, которые были в стеке вызовов в момент критической ошибки. Если при нескольких сбоях подсвечивается один и тот же драйвер — это серьёзный кандидат на роль виновника.
Важно понимать ограничение метода: подсвеченный модуль — это не всегда причина, иногда это жертва. Например, ntoskrnl.exe фигурирует в огромном числе дампов просто потому, что ядро участвует в любой операции. Ориентируйтесь на сторонние драйверы, а не на компоненты самой системы.
Полноценный анализ в WinDbg
WinDbg — официальный отладчик Microsoft, дающий максимум информации. Современная версия называется WinDbg Preview и распространяется через Microsoft Store, классическая входит в состав Windows SDK. Для анализа дампов ядра это основной инструмент.
Порядок действий: откройте файл дампа через File → Open Dump File, дождитесь загрузки и выполните команду автоматического анализа:
!analyze -vКоманда выдаёт развёрнутый отчёт: код bugcheck, параметры, стек вызовов и поле IMAGE_NAME / MODULE_NAME, где указан модуль, который отладчик считает вероятной причиной. Для корректной работы анализа нужны символы — отладочные данные Microsoft. Их можно подключить командой настройки пути:
.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols☑️ Чек-лист анализа дампа в WinDbg
Дополнительно полезны команды lmvm имя_модуля (показывает версию и дату драйвера) и !thread (информация о потоке, в котором произошёл сбой). Устаревшая дата драйвера — косвенный признак того, что его стоит обновить.
На какие поля смотреть в отчёте
Отчёт !analyze -v объёмный, но для диагностики критичны несколько полей. Разберём их значение.
| Поле | Что показывает | Как использовать |
|---|---|---|
BUGCHECK_CODE | Код критической ошибки (например, 0x1A, 0x3B) | Определяет класс проблемы: память, драйвер, файловая система |
MODULE_NAME | Модуль, в котором произошёл сбой | Первый кандидат на проверку и обновление |
IMAGE_NAME | Имя файла модуля | Позволяет найти драйвер на диске и узнать его версию |
STACK_TEXT | Стек вызовов на момент падения | Показывает цепочку функций, приведшую к ошибке |
FAILURE_BUCKET_ID | Автоматическая классификация сбоя | Удобно для поиска похожих случаев в документации |
Отдельного внимания заслуживают параметры bugcheck — четыре значения в скобках после кода. Их смысл зависит от конкретного кода остановки и описан в официальной документации Microsoft «Bug Check Code Reference». Не пытайтесь трактовать параметры «в общем виде»: для разных кодов одно и то же значение означает разное.
Как отличить программный сбой от аппаратного
Это ключевой вопрос диагностики, и дамп даёт на него косвенные, но полезные подсказки. Единственного «поля с вердиктом» не существует — вывод делается по совокупности признаков.
- 🔧 Один и тот же драйвер в разных дампах — почти наверняка программная причина: обновите или откатите его;
- 🎲 Случайные модули и разные коды ошибок — типичный признак неисправной оперативной памяти или нестабильного разгона;
- 🌡️ Сбои под нагрузкой (игры, рендеринг) с ошибками видеодрайвера — проверьте температуры и питание видеокарты;
- 💾 Ошибки с участием Ntfs.sys или storport.sys — возможна проблема с диском или его контроллером, проверьте SMART и кабели.
Для проверки памяти используйте штатное средство mdsched.exe или более тщательный MemTest86, загружаемый с флешки. Если включён разгон (XMP-профиль, разгон процессора) — верните штатные частоты и понаблюдайте: исчезновение сбоев само по себе является диагнозом.
⚠️ Внимание: не обновляйте BIOS и не перепрошивайте устройства только на основании одного дампа. Сначала выполните обратимые проверки — обновление драйверов, тест памяти, откат разгона. Прошивка — рискованная операция, которая оправдана лишь при подтверждённой необходимости.
Что делать, если папка Minidump пуста
Проверьте настройки: Панель управления → Система → Дополнительные параметры → Загрузка и восстановление. Убедитесь, что выбран тип дампа и снята галочка «Выполнить автоматическую перезагрузку» — тогда код ошибки можно будет прочитать на экране. Также проверьте, что файл подкачки не отключён и находится на системном диске, а чистильщики вроде CCleaner не удаляют дампы автоматически.
Анализ дампов отдельных приложений
Не только система в целом, но и отдельные программы оставляют дампы при аварийном завершении. Если падает конкретное приложение, а Windows работает стабильно, искать нужно дамп пользовательского режима, а не дамп ядра.
Такой дамп можно создать вручную: в Диспетчере задач на вкладке «Подробности» щёлкните правой кнопкой по зависшему процессу и выберите «Создать файл дампа памяти» — система сохранит файл и покажет путь к нему. Открывается он тем же WinDbg, но анализ начинается с команд !analyze -v (для managed-кода .NET — расширение SOS и команда !pe для просмотра исключения).
Для .NET-приложений удобнее связка dotnet-dump analyze из кроссплатформенного инструментария Microsoft. Она показывает управляемые исключения, потоки и кучу без настройки символов ядра.
Типичные ошибки при анализе
Начинающие диагносты часто делают одни и те же промахи, которые ведут к ложным выводам и лишним действиям.
Первая ошибка — анализ без символов. Без них стек выглядит как набор адресов, и отладчик может указать неверный модуль. Вторая — выводы по единственному дампу: один сбой может быть случайностью, закономерность видна только по серии из трёх-пяти файлов. Третья — слепое доверие полю «Probably caused by»: это эвристика, а не приговор, её нужно перепроверять стеком и здравым смыслом.
⚠️ Внимание: не удаляйте и не заменяйте системные файлы вроде ntoskrnl.exe или hal.dll, даже если они указаны в дампе. Эти модули почти всегда оказываются в стеке постольку, поскольку являются ядром системы, а реальная причина обычно кроется в драйвере или железе.
И наконец: не игнорируйте контекст. Сбои начались после обновления драйвера, установки антивируса или подключения нового устройства? Хронология часто важнее самого дампа — сопоставьте дату первого файла в Minidump с недавними изменениями в системе.
Часто задаваемые вопросы
Чем открыть файл .dmp без установки программ?
Штатных средств просмотра дампов в Windows нет. Минимальный вариант — портативная утилита BlueScreenView, которая не требует установки. Для глубокого анализа понадобится WinDbg из Microsoft Store.
Почему WinDbg пишет, что не может загрузить символы?
Чаще всего не настроен путь к серверу символов или нет доступа в интернет. Выполните команду .symfix для автоматической настройки, затем .reload и повторите анализ.
Можно ли анализировать дамп с другого компьютера?
Да, файл дампа не привязан к машине, на которой создан. Скопируйте его на свой ПК и откройте в WinDbg — анализ будет полноценным, версии Windows на двух машинах могут отличаться.
В дампе указан ntoskrnl.exe — значит, проблема в Windows?
Практически никогда. Ядро системы фигурирует в стеке большинства сбоев, потому что через него проходят все системные вызовы. Ищите в стеке сторонние драйверы, а при «плавающих» ошибках проверяйте память и разгон.
Сколько дампов нужно для достоверного вывода?
Один файл показывает только частный случай. Для выявления закономерности желательно проанализировать хотя бы три-пять дампов: если виновник повторяется — причина программная, если каждый раз разный — подозревайте железо.