Файл MEMORY.DMP или минидамп из папки C:\Windows\Minidump появляется после каждого критического сбоя Windows — синего экрана BSOD, и именно в нём записан код ошибки, имя драйвера-виновника и состояние памяти в момент падения системы. Двойной клик по такому файлу ничего не даст: .dmp — это бинарный слепок оперативной памяти, который открывается только специальными отладчиками.
Разберёмся, чем открыть DMP-файл, как найти в нём причину сбоя и что делать с полученной информацией. Способы подходят для Windows 10 и Windows 11, а также для более ранних версий системы.
Что такое DMP-файл и где он хранится
Дамп памяти (memory dump) — это файл, в который Windows автоматически сохраняет содержимое оперативной памяти и данные о состоянии процессора при критической ошибке. Система делает это, чтобы после перезагрузки можно было выяснить, какой драйвер или процесс вызвал падение.
Существует несколько типов дампов, и от типа зависит размер файла и полнота информации:
- 🔹 Малый дамп памяти (минидамп) — файлы вида
MiniDDMMYY-NN.dmpв папкеC:\Windows\Minidump. Содержит код ошибки, список загруженных драйверов и контекст сбойного процесса. Для большинства диагностик этого достаточно. - 🔹 Дамп памяти ядра — файл
C:\Windows\MEMORY.DMP, включает только память ядра системы без пользовательских процессов. - 🔹 Полный дамп памяти — полный слепок всей оперативной памяти. Файл может занимать десятки гигабайт, нужен в основном разработчикам.
- 🔹 Автоматический дамп — вариант по умолчанию в современных версиях Windows, близкий к дампу ядра.
Тип создаваемого дампа настраивается в параметрах: Панель управления → Система → Дополнительные параметры системы → Загрузка и восстановление → Параметры. Там же можно убедиться, что запись отладочной информации вообще включена — иначе после сбоя файла просто не будет.
⚠️ Внимание: если папка C:\Windows\Minidump пуста после синего экрана, проверьте, что файл подкачки не отключён и находится на системном диске — без него Windows не может записать дамп. Также дамп не создаётся, если в настройках загрузки и восстановления выбран вариант «нет».
Быстрый анализ через BlueScreenView
Самый простой способ прочитать DMP-файл без установки громоздких инструментов — бесплатная утилита BlueScreenView от NirSoft. Она автоматически сканирует папку минидампов и показывает список всех сбоев в виде таблицы.
Вам нужно скачать утилиту с официального сайта разработчика, распаковать архив и запустить исполняемый файл — установка не требуется. Программа сразу отобразит все найденные дампы: дату сбоя, код ошибки (Bug Check String, например IRQL_NOT_LESS_OR_EQUAL), четыре параметра и адрес драйвера.
Ключевая строка — Caused By Driver: в ней указан файл драйвера, который, по оценке анализатора, вызвал падение. Если там nvlddmkm.sys — подозрение падает на видеодрайвер NVIDIA, rtwlane.sys и похожие — на сетевой адаптер Realtek, а ntoskrnl.exe означает, что сбой произошёл в ядре и реальная причина требует более глубокого анализа.
Профессиональный анализ в WinDbg
WinDbg (Windows Debugger) — официальный отладчик Microsoft, который даёт максимально полную картину сбоя. Скачать его можно бесплатно из Microsoft Store (приложение WinDbg) или в составе Windows SDK.
Порядок действий после установки:
- 🛠️ Запустите WinDbg и откройте дамп через
File → Open dump file, выбрав файл изC:\Windows\MinidumpилиMEMORY.DMP. - 🛠️ Дождитесь загрузки символов — отладчик скачает их с серверов Microsoft, при первом запуске это может занять время.
- 🛠️ Введите в командной строке отладчика команду
!analyze -vи нажмите Enter. - 🛠️ Изучите вывод: строки
BUGCHECK_CODE,PROCESS_NAMEиIMAGE_NAMEукажут на виновника.
!analyze -vВ результатах анализа обращайте внимание на поле MODULE_NAME и IMAGE_NAME — там указан конкретный файл, в котором произошла ошибка. Если это сторонний драйвер (не системный файл Microsoft), его обновление или откат обычно решает проблему.
☑️ Анализ дампа в WinDbg
⚠️ Внимание: без доступа к интернету WinDbg не сможет загрузить символы, и анализ будет неполным — вместо имён функций вы увидите нечитаемые адреса. Убедитесь, что компьютер подключён к сети при первом анализе.
Как расшифровать результаты анализа
Полученный код ошибки — отправная точка диагностики. Один и тот же BSOD может иметь разные причины, но типовые закономерности известны:
| Код ошибки | Вероятная причина | Первое действие |
|---|---|---|
IRQL_NOT_LESS_OR_EQUAL | Драйвер обратился к недопустимой области памяти; возможны проблемы с ОЗУ | Обновить драйвер из IMAGE_NAME, проверить память |
PAGE_FAULT_IN_NONPAGED_AREA | Неисправная оперативная память или сбойный драйвер | Запустить mdsched.exe — средство проверки памяти Windows |
DPC_WATCHDOG_VIOLATION | Драйвер слишком долго выполнялся; часто связан с SSD и SATA-контроллером | Обновить драйверы чипсета и контроллера накопителя |
SYSTEM_SERVICE_EXCEPTION | Ошибка в системном вызове; нередко виноват антивирус или графический драйвер | Обновить или временно удалить подозрительное ПО |
VIDEO_TDR_FAILURE | Видеодрайвер перестал отвечать | Чистая переустановка видеодрайвера |
Если в нескольких дампах подряд фигурирует один и тот же файл драйвера — это почти наверняка и есть причина сбоев, а не совпадение. Разовый сбой с уникальным кодом может быть случайностью, но повторяющийся паттерн требует действий.
Альтернативные программы для чтения DMP
Помимо BlueScreenView и WinDbg, существуют и другие инструменты. WhoCrashed ориентирован на новичков: программа анализирует дампы и выдаёт заключение простым языком — например, прямо пишет, что проблема, вероятно, связана с конкретным драйвером или перегревом, а не сбоями Windows.
Системные администраторы нередко используют WinDbg Preview в связке с онлайн-сервисами анализа, куда можно загрузить минидамп и получить автоматический отчёт. Однако отправлять дампы на сторонние ресурсы стоит осторожно: файл может содержать фрагменты данных из оперативной памяти.
Почему ntoskrnl.exe не всегда настоящий виновник
Файл ntoskrnl.exe — это ядро Windows. Когда драйвер повреждает память, фактическое падение часто происходит позже, уже внутри ядра, поэтому анализатор указывает ntoskrnl.exe. В таких случаях смотрите глубже в стек вызовов в WinDbg или включайте проверку драйверов сторонних производителей.
Что делать, если дамп не создаётся или не читается
Иногда после сбоя файла дампа нет вовсе, либо отладчик сообщает, что файл повреждён. Проверьте следующие моменты:
- 💾 Включена ли запись дампа в
Загрузка и восстановлениеи не выбран ли вариант «нет». - 💾 Есть ли файл подкачки на системном диске — без него дамп ядра и полный дамп не записываются.
- 💾 Достаточно ли свободного места на диске C: — полный дамп требует объёма, сопоставимого с размером ОЗУ.
- 💾 Не чистит ли диск сторонний «оптимизатор» — некоторые утилиты удаляют содержимое папки Minidump.
Если дамп открывается, но анализ выдаёт ошибку символов, проверьте путь к символам в WinDbg: в настройках должен быть указан сервер Microsoft. Команда для установки пути вручную выглядит так:
.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbolsFAQ: частые вопросы о DMP-файлах
Можно ли открыть DMP-файл блокнотом или текстовым редактором?
Технически файл откроется, но вы увидите бессмысленный набор символов — дамп хранится в бинарном формате. Для чтения нужны отладчики: WinDbg, BlueScreenView или WhoCrashed.
Безопасно ли удалять DMP-файлы?
Да, дампы можно удалять без вреда для системы — это просто отчёты о прошлых сбоях. Но делать это стоит только после того, как причина BSOD найдена и устранена, иначе при повторном сбое вы лишитесь данных для диагностики.
Почему WinDbg показывает виновником ntoskrnl.exe?
Это ядро Windows, и оно редко является истинной причиной. Обычно сторонний драйвер повреждает память, а падение происходит позже уже внутри ядра. Нужен более глубокий анализ стека вызовов или проверка драйверов сторонних производителей.
Можно ли проанализировать дамп с другого компьютера?
Да. Скопируйте файлы из папки C:\Windows\Minidump или файл MEMORY.DMP на свой ПК и откройте их в WinDbg или BlueScreenView — для анализа не требуется исходная система.
Что делать, если сбои повторяются, но виновник каждый раз разный?
Разные драйверы в разных дампах — характерный признак аппаратной проблемы: неисправной оперативной памяти, нестабильного разгона или перегрева. Проверьте ОЗУ средством mdsched.exe или MemTest86 и верните стандартные частоты, если использовался разгон.