Чем открыть MEMORY.DMP и разобрать причину синего экрана

Файл MEMORY.DMP появляется в папке C:\Windows сразу после критического сбоя системы — синего экрана (BSOD), и обычный двойной клик по нему ничего не даст: Windows не ассоциирует расширение .dmp ни с одной программой по умолчанию. Это бинарный снимок содержимого оперативной памяти на момент аварии, и для его чтения нужны специальные отладчики или анализаторы дампов.

Хорошая новость в том, что инструментов для этой задачи несколько — от простых утилит с готовым списком подозрительных драйверов до полноценного отладчика Microsoft. Ниже разберём, чем открыть MEMORY.DMP, как интерпретировать результат и что делать, если файл не читается или отсутствует.

Что такое MEMORY.DMP и где он находится

Когда Windows сталкивается с неустранимой ошибкой ядра, система записывает содержимое памяти в файл дампа, чтобы позже можно было установить виновника сбоя. В зависимости от настроек создаётся полный дамп памяти, дамп ядра или малый дамп (minidump).

Стандартные расположения:

  • 🗂️ C:\Windows\MEMORY.DMP — полный дамп или дамп ядра, один файл перезаписывается при каждом новом сбое;
  • 🗂️ C:\Windows\Minidump\ — папка с малыми дампами, каждый сбой создаёт отдельный файл с датой в имени;
  • ⚙️ Тип дампа настраивается в Система → Дополнительные параметры → Загрузка и восстановление → Отладочная информация.

Размер MEMORY.DMP может достигать объёма установленной оперативной памяти, поэтому на диске с малым запасом места файл иногда не записывается полностью. Если дампа нет ни в одном из указанных мест, возможная причина — отключённая запись отладочной информации или слишком маленький файл подкачки.

⚠️ Внимание: если файл MEMORY.DMP имеет размер 0 байт или заметно меньше ожидаемого, он, скорее всего, повреждён и не откроется в анализаторе. В этом случае ориентируйтесь на малые дампы из папки Minidump.

WinDbg — официальный отладчик Microsoft

Самый достоверный способ открыть дамп — WinDbg, официальный отладчик от Microsoft. Сейчас распространяется в двух вариантах: классический WinDbg из комплекта Windows SDK и современный WinDbg Preview, доступный в Microsoft Store. Для разовой диагностики удобнее второй — он ставится как обычное приложение.

Порядок анализа после установки:

  • 🔓 Запустите WinDbg от имени администратора и откройте файл через File → Open dump file;
  • 🌐 Настройте символы командой .symfix — отладчик скачает отладочные символы с серверов Microsoft;
  • ▶️ Введите команду !analyze -v и дождитесь автоматического разбора;
  • 🔍 Изучите строки IMAGE_NAME и MODULE_NAME — там обычно указан драйвер или модуль, вызвавший сбой.

☑️ Анализ дампа в WinDbg

Выполнено: 0 / 5

Строка IMAGE_NAME с именем вроде nvlddmkm.sys или ntoskrnl.exe — главная зацепка. Первый пример указывает на драйвер видеокарты NVIDIA, второй — на ядро системы, что чаще всего означает проблему не в самом ядре, а в стороннем драйвере или железе.

BlueScreenView и WhoCrashed — простой анализ без команд

Если командная строка отладчика отпугивает, есть утилиты, которые открывают дамп и сразу показывают результат в понятном виде. BlueScreenView от NirSoft сканирует папку Minidump и выводит список сбоев с подсветкой драйверов, находившихся в стеке на момент падения. Подозрительные модули подсвечиваются розовым.

WhoCrashed идёт дальше и выдаёт текстовое заключение на человекочитаемом языке: какой драйвер вероятнее всего виноват и какого типа была ошибка. Обе программы бесплатны для домашнего использования и не требуют установки символов.

Ограничение у таких утилит одно: они хуже справляются с полными дампами большого размера и дают менее детальную картину, чем WinDbg. Для первичной диагностики их достаточно, но при неоднозначных результатах стоит вернуться к отладчику.

📊 Каким инструментом вы анализируете дампы памяти
WinDbg / WinDbg Preview
BlueScreenView
WhoCrashed
Ещё не пробовал ни один

Сравнение инструментов для открытия MEMORY.DMP

ИнструментСложностьДетализацияКому подходит
WinDbg PreviewВысокаяМаксимальнаяПродвинутым пользователям
BlueScreenViewНизкаяСредняяБыстрая первичная диагностика
WhoCrashedНизкаяСредняяПонятное заключение без команд
Visual StudioСредняяВысокаяРазработчикам

Отдельно упомянем Visual Studio: она умеет открывать дампы и показывать стек вызовов, но для диагностики BSOD это избыточный инструмент. Её имеет смысл использовать, если дамп создала не система, а отдельное приложение, которое вы разрабатываете.

