Синий экран с кодом вроде IRQL_NOT_LESS_OR_EQUAL или PAGE_FAULT_IN_NONPAGED_AREA почти всегда оставляет после себя файл дампа памяти — и именно его разбор позволяет установить конкретный драйвер или модуль, спровоцировавший сбой, вместо беспорядочной переустановки системы. Без анализа дампа диагностика BSOD превращается в угадывание: меняются планки памяти, драйверы, обновления, а причина так и остаётся неизвестной.
В этой статье разберём, где Windows 10 хранит дампы, какие типы дампов существуют, как открыть их в WinDbg и BlueScreenView и как интерпретировать результаты, чтобы перейти от симптома к конкретному виновнику сбоя.
Что такое дамп памяти и зачем он нужен
Дамп памяти — это снимок содержимого оперативной памяти и состояния системы в момент критической ошибки. Когда ядро Windows обнаруживает состояние, при котором продолжение работы невозможно, оно останавливает систему (это и есть BSOD) и записывает отладочную информацию на диск. Именно этот файл затем читают отладчики.
По сути, дамп — это «чёрный ящик» операционной системы. В нём содержится стек вызовов в момент сбоя, список загруженных драйверов, код ошибки (bug check code) и параметры, которые помогают понять контекст: какой процесс был активен, к какой памяти шло обращение и какой модуль выполнялся последним.
Важно понимать: дамп не даёт готового ответа вида «замените планку ОЗУ». Он указывает направление диагностики — конкретный драйвер, службу или подсистему, — а дальнейшие выводы делаются с учётом контекста.
Типы дампов в Windows 10 и где они хранятся
Windows 10 поддерживает несколько форматов дампов, которые различаются объёмом сохраняемой информации. Тип настраивается в разделе Панель управления → Система → Дополнительные параметры системы → Загрузка и восстановление.
| Тип дампа | Расположение | Особенности |
|---|---|---|
| Малый дамп памяти (minidump) | C:\Windows\Minidump | Компактный файл, достаточен для большинства случаев анализа BSOD |
| Дамп памяти ядра | C:\Windows\MEMORY.DMP | Содержит память ядра, перезаписывается при каждом сбое |
| Полный дамп памяти | C:\Windows\MEMORY.DMP | Всё содержимое ОЗУ, требует места на диске, сопоставимого с объёмом памяти |
| Автоматический дамп памяти | C:\Windows\MEMORY.DMP | Вариант по умолчанию в Windows 10, система сама управляет размером файла подкачки |
Для повседневной диагностики удобнее всего малые дампы: на каждый сбой создаётся отдельный файл с датой в имени, поэтому можно сравнить несколько падений и выявить закономерность. Полный дамп нужен редко — в основном при глубокой отладке проблем ядра.
⚠️ Внимание: если после сбоя в папке C:\Windows\Minidump пусто, проверьте, не отключена ли запись дампов, не блокирует ли её сторонний «оптимизатор системы» и достаточно ли места на системном диске. Также дамп не создастся, если файл подкачки полностью отключён или сбой происходит до инициализации дисковой подсистемы.
Как настроить создание дампов
Перед анализом убедитесь, что система вообще сохраняет дампы. Откройте свойства системы и пройдите по пути Дополнительные параметры системы → Загрузка и восстановление → Параметры. В разделе «Отказ системы» должна быть включена запись отладочной информации.
Рекомендуемый порядок действий:
- 🔧 Выберите тип «Малый дамп памяти (256 kb)» — для рядовой диагностики этого достаточно.
- 📁 Проверьте путь сохранения — по умолчанию
%SystemRoot%\Minidump. - 💾 Убедитесь, что файл подкачки включён и находится на системном разделе — без него дамп может не записаться.
- 🔄 Оставьте включённой автоматическую перезагрузку при сбое, если хотите, чтобы система возвращалась в работу сама.
Если сбои регулярные, а дампы не появляются, возможная причина — стороннее ПО для «очистки», которое удаляет содержимое папки Minidump. Проверьте настройки таких программ или временно отключите их.
☑️ Подготовка к анализу дампа
Анализ дампа в WinDbg
WinDbg — официальный отладчик Microsoft, самый точный инструмент для разбора дампов. Свежую версию (WinDbg Preview) можно установить из Microsoft Store. Первый запуск требует настройки символов — без них отладчик покажет только адреса вместо читаемых имён функций.
Настройте путь к символам командой или через меню File → Settings → Debugging settings. Стандартная строка сервера символов Microsoft:
SRV*C:\Symbols*http://msdl.microsoft.com/download/symbolsЗатем откройте файл дампа через File → Open dump file и выполните команду:
!analyze -vАнализ займёт некоторое время — отладчик подгрузит символы и разберёт стек. В выводе обратите внимание на поля BUGCHECK_CODE (код ошибки), PROCESS_NAME (активный процесс) и IMAGE_NAME / MODULE_NAME — имя модуля, который отладчик считает вероятным виновником сбоя.
Здесь нужна осторожность: модуль, указанный в MODULE_NAME, — это вероятный, а не гарантированный виновник. Например, если указан системный файл ntoskrnl.exe, реальная причина часто кроется в стороннем драйвере или неисправной памяти — ядро лишь зафиксировало последствие. Сравните вывод по нескольким дампам: повторяющийся сторонний .sys-файл — гораздо более сильный сигнал.
Быстрый разбор через BlueScreenView
Если WinDbg кажется избыточным, утилита BlueScreenView от NirSoft покажет список всех минидампов в читаемом виде: код ошибки, параметры, время сбоя и подсвеченные драйверы, которые участвовали в падении стека. Программа не требует установки и настройки символов.
Работа с ней сводится к трём шагам: запустите утилиту, выберите дамп в верхней панели и посмотрите на нижнюю — модули, отмеченные розовым, находились в стеке вызовов на момент сбоя. Имя файла вроде nvlddmkm.sys (видеодрайвер NVIDIA), rtwlane.sys (сетевой адаптер Realtek) или iaStorAC.sys (контроллер Intel RST) сразу сужает круг поиска.
- 🎯 Сравните несколько дампов: один и тот же драйвер в разных сбоях — почти наверняка источник проблемы.
- 🧩 Разные модули в каждом дампе и разные коды ошибок — типичный признак неисправной оперативной памяти или нестабильного разгона.
- 🛡️ Драйвер антивируса в стеке — попробуйте временно заменить его и понаблюдать.
- 🎮 Сбои только в играх с видеодрайвером в стеке — начните с чистой переустановки драйвера GPU.
Интерпретация результатов: частые сценарии
Определив модуль, переходите к действиям. Если виновник — сторонний драйвер, логика проста: обновите его до актуальной версии с сайта производителя устройства или, наоборот, откатите, если сбои начались после обновления. Для видеодрайверов эффективна чистая переустановка с предварительным удалением старой версии.
Сложнее случай, когда в дампах фигурируют системные файлы (ntoskrnl.exe, ntfs.sys, win32k.sys). Сами по себе они редко бывают причиной — чаще это «пострадавшие». В такой ситуации проверяйте фундамент: протестируйте ОЗУ (например, встроенным средством mdsched.exe или MemTest86), проверьте диск командой chkdsk и целостность системных файлов:
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
⚠️ Внимание: не удаляйте и не заменяйте вручную системные файлы вроде ntoskrnl.exe, даже если они указаны в дампе. Это не устранит причину сбоя, но может сделать систему незагружаемой. Работайте с реальным источником проблемы: драйвером, памятью, диском или разгоном.
Если разгон присутствует (процессор, память с XMP-профилем, видеокарта) — первым делом верните штатные частоты и понаблюдайте. Нестабильный разгон даёт хаотичные BSOD с самыми разными кодами, и ни один анализ дампа не укажет на него прямо.
Что делать, если дампов несколько и виновники разные
Хаотичные сбои с разными модулями и кодами ошибок чаще всего указывают на аппаратный уровень: неисправную или несовместимую оперативную память, нестабильный блок питания, перегрев или разгон. Порядок действий: сбросьте разгон и XMP, протестируйте каждую планку ОЗУ по отдельности, проверьте температуры под нагрузкой и состояние диска через SMART. Программная переустановка драйверов в этом сценарии обычно не помогает.
Когда дамп не помогает
Бывают ситуации, где анализ заходит в тупик. Если система зависает намертво без BSOD, дамп не создаётся вовсе — тогда применяют ручную инициализацию аварийного дампа или диагностируют железо напрямую. Если сбой происходит на раннем этапе загрузки, дамп также может не записаться.
В таких случаях опорными точками становятся журнал событий Windows (Просмотр событий → Журналы Windows → Система), монитор стабильности системы (perfmon /rel) и аппаратная диагностика. Анализ дампа — мощный, но не единственный инструмент, и комбинировать его с другими источниками данных — нормальная практика.
Частые вопросы об анализе дампов
Можно ли открыть дамп с другого компьютера?
Да. Файл .dmp можно скопировать на любой ПК с установленным WinDbg или BlueScreenView и проанализировать там. Для корректной работы WinDbg потребуется доступ в интернет для загрузки символов с сервера Microsoft.
Что означает ntoskrnl.exe в результатах анализа?
Это ядро Windows, и оно почти никогда не является первопричиной. Указание на ntoskrnl.exe означает, что сбой зафиксирован на уровне ядра, а реальный источник — сторонний драйвер, неисправная память или разгон. Ищите закономерности в нескольких дампах и проверяйте ОЗУ.
Почему папка Minidump пуста после синего экрана?
Возможные причины: отключена запись отладочной информации в настройках «Загрузка и восстановление», отключён файл подкачки, не хватает места на системном диске или сторонняя программа очистки удаляет дампы. Проверьте эти пункты по очереди.
Опасно ли хранить дампы и можно ли их удалять?
Дампы безопасны — это обычные файлы, которые можно удалить после анализа. Учтите только, что полный дамп теоретически может содержать фрагменты данных из оперативной памяти, поэтому не стоит передавать его незнакомым лицам. Малые дампы содержат минимум такой информации.
Нужно ли платить за WinDbg или BlueScreenView?
Нет. WinDbg распространяется Microsoft бесплатно (в том числе через Microsoft Store), BlueScreenView — бесплатная утилита NirSoft. Встречающиеся в сети «платные анализаторы дампов» не дают преимуществ перед этими инструментами.