После синего экрана смерти Windows автоматически сохраняет файл MEMORY.DMP или мини-дамп в папке C:\Windows\Minidump — именно в нём записана причина сбоя: код ошибки, адрес в памяти и имя драйвера, вызвавшего падение системы. Открыть такой файл обычным блокнотом бесполезно: это бинарный снимок оперативной памяти в момент критической ошибки, и для его чтения нужны специальные инструменты вроде WinDbg или BlueScreenView.
В этом руководстве разберём, где Windows хранит дампы, какие бывают их типы, как открыть DMP-файл бесплатными программами и как по строке Probably caused by найти виновника сбоя — будь то драйвер видеокарты, антивирус или неисправная планка памяти.
Что такое DMP-файл и где его искать
Дамп памяти (crash dump) — это файл, в который операционная система записывает состояние памяти и процессора в момент критической ошибки. Когда ядро Windows встречает ситуацию, из которой не может восстановиться, оно останавливает работу, показывает BSOD и сохраняет дамп для последующей диагностики.
Расположение файлов зависит от типа дампа, который задан в настройках системы:
- 🔹 Малый дамп памяти (minidump) — файлы
.dmpв папкеC:\Windows\Minidump, имя содержит дату сбоя; - 🔹 Дамп памяти ядра — один файл
C:\Windows\MEMORY.DMP, перезаписывается при каждом новом сбое; - 🔹 Полный дамп памяти — тот же путь
MEMORY.DMP, но размер сопоставим с объёмом оперативной памяти; - 🔹 Автоматический дамп — вариант по умолчанию в современных версиях Windows, система сама выбирает объём данных.
Тип сохраняемого дампа задаётся в разделе Система → Дополнительные параметры системы → Загрузка и восстановление → Параметры. Там же можно отключить автоматическую перезагрузку при сбое — тогда код ошибки на синем экране останется перед глазами, и его можно будет сфотографировать.
⚠️ Внимание: если папка C:\Windows\Minidump пуста, проверьте, не отключена ли запись дампов, и достаточно ли места на системном диске. Также файл подкачки на системном разделе необходим для создания дампа — при его полном отключении дамп может не сохраняться.
Чем открыть DMP-файл: обзор инструментов
Для чтения дампов существует несколько программ разного уровня сложности. Выбор зависит от того, нужна ли вам быстрая подсказка или глубокий анализ стека вызовов.
| Инструмент | Разработчик | Сложность | Когда использовать |
|---|---|---|---|
| BlueScreenView | NirSoft | Минимальная | Быстро узнать код ошибки и драйвер-виновник |
| WhoCrashed | Resplendence | Низкая | Получить отчёт на понятном языке без ручного анализа |
| WinDbg (Preview) | Microsoft | Высокая | Профессиональный анализ стека, потоков и памяти |
| kd / cdb | Microsoft | Высокая | Консольная отладка, автоматизация, серверы |
Для большинства пользователей оптимальна связка: сначала BlueScreenView для быстрой оценки, затем WinDbg, если требуется подтверждение или детали. Официальный отладчик Microsoft даёт наиболее достоверную картину, но требует загрузки символов и понимания структуры отчёта.
Быстрый анализ в BlueScreenView
Утилита BlueScreenView от NirSoft не требует установки и сразу после запуска сканирует папку Minidump, показывая список всех зафиксированных сбоев. Вам не нужно вручную открывать файлы — программа сама подхватывает дампы из стандартного расположения.
Что отображает программа по каждому сбою:
- 🔍 Bug Check String — текстовое название ошибки, например
IRQL_NOT_LESS_OR_EQUAL; - 🔍 Bug Check Code — шестнадцатеричный стоп-код, например
0x0000000A; - 🔍 Caused By Driver — файл драйвера, который программа считает виновником;
- 🔍 Caused By Address — адрес в памяти, где произошёл сбой.
Ключевая колонка — Caused By Driver. Если там значится сторонний драйвер, например nvlddmkm.sys (видеокарта NVIDIA) или rtwlane.sys (Wi-Fi-адаптер Realtek), направление поиска понятно: обновление или откат этого драйвера. Если же указан системный файл вроде ntoskrnl.exe, это, как правило, означает, что истинный виновник скрыт глубже — часто это оперативная память, разгон или другой драйвер, испортивший данные ядра.
Профессиональный анализ в WinDbg
WinDbg — официальный отладчик Microsoft, который распространяется бесплатно через Microsoft Store (версия WinDbg Preview) или в составе Windows SDK. Именно этот инструмент используют инженеры поддержки, и именно его вывод считается эталонным при разборе дампов.
☑️ Подготовка и анализ дампа в WinDbg
Порядок работы следующий. Откройте программу, выберите File → Start debugging → Open dump file и укажите путь к файлу .dmp. При первом запуске отладчик подтянет символы отладки с публичного сервера Microsoft — без них имена функций в стеке будут нечитаемыми, поэтому нужно интернет-соединение и немного терпения.
После загрузки дампа выполните в командной строке отладчика главную команду анализа:
!analyze -vПолный разбор займёт от нескольких секунд до пары минут. В выводе ищите следующие поля: BUGCHECK_CODE — стоп-код ошибки, PROCESS_NAME — процесс, активный в момент сбоя, MODULE_NAME и IMAGE_NAME — модуль и файл драйвера, который анализатор считает виновным. Поле STACK_TEXT показывает стек вызовов: читать его нужно снизу вверх, от старых вызовов к последним.
Что делать, если символы не загружаются
Проверьте интернет-соединение и задайте путь к символам командой .symfix, которая автоматически указывает на сервер символов Microsoft. Затем выполните .reload, чтобы перезагрузить модули. Если конкретный сторонний драйвер остаётся без символов — это нормально: символы есть только у компонентов Microsoft и у производителей, которые их публикуют.
⚠️ Внимание: не доверяйте слепо строке Probably caused by. Автоматический анализ указывает модуль, в котором сработала проверка, а не обязательно истинную причину. Если виновником раз за разом называются разные системные файлы, подозревайте оперативную память, перегрев или нестабильный разгон, а не Windows.
Как интерпретировать результаты: типичные стоп-коды
Сам по себе код ошибки — это не диагноз, а направление поиска. Один и тот же стоп-код может быть вызван драйвером, железом или повреждением системных файлов, поэтому важно смотреть на связку «код + модуль + повторяемость».
Несколько распространённых примеров для ориентировки:
- 🧩
IRQL_NOT_LESS_OR_EQUAL— часто связан с драйверами или неисправной памятью; - 🧩
PAGE_FAULT_IN_NONPAGED_AREA— обращение к отсутствующей странице памяти; типичные подозреваемые — RAM и антивирусы; - 🧩
DPC_WATCHDOG_VIOLATION— драйвер слишком долго выполнял отложенный вызов; нередко виноваты драйверы накопителей или чипсета; - 🧩
SYSTEM_SERVICE_EXCEPTION— исключение в системном вызове, часто из-за сторонних драйверов или антивирусного ПО; - 🧩
KMODE_EXCEPTION_NOT_HANDLED— драйвер вызвал необработанное исключение; смотрите имя модуля рядом с кодом.
Если в дампе через запятую указан конкретный файл, например имя драйвера после стоп-кода на синем экране — самая ценная улика, совпадающая с полем IMAGE_NAME в WinDbg, начинайте с него: проверьте версию, дату и цифровую подпись файла. Драйвер двухлетней давности к свежему обновлению Windows — классический источник конфликтов.
Что делать, если дампы не создаются
Бывает, что синие экраны случаются регулярно, а папка Minidump пуста. В этом случае анализировать нечего, и первым делом нужно восстановить механизм записи дампов.
Проверьте базовые условия: в настройках Загрузка и восстановление должен быть выбран тип дампа, отличный от «Нет»; на системном диске должно быть достаточно свободного места; файл подкачки на системном разделе не должен быть полностью отключён. Дополнительно убедитесь, что служба, отвечающая за отчёты об ошибках, не заблокирована сторонними «оптимизаторами» — многие твикеры отключают запись дампов вместе с телеметрией.
⚠️ Внимание: не запускайте очистку диска или «чистильщики реестра» до завершения анализа — часть таких утилит удаляет файлы дампов и журналы событий, лишая вас единственного источника информации о сбое.
Параллельно с дампами полезно изучать Просмотр событий (eventvwr.msc): в журнале «Система» критические события с источником BugCheck дублируют стоп-код, а записи WHEA-Logger указывают на аппаратные ошибки процессора или памяти. Связка «журнал событий + дамп» даёт куда более уверенную картину, чем каждый источник по отдельности.
Часто задаваемые вопросы
Можно ли открыть DMP-файл без установки программ?
Полноценно — нет. Блокнот и онлайн-просмотрщики покажут лишь фрагменты текста внутри бинарного файла. Минимальный вариант — портативная утилита BlueScreenView, которая не требует установки и запускается с флешки.
Почему WinDbg показывает виновником ntoskrnl.exe?
ntoskrnl.exe — это ядро Windows, и оно почти всегда присутствует в стеке сбоя, потому что проверка сработала внутри системного кода. Реальная причина обычно в драйвере, испортившем данные ядра, в неисправной памяти или разгоне. Проверьте оперативную память диагностическими средствами и снимите разгон, если он есть.
Сколько хранятся дампы и можно ли их удалять?
Мини-дампы накапливаются в папке Minidump без автоматической очистки, а файл MEMORY.DMP перезаписывается при каждом новом сбое. После завершения диагностики дампы можно безопасно удалить — на работу системы это не влияет.
Чем отличается мини-дамп от полного дампа памяти?
Мини-дамп содержит только стоп-код, список загруженных драйверов и стек проблемного потока — этого достаточно для определения виновника в большинстве случаев. Полный дамп включает всё содержимое оперативной памяти и нужен для глубокой отладки, но занимает гигабайты места.
Дамп указывает на драйвер видеокарты. Что делать?
Обновите драйвер до актуальной версии с официального сайта производителя, а если сбои начались после обновления — откатите на предыдущую стабильную версию. При сохранении проблемы проверьте температуру видеокарты и стабильность блока питания: перегрев и просадки напряжения дают те же симптомы.