Синий экран с кодом вроде IRQL_NOT_LESS_OR_EQUAL или PAGE_FAULT_IN_NONPAGED_AREA — это лишь верхушка проблемы: настоящая причина сбоя записывается системой в файл дампа памяти, и без специальной программы его не прочитать. Windows сохраняет такие файлы в папке C:\Windows\Minidump (малые дампы) или как единый файл C:\Windows\MEMORY.DMP (полный дамп), однако открыть их обычным текстовым редактором бессмысленно — данные хранятся в бинарном формате.
Программа для анализа дампов памяти декодирует эти файлы и показывает, какой драйвер, модуль или системный процесс вызвал критическую ошибку. В этой статье разберём основные инструменты — от простых утилит для новичков до профессионального отладчика Microsoft, а также пошаговый порядок анализа и типичные ошибки интерпретации результатов.
Что такое дамп памяти и когда он создаётся
Дамп памяти — это снимок содержимого оперативной памяти и состояния системы в момент критического сбоя. Операционная система создаёт его автоматически, когда происходит ошибка уровня ядра: тот самый «синий экран смерти» (BSOD). Без дампа диагностика превращается в гадание, потому что код ошибки на экране часто слишком общий.
Windows умеет формировать несколько типов дампов, и от настройки зависит, сколько информации будет доступно для анализа:
- 🔹 Малый дамп (minidump) — компактный файл с базовой информацией: код ошибки, список загруженных драйверов, стек вызовов. Сохраняется в
C:\Windows\Minidump. - 🔹 Дамп памяти ядра — содержит только память, занятую ядром и драйверами, без пользовательских процессов.
- 🔹 Полный дамп памяти — весь объём ОЗУ; самый информативный, но и самый тяжёлый файл.
- 🔹 Автоматический дамп — вариант, при котором система сама управляет размером файла подкачки для записи дампа.
Проверить текущую настройку можно через Панель управления → Система → Дополнительные параметры системы → Загрузка и восстановление → Параметры. Обратите внимание: если запись отладочной информации отключена или файл подкачки слишком мал, дамп после синего экрана просто не создастся — и анализировать будет нечего.
⚠️ Внимание: если после BSOD в папке C:\Windows\Minidump пусто, не спешите искать «неисправную» программу анализа. Сначала убедитесь, что в настройках восстановления выбран тип дампа, а файл подкачки не отключён и находится на системном диске.
Обзор популярных программ для анализа дампов
Выбор инструмента зависит от вашей задачи. Нужно быстро узнать виновный драйвер — хватит лёгкой утилиты. Требуется глубокая отладка со стеком вызовов и символами — понадобится профессиональный отладчик.
| Программа | Разработчик | Уровень | Особенности |
|---|---|---|---|
| BlueScreenView | NirSoft | Новичок | Список всех BSOD, подсветка сбойного драйвера |
| WhoCrashed | Resplendence | Новичок | Отчёт на понятном языке, вероятная причина сбоя |
| WinDbg | Microsoft | Продвинутый | Полноценная отладка, загрузка символов, команды анализа |
| WinDbg Preview | Microsoft | Продвинутый | Современный интерфейс классического WinDbg |
BlueScreenView сканирует папку с минидампами и выводит таблицу всех зафиксированных сбоев: дату, код ошибки и модули, загруженные в момент падения. Драйвер, который программа считает вероятным виновником, подсвечивается на нижней панели. Это самый быстрый способ получить первую зацепку.
WhoCrashed идёт дальше и формирует текстовое заключение: какой драйвер предположительно вызвал сбой и к какому устройству или ПО он относится. Утилита полезна, когда нужно объяснение «человеческим языком», но её выводы стоит воспринимать как подсказку, а не окончательный вердикт.
WinDbg — официальный отладчик Microsoft, входящий в состав Windows SDK. Именно анализ команды !analyze -v в WinDbg считается эталонным способом разбора дампа: он показывает стек вызовов, контекст процессора и конкретный модуль, на котором произошло исключение. Порог входа выше, зато и точность максимальная.
Быстрый анализ в BlueScreenView
Для первичной диагностики вам не потребуется ничего, кроме самой утилиты и папки с минидампами. Программа портативная — установка не нужна, достаточно распаковать архив и запустить исполняемый файл.
Порядок действий выглядит так:
- 📂 Запустите BlueScreenView — программа автоматически загрузит дампы из
C:\Windows\Minidump. - 🔍 Выберите нужный дамп в верхней панели по дате и времени сбоя.
- 🎯 В нижней панели найдите модуль, выделенный розовым цветом, — это предполагаемый виновник.
- 🧩 Сопоставьте имя файла (например,
nvlddmkm.sysотносится к драйверу видеокарты NVIDIA,rtwlane.sys— к сетевому адаптеру Realtek) с устройством или программой.
Важный нюанс: если виновником указан системный файл вроде ntoskrnl.exe или hal.dll, это почти никогда не означает повреждение самого ядра. Ядро лишь фиксирует ошибку, которую спровоцировал сторонний драйвер или неисправное оборудование — чаще всего оперативная память. В таком случае требуется более глубокий анализ в WinDbg.
Профессиональный разбор в WinDbg
Когда простые утилиты не дают однозначного ответа, необходимо открыть дамп в WinDbg. Отладчик распространяется бесплатно: классическая версия входит в состав Windows SDK (при установке достаточно отметить только компонент Debugging Tools for Windows), а WinDbg Preview доступен в Microsoft Store.
Ключевой элемент точного анализа — символы отладки. Это файлы, сопоставляющие адреса памяти с именами функций Windows. Без них стек вызовов будет состоять из непонятных адресов. Сервер символов Microsoft подключается командой:
.symfix
.reload
После загрузки символов откройте дамп через File → Open Dump File и выполните главную команду анализа:
!analyze -vВ выводе обратите внимание на поля BUGCHECK_CODE (код ошибки), IMAGE_NAME и MODULE_NAME — именно они указывают на модуль, вызвавший исключение. Дополнительно полезна команда lmvm имя_модуля, которая показывает версию и дату драйвера: устаревший драйвер — частый кандидат на обновление.
☑️ Порядок анализа дампа в WinDbg
Почему WinDbg иногда показывает «wrong symbols» или пустой стек
Такое происходит, если символы не загрузились (нет интернета или неверный путь к серверу символов), либо дамп обрезан — например, из-за нехватки места на диске в момент записи. Проверьте настройки типа дампа и повторите загрузку символов командой .reload /f.
Типичные причины сбоев по результатам анализа
Получив имя модуля, вы только начинаете диагностику. Один и тот же код ошибки может иметь разные первопричины, поэтому действуйте от простого к сложному.
Если виновником указан драйвер устройства (видеокарта, сетевой адаптер, антивирус), первым шагом обновите его до актуальной версии с сайта производителя либо, наоборот, откатите — если сбои начались сразу после обновления. Драйверы антивирусов и системных утилит нередко конфликтуют между собой, и временное удаление такого ПО помогает подтвердить догадку.
Если анализ указывает на ядро (ntoskrnl.exe) или модули управления памятью, возможная причина — неисправная оперативная память или нестабильный разгон. Проверьте ОЗУ штатным средством mdsched.exe или утилитой MemTest86, а также сбросьте настройки XMP/разгона в BIOS на значения по умолчанию. Ещё один источник подобных ошибок — повреждённые системные файлы, которые проверяются командой:
sfc /scannow⚠️ Внимание: не удаляйте и не заменяйте файлы драйверов вручную в папке System32\drivers, руководствуясь только именем из дампа. Некорректная замена может сделать систему незагружаемой. Используйте штатные механизмы: обновление, откат драйвера через Диспетчер устройств или безопасный режим.
Частые ошибки при анализе дампов
Первая типичная ошибка — выводы по единственному дампу. Один сбой может быть случайностью, а вот серия дампов с повторяющимся модулем или кодом ошибки — уже устойчивая закономерность. Сравнивайте несколько файлов из папки Minidump за разные даты.
Вторая ошибка — игнорирование контекста. Вспомните, что менялось в системе перед началом сбоев: новое устройство, обновление драйвера, установка антивируса, разгон. Дамп подтверждает или опровергает такие гипотезы, но не заменяет их.
Третья ловушка — слепое доверие автоматическим заключениям утилит вроде WhoCrashed. Они строят предположение по верхнему модулю стека, который не всегда является первопричиной. При противоречивых результатах сверяйтесь с полным выводом !analyze -v.
⚠️ Внимание: файлы дампов могут содержать фрагменты данных из оперативной памяти, включая личную информацию. Перед тем как отправлять дамп на форум или стороннему специалисту, предпочтительнее использовать малый дамп (minidump) — в нём минимум пользовательских данных.
FAQ: частые вопросы об анализе дампов памяти
Где Windows хранит файлы дампов памяти?
Малые дампы сохраняются в папке C:\Windows\Minidump, а полный дамп или дамп ядра — в файл C:\Windows\MEMORY.DMP. Путь можно изменить в настройках «Загрузка и восстановление».
Папка Minidump пуста после синего экрана. Что делать?
Проверьте, что в параметрах восстановления выбран тип записи отладочной информации, файл подкачки включён и расположен на системном диске, а на диске достаточно свободного места. Также дамп не создастся, если система перезагружается быстрее, чем успевает его записать.
Какая программа лучше для новичка?
Для первичной диагностики удобнее BlueScreenView или WhoCrashed — они не требуют настройки и сразу показывают предполагаемый сбойный драйвер. WinDbg стоит осваивать, когда простых утилит недостаточно.
Дамп указывает на ntoskrnl.exe — значит, повреждена Windows?
Не обязательно. Модуль ядра чаще всего лишь фиксирует ошибку, вызванную сторонним драйвером или неисправной памятью. Проверьте ОЗУ тестом MemTest86 и целостность системных файлов командой sfc /scannow, прежде чем переустанавливать систему.
Можно ли анализировать дамп с другого компьютера?
Да. Скопируйте файлы дампов на свой ПК и откройте их в BlueScreenView (через настройку папки с дампами) или в WinDbg. Для точного анализа в WinDbg потребуется доступ в интернет для загрузки символов.