Файл C:\Windows\MEMORY.DMP появляется после критического сбоя — синего экрана смерти (BSOD), и именно его содержимое позволяет узнать, какой драйвер или модуль вызвал остановку системы. Обычным текстовым редактором этот файл не открыть: он содержит снимок оперативной памяти в бинарном формате, и для чтения нужны специальные инструменты отладки.
В этой статье разберём, какие программы подходят для анализа дампа памяти в Windows 10, как настроить WinDbg с символами Microsoft и как интерпретировать результаты, чтобы найти виновника сбоев.
Что такое MEMORY.DMP и где он находится
Когда Windows 10 сталкивается с критической ошибкой, система сохраняет содержимое оперативной памяти (или его часть) в файл дампа. В зависимости от настроек создаются разные типы дампов: полный дамп памяти, дамп памяти ядра или малый дамп памяти (minidump).
Расположение файлов следующее:
- 🗂️
C:\Windows\MEMORY.DMP— полный или дамп ядра, один файл, перезаписывается при каждом сбое; - 🗂️
C:\Windows\Minidump\— папка с малыми дампами, каждый сбой создаёт отдельный файл с датой в имени; - ⚙️ тип дампа задаётся в
Панель управления → Система → Дополнительные параметры системы → Загрузка и восстановление.
Размер MEMORY.DMP может достигать объёма установленной оперативной памяти, поэтому на системах с 16–32 ГБ ОЗУ файл будет очень большим. Малые дампы, напротив, занимают обычно менее мегабайта и содержат только ключевую информацию о сбое.
⚠️ Внимание: если в настройках восстановления выбрано «Автоматически перезагружать», а запись отладочной информации отключена, дамп может вообще не создаваться. Проверьте настройки до того, как искать файл.
WinDbg — основной инструмент анализа дампов
Windows Debugger (WinDbg) — официальный отладчик Microsoft, который считается эталонным средством анализа дампов памяти. Современная версия WinDbg Preview устанавливается из Microsoft Store, также отладчик входит в состав Windows SDK (при установке достаточно выбрать только компонент Debugging Tools for Windows).
После установки нужно настроить путь к символам — без них отладчик покажет только адреса в памяти, а не имена функций и драйверов. Символы загружаются с сервера Microsoft, поэтому при первом анализе потребуется интернет-соединение.
SRV*C:\Symbols*http://msdl.microsoft.com/download/symbolsЭту строку указывают в меню File → Settings → Debugging settings в поле Symbol path, либо задают командой .sympath в окне отладчика. Локальная папка C:\Symbols служит кэшем, чтобы символы не скачивались повторно.
Пошаговый анализ дампа в WinDbg
Порядок действий при открытии дампа одинаков для MEMORY.DMP и файлов из Minidump. Отладчик делает основную работу автоматически — от вас требуется запустить анализ и прочитать результат.
☑️ Анализ дампа в WinDbg
Ключевая команда анализа вводится в командной строке внизу окна отладчика:
!analyze -vКоманда запускает расширенный автоматический анализ. В выводе обратите внимание на поля BUGCHECK_CODE (код ошибки синего экрана), IMAGE_NAME и MODULE_NAME — они указывают на файл, который отладчик считает вероятной причиной сбоя. Обычно это драйвер с расширением .sys.
Важно понимать: указанный модуль — это вероятный виновник, а не установленный факт. Иногда в дампе фигурирует системный файл вроде ntoskrnl.exe, хотя реальная причина — неисправная память или сторонний драйвер, повредивший структуры ядра раньше. В таких случаях стоит проанализировать несколько дампов от разных сбоев: повторяющийся модуль — более надёжная зацепка.
Альтернативные программы для открытия дампов
WinDbg требует настройки и даёт подробный, но перегруженный вывод. Если нужно быстро узнать виновника сбоя без погружения в отладку, подойдут более простые утилиты.
| Программа | Тип | Особенности |
|---|---|---|
| BlueScreenView | Бесплатная, портативная | Показывает список всех минидампов, подсвечивает сбойный драйвер |
| WhoCrashed | Бесплатная (домашняя версия) | Автоматический анализ с пояснением на понятном языке |
| WinDbg Preview | Официальная, Microsoft | Максимально глубокий анализ, требует настройки символов |
| OSR Online / аналоги | Онлайн-сервисы | Загрузка дампа на сайт, результат без установки ПО |
BlueScreenView от NirSoft — самый быстрый вариант: программа не требует установки, при запуске сама сканирует папку Minidump и выводит таблицу сбоев. Драйверы, участвовавшие в падении, подсвечиваются розовым цветом. Двойной клик по записи показывает код ошибки и параметры.
WhoCrashed идёт дальше и выдаёт текстовое заключение: например, указывает, что сбой связан с драйвером видеокарты, и предлагает его обновить. Для неподготовленного пользователя это самый понятный вариант, хотя глубина анализа уступает WinDbg.
Как интерпретировать результаты анализа
Имя модуля из дампа нужно сопоставить с конкретным драйвером или программой. Файлы .sys обычно лежат в C:\Windows\System32\drivers — по имени файла через поиск в интернете почти всегда удаётся установить, какому устройству или пакету ПО он принадлежит.
Типичные сценарии дальнейших действий:
- 🔧 драйвер видеокарты (nvlddmkm.sys, atikmdag.sys) — обновите или откатите драйвер GPU;
- 🔧 сетевой драйвер — обновите драйвер адаптера с сайта производителя;
- 🔧 антивирусный драйвер — попробуйте временно удалить антивирус и понаблюдать;
- 🔧 системные файлы ядра — проверьте ОЗУ (например, средством
mdsched.exe) и целостность системы командойsfc /scannow.
⚠️ Внимание: не удаляйте файлы .sys вручную из папки System32. Это может сделать систему незагружаемой. Драйверы отключаются через Диспетчер устройств или деинсталлятор соответствующей программы.
Что означают частые коды ошибок
Коды вроде IRQL_NOT_LESS_OR_EQUAL (0xA), PAGE_FAULT_IN_NONPAGED_AREA (0x50) и SYSTEM_SERVICE_EXCEPTION (0x3B) чаще всего связаны с драйверами или памятью. KMODE_EXCEPTION_NOT_HANDLED (0x1E) обычно указывает на сбойный драйвер. Точную причину всегда уточняйте по модулю из дампа — один и тот же код вызывается разными причинами.
Если файл дампа не создаётся
Бывает, что после синего экрана ни MEMORY.DMP, ни минидампов не обнаруживается. Возможные причины: отключена запись отладочной информации, недостаточно места на диске C:, файл подкачки перенесён или отключён, либо сбой происходит настолько рано, что система не успевает записать дамп.
Проверьте настройки: откройте sysdm.cpl через Win+R, перейдите на вкладку «Дополнительно», в разделе «Загрузка и восстановление» нажмите «Параметры». В списке «Запись отладочной информации» должен быть выбран хотя бы «Малый дамп памяти». Также убедитесь, что на системном разделе есть свободное место и файл подкачки не отключён полностью — для записи дампа ядра он необходим.
FAQ: частые вопросы о MEMORY.DMP
Можно ли открыть MEMORY.DMP блокнотом или Word?
Нет. Файл содержит бинарный снимок памяти, и в текстовом редакторе вы увидите только бессмысленный набор символов. Для чтения нужны отладчики (WinDbg) или специализированные анализаторы вроде BlueScreenView.
Можно ли удалить MEMORY.DMP, чтобы освободить место?
Да, файл можно безопасно удалить — на работу системы это не влияет. Но сделайте это после анализа, иначе потеряете информацию о причине сбоя. При следующем BSOD система создаст файл заново.
Чем минидамп отличается от полного дампа памяти?
Малый дамп содержит только сведения о сбое: код ошибки, список загруженных драйверов и стек вызовов. Полный дамп включает всё содержимое ОЗУ и нужен для глубокой отладки — обычному пользователю достаточно минидампа.
WinDbg показывает виновником ntoskrnl.exe — что делать?
Это ядро Windows, и оно почти никогда не является реальной причиной. Такой результат означает, что сбой вызвал сторонний код, повредивший структуры ядра, либо аппаратная проблема. Проверьте оперативную память, обновите драйверы и проанализируйте дампы от других сбоев.
Можно ли проанализировать дамп с другого компьютера?
Да. Скопируйте файл MEMORY.DMP или содержимое папки Minidump на свой ПК и откройте в WinDbg или BlueScreenView — версия Windows на анализирующей машине не обязана совпадать, важно лишь подключение к серверу символов.