Стоп-код MEMORY_MANAGEMENT или IRQL_NOT_LESS_OR_EQUAL на синем экране — это лишь верхушка проблемы: настоящий виновник сбоя записан в файле дампа памяти, который Windows создаёт в момент краха системы. Без анализа этого файла поиск причины BSOD превращается в перебор догадок: меняют память, переустанавливают систему, а синий экран возвращается снова.
Дамп памяти — это снимок состояния оперативной памяти и системных структур в момент критической ошибки. В нём содержится стек вызовов, список загруженных драйверов и код исключения, по которым можно точно определить сбойный модуль. В этой статье разберём, где Windows хранит дампы, какие типы дампов существуют и как проанализировать их с помощью WinDbg и BlueScreenView.
Типы дампов памяти и где их искать
Windows умеет создавать несколько видов дампов, и от настройки зависит, хватит ли данных для анализа. Проверить текущий режим можно через Панель управления → Система → Дополнительные параметры системы → Загрузка и восстановление → Параметры. В разделе «Отказ системы» указан тип записываемой отладочной информации.
- 🧩 Малый дамп памяти (256 КБ) — сохраняется в папке
C:\Windows\Minidump, содержит стоп-код, параметры и краткий стек. Достаточен для большинства бытовых диагностик. - 🧩 Дамп памяти ядра — записывается в
C:\Windows\MEMORY.DMP, включает всю память режима ядра. Оптимален для глубокого анализа. - 🧩 Полный дамп памяти — копия всей оперативной памяти. Требуется редко, в основном разработчикам драйверов.
- 🧩 Автоматический дамп памяти — вариант по умолчанию в современных версиях Windows, система сама выбирает размер файла подкачки.
⚠️ Внимание: если в момент BSOD файл подкачки отключён или размещён не на системном диске, дамп может вообще не создаться. Перед диагностикой убедитесь, что файл подкачки существует и его размер не меньше объёма, рекомендованного системой.
Также проверьте, что включена опция «Записать событие в системный журнал» — тогда даже при отсутствии дампа в Просмотре событий останется запись с кодом BugCheck и параметрами ошибки. Это запасной источник информации.
Подготовка: настройка записи дампов
Прежде чем анализировать, нужно гарантировать, что система корректно сохраняет дампы при каждом сбое. Откройте параметры «Загрузка и восстановление» и выставьте малый дамп памяти — для поиска сбойного драйвера его обычно достаточно, а файлы занимают минимум места.
Снимите галочку «Выполнить автоматическую перезагрузку», если хотите успеть прочитать стоп-код прямо на синем экране. Правда, с дампом эта опция уже не критична — вся информация сохранится в файл.
☑️ Проверка перед анализом дампа
Если папка Minidump пуста после свежего синего экрана — проверьте свободное место на диске C и права доступа. Некоторые «чистильщики» системы удаляют дампы автоматически; временно отключите такие утилиты на период диагностики.
Анализ дампа в WinDbg
WinDbg — официальный отладчик Microsoft, самый точный инструмент для разбора дампов. Современная версия WinDbg Preview устанавливается из Microsoft Store, классическая входит в состав Windows SDK. После установки откройте файл дампа через File → Open Dump File.
Первым делом настройте сервер символов — без них стек вызовов будет показывать нечитаемые адреса вместо названий функций. Выполните в командной строке отладчика:
.symfix
.reload
!analyze -v
Команда !analyze -v запускает автоматический анализ: WinDbg определит код bugcheck, параметры исключения и укажет предполагаемый виновник в строке IMAGE_NAME или MODULE_NAME. Именно там чаще всего фигурирует имя сбойного драйвера, например nvlddmkm.sys (видеодрайвер NVIDIA) или rtwlane.sys (сетевой адаптер Realtek).
⚠️ Внимание: строка MODULE_NAME показывает модуль, в котором упало выполнение, но это не всегда первопричина. Если виновником указан системный файл вроде ntoskrnl.exe или ntkrnlmp.exe, реальная проблема обычно кроется в стороннем драйвере, памяти или разгоне — ядро лишь зафиксировало последствия.
Какие команды WinDbg полезны помимо !analyze -v
Команда lmvm имя_модуля покажет версию и дату драйвера — полезно проверить, не устарел ли он. Команда k выводит стек вызовов текущего потока, !process 0 0 — список процессов в момент сбоя, !irpfind помогает при анализе зависших запросов ввода-вывода. Для большинства бытовых случаев достаточно !analyze -v и просмотра IMAGE_NAME.
Быстрый анализ через BlueScreenView
Если возиться с отладчиком не хочется, утилита BlueScreenView от NirSoft покажет содержимое всех минидампов в удобной таблице. Программа не требует установки: запустите её, и она автоматически просканирует папку Minidump.
В верхней панели отображается список сбоев с датой, стоп-кодом и параметрами, в нижней — модули из стека, причём подозреваемый драйвер подсвечивается. Двойной клик по записи открывает детали конкретного сбоя. Этого достаточно, чтобы за пару минут понять, какой .sys-файл фигурирует в падениях чаще всего.
Альтернатива — WhoCrashed, который выдаёт заключение текстом и подсказывает, к какому устройству относится драйвер. Оба инструмента подходят для первичной диагностики, но при противоречивых результатах стоит вернуться к WinDbg.
Расшифровка популярных стоп-кодов
Код ошибки — первый ориентир при анализе. Вот наиболее частые bugcheck-коды и их типичные причины:
| Стоп-код | Вероятная причина | С чего начать |
|---|---|---|
| KMODE_EXCEPTION_NOT_HANDLED | Конфликт драйверов, сбойный .sys-файл | Обновить или откатить драйвер из MODULE_NAME |
| MEMORY_MANAGEMENT | Ошибки ОЗУ или работы с памятью | Тест memtest86, проверка XMP-профиля |
| IRQL_NOT_LESS_OR_EQUAL | Драйвер обратился к недопустимому адресу | Поиск сбойного драйвера, проверка антивируса |
| PAGE_FAULT_IN_NONPAGED_AREA | Дефект памяти или повреждённый драйвер | Тест ОЗУ, проверка диска chkdsk |
| DPC_WATCHDOG_VIOLATION | Драйвер слишком долго выполнялся | Обновление драйверов SSD/чипсета |
Учтите, что один и тот же стоп-код может иметь разные причины на разных машинах. Таблица задаёт направление поиска, а окончательный ответ даёт именно содержимое дампа — стек вызовов и имя модуля.
Что делать после определения виновника
Когда сбойный модуль найден, порядок действий зависит от того, чей это драйвер. Если имя файла указывает на конкретное устройство — видеокарту, сетевой адаптер, антивирус — начните с обновления драйвера с сайта производителя. Если сбои начались сразу после обновления, наоборот, выполните откат через Диспетчер устройств → свойства устройства → Драйвер → Откатить.
При подозрении на оперативную память (разные виновники в разных дампах, коды MEMORY_MANAGEMENT) прогоните тест memtest86 с загрузочной флешки. Если в BIOS включён профиль разгона памяти (XMP/EXPO) — временно верните стандартные частоты и понаблюдайте за стабильностью. Нестабильный разгон процессора даёт схожую картину: плавающие ошибки без явного закономерного виновника.
⚠️ Внимание: не удаляйте и не заменяйте системные .sys-файлы вручную из папки System32\drivers — это с высокой вероятностью сделает систему незагружаемой. Работайте только через штатные механизмы: установку, обновление и откат драйверов.
Если после замены или обновления драйвера BSOD исчез — зафиксируйте результат: сохраните последний проблемный дамп и версию драйвера. Это пригодится, если сбой вернётся после очередного обновления Windows.
Частые вопросы
Дамп не создаётся после BSOD — что проверить?
Убедитесь, что файл подкачки включён на системном диске, в настройках отказа системы выбран тип дампа, а на диске C достаточно свободного места. Также проверьте, не удаляет ли дампы сторонняя утилита очистки.
Можно ли анализировать дамп с другого компьютера?
Да. Скопируйте файл из папки C:\Windows\Minidump или MEMORY.DMP на рабочий ПК с установленным WinDbg, настройте символы командой .symfix и выполните !analyze -v — анализ ничем не будет отличаться.
Почему WinDbg показывает виновником ntoskrnl.exe?
Это ядро Windows — оно фиксирует сбой последним, но редко является причиной. Почти всегда за такой записью скрывается сторонний драйвер, нестабильная память или разгон. Смотрите глубже в стек вызовов и сравнивайте несколько дампов.
Сколько дампов нужно для достоверного вывода?
Один дамп даёт лишь предположение. Надёжный вывод строится на сравнении нескольких сбоев: повторяющийся модуль указывает на драйвер, а хаотичные разные виновники — на память, питание или разгон.
Опасно ли хранить старые дампы?
Нет, но они занимают место, особенно полные дампы ядра. После завершения диагностики старые файлы из Minidump и MEMORY.DMP можно удалить — на работу системы это не влияет.