Можно ли открыть дамп онлайн

Сервисы онлайн-анализа дампов существуют, но пользоваться ими стоит осторожно. MEMORY.DMP может содержать фрагменты данных из оперативной памяти: пароли, ключи шифрования, содержимое открытых документов — всё, что обрабатывалось системой в момент сбоя. Загружать такой файл на сторонний сервер небезопасно.

⚠️ Внимание: не отправляйте полный дамп памяти на незнакомые сайты и не пересылайте его третьим лицам. Если нужна помощь с анализом, передавайте только малый дамп (minidump) — в нём данных заметно меньше, — и то после оценки рисков.

Безопасная альтернатива — скопировать текстовый вывод команды !analyze -v из WinDbg и попросить помочь с интерпретацией на профильном форуме. Текстовый лог не содержит содержимого памяти.

Что делать, если дамп не открывается или отсутствует

Бывает, что после синего экрана файла нет вообще или анализатор выдаёт ошибку чтения. Проверьте базовые условия записи дампов: откройте Win + R → sysdm.cpl → Дополнительно → Загрузка и восстановление и убедитесь, что в разделе «Отладочная информация» выбран любой тип дампа, кроме «Нет».

Также проверьте, что файл подкачки включён и находится на системном диске — без него Windows физически не может сохранить дамп. Если системный диск зашифрован или переполнен, запись тоже может завершаться неудачей. После изменения настроек дождитесь следующего сбоя (или спровоцируйте его, если это безопасно) и проверьте наличие файла снова.

Если файл есть, но WinDbg сообщает о повреждении, попробуйте открыть малые дампы из C:\Windows\Minidump\ — они пишутся отдельно и часто остаются целыми, даже когда большой файл битый.

Почему дамп может не записываться

Типичные причины: выбрано «Нет» в настройках отладочной информации, файл подкачки отключён или меньше требуемого объёма, на системном диске закончилось место, сбой происходит настолько рано (на этапе загрузки), что система не успевает сохранить данные. В последнем случае помогает загрузка в безопасном режиме и анализ журнала событий через «Просмотр событий».

Как интерпретировать результат анализа

Получить имя драйвера — только половина задачи. Дальше нужно понять, что с ним делать. Если виновник — файл видеодрайвера (nvlddmkm.sys, atikmdag.sys), первым шагом обычно бывает чистая переустановка драйвера с предварительным удалением старого. Если упоминается антивирусный или сетевой драйвер — обновите или временно удалите соответствующую программу.

Когда анализ называет системные файлы вроде ntoskrnl.exe или hal.dll, а сторонних модулей в стеке нет, вероятная причина — железо: нестабильная оперативная память, перегрев, разгон или проблемы с диском. В этом случае логично прогнать память тестом (например, встроенным средством диагностики памяти Windows или MemTest86) и проверить температуры компонентов.

Повторяющиеся сбои с разными кодами ошибок и разными «виновниками» — характерный признак именно аппаратной неисправности, а не программной. Один и тот же драйвер в каждом дампе, наоборот, указывает на конкретный программный источник проблемы.

FAQ: частые вопросы о файле MEMORY.DMP

Можно ли удалить MEMORY.DMP после анализа?

Да, после завершения диагностики файл можно удалить — он занимает заметное место на системном диске. При следующем сбое Windows создаст новый. Удаление не влияет на работу системы.

Почему двойной клик по MEMORY.DMP не работает?

Расширение .dmp не привязано к программам по умолчанию. Файл нужно открывать изнутри анализатора: через меню File в WinDbg или автоматическим сканированием в BlueScreenView. Назначать ассоциацию вручную не обязательно.

Чем отличается MEMORY.DMP от файлов в папке Minidump?

MEMORY.DMP — это полный дамп или дамп ядра, один большой файл, который перезаписывается при каждом сбое. Малые дампы в Minidump создаются отдельно для каждого инцидента и содержат только ключевую информацию о сбое, поэтому по ним удобно отслеживать историю и повторяемость ошибок.

WinDbg требует символы — что это и зачем?

Отладочные символы — это файлы, сопоставляющие адреса в памяти с именами функций и модулей. Без них анализ покажет только набор адресов. Команда .symfix настраивает автоматическую загрузку символов с серверов Microsoft, ручная настройка обычно не требуется.

Дамп показывает ntoskrnl.exe — это вирус или сломанная Windows?

Почти наверняка ни то ни другое. Ядро системы фигурирует в дампах потому, что сбой произошёл в его коде, но инициатором обычно бывает сторонний драйвер или неисправное железо. Ищите в выводе анализа сторонние .sys-модули и проверяйте оперативную память.