Повторяющийся синий экран смерти с кодом MEMORY_MANAGEMENT, IRQL_NOT_LESS_OR_EQUAL или KERNEL_SECURITY_CHECK_FAILURE — прямой повод выполнить анализ дампов памяти Windows, а не гадать наугад. Каждый раз, когда система аварийно завершается, она сохраняет снимок состояния памяти в файл дампа, и именно в нём записано, какой драйвер или процесс вызвал сбой. Без этого файла диагностика BSOD превращается в перебор догадок.
Дамп памяти — это не текстовый лог, а бинарный снимок, который читается специальными отладчиками. В этой статье разберём, где Windows хранит дампы, какие типы дампов существуют, чем отличаются WinDbg и BlueScreenView, и как по стеку вызовов определить виновника сбоя — от драйвера видеокарты до антивируса.
Где Windows хранит файлы дампов
По умолчанию система создаёт файлы дампов в двух местах. Полный дамп ядра пишется в C:\Windows\MEMORY.DMP, а малые дампы (minidump) — в папку C:\Windows\Minidump, где каждый файл получает имя по дате и времени сбоя. Папка Minidump может быть скрыта от обычного пользователя, поэтому для доступа потребуются права администратора.
Тип создаваемого дампа задаётся в настройках. Откройте Система → Дополнительные параметры системы → Загрузка и восстановление → Параметры и проверьте раздел «Запись отладочной информации». Там можно выбрать малый дамп памяти, дамп ядра, полный дамп или автоматический дамп памяти.
- 📄 Малый дамп (256 КБ) — минимум данных: код ошибки, список загруженных драйверов, стек сбойного потока. Достаточно для большинства домашних диагностик.
- 🧠 Дамп ядра — только память режима ядра, без пользовательских процессов. Оптимален по соотношению размера и информативности.
- 💾 Полный дамп памяти — весь объём ОЗУ. Используется редко, файл может занимать десятки гигабайт.
- ⚙️ Автоматический дамп — вариант по умолчанию в современных Windows, система сама управляет размером файла подкачки под дамп ядра.
⚠️ Внимание: если файл подкачки отключён или сильно ограничен, а также если на системном диске мало свободного места, дамп может не создаться вообще. Перед анализом убедитесь, что после очередного BSOD в папке Minidump появился новый файл.
Почему дампа нет: типичные причины
Частая ситуация — синий экран был, а файл не появился. Проверьте три вещи: включена ли запись отладочной информации в настройках восстановления, достаточно ли места на диске C и не стёр ли дамп чистильщик вроде CCleaner или встроенная «Очистка диска» (дампы памяти входят в список удаляемых системных файлов).
Ещё одна возможная причина — сбой происходит настолько рано или жёстко (например, внезапное отключение питания или критическая ошибка диска), что система физически не успевает записать дамп. В таком случае сам факт отсутствия дампа — уже диагностический признак, косвенно указывающий на проблему с питанием или накопителем.
Инструменты для анализа дампов
Для разбора дампов существует несколько инструментов разного уровня сложности. Новичкам проще начать с BlueScreenView или WhoCrashed — они показывают список сбоев и подсвечивают драйвер, который с высокой вероятностью вызвал падение. Профессиональный инструмент — WinDbg (есть классическая версия и современная WinDbg Preview из Microsoft Store).
| Инструмент | Уровень | Что показывает | Когда использовать |
|---|---|---|---|
| BlueScreenView | Начальный | Список BSOD, коды, подсветка драйвера | Быстрая первичная диагностика |
| WhoCrashed | Начальный | Отчёт текстом с предполагаемой причиной | Когда нужен готовый вывод без ручного разбора |
| WinDbg Preview | Продвинутый | Стек вызовов, параметры, состояние памяти | Глубокий анализ и неоднозначные сбои |
| Event Viewer | Начальный | Событие BugCheck с кодом ошибки | Когда дампа нет, но нужен хотя бы стоп-код |
WinDbg требует загрузки символов — файлов сопоставления адресов памяти с именами функций. Без них стек вызовов будет состоять из непонятных адресов. Символы подтягиваются с публичного сервера Microsoft, для этого в настройках отладчика задаётся путь к символам.
Даже если вы пользуетесь BlueScreenView, сохраните сами файлы дампов — позже их можно открыть в WinDbg для более глубокого анализа, если первичная диагностика не дала ответа.
Пошаговый анализ дампа в WinDbg
Установите WinDbg Preview из Microsoft Store, запустите его и откройте файл дампа через меню File → Open dump file. После загрузки выполните главную команду автоматического анализа:
!analyze -vКоманда выдаёт развёрнутый отчёт: стоп-код (bugcheck code), его параметры, стек вызовов сбойного потока и поле IMAGE_NAME или MODULE_NAME — имя модуля, который отладчик считает вероятным виновником. Именно это поле обычно и есть ответ: например, nvlddmkm.sys указывает на драйвер NVIDIA, rtwlane.sys — на драйвер Wi-Fi Realtek, ntoskrnl.exe — на ядро, что чаще всего означает проблему не в самом ядре, а в драйвере или железе, повредившем его данные.
☑️ Порядок анализа дампа в WinDbg
Дополнительно полезны команды lmvm имя_модуля (показывает версию и дату драйвера — устаревший драйвер сразу видно) и !thread (информация о потоке, в котором произошёл сбой). Дата драйвера — важная деталь: если модуль несколько лет не обновлялся, а система свежая, конфликт версий весьма вероятен.
⚠️ Внимание: указание наntoskrnl.exe,ntkrnlmp.exeилиwin32k.sysв отчёте почти никогда не означает, что виновата сама Windows. Эти модули ядра лишь «ловят» последствия чужой ошибки. Ищите в стеке вызовов сторонний.sys-драйвер выше по цепочке.
Как настроить путь к символам в WinDbg
В WinDbg Preview откройте File → Settings → Debugging settings и в поле Symbol path укажите строку вида SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols — локальная папка C:\Symbols будет использоваться как кэш, а недостающие символы загрузятся с сервера Microsoft при первом анализе.
Типичные виновники сбоев и что с ними делать
Анализ десятков дампов на одной и той же машине обычно выявляет закономерность: либо один и тот же драйвер, либо разные модули при разных стоп-кодах. Первый случай — почти наверняка виноват конкретный драйвер или связанное с ним устройство. Второй случай, когда виновник каждый раз разный, а коды ошибок меняются, — классический признак аппаратной проблемы: нестабильной оперативной памяти, перегрева, неисправного SSD или нестабильного блока питания.
- 🎮 Драйверы видеокарты (
nvlddmkm.sys,atikmdag.sys) — обновите драйвер чистой установкой; при повторах проверьте температуру GPU и стабильность разгона. - 🌐 Сетевые драйверы (Wi-Fi, Ethernet) — частая причина
IRQL_NOT_LESS_OR_EQUAL; помогает обновление с сайта производителя чипа, а не только через Windows Update. - 🛡️ Антивирусы и VPN — их фильтр-драйверы глубоко встраиваются в ядро; для проверки временно удалите продукт и понаблюдайте за системой.
- 🧩 Память и разгон — сбросьте XMP/EXPO-профиль и разгон в BIOS, прогоните тест памяти (например, MemTest86) на несколько проходов.
После каждого действия — обновления драйвера, замены компонента, сброса настроек — дайте системе поработать в обычном режиме и при новом сбое проанализируйте свежий дамп. Сравнение «до» и «после» — единственный надёжный способ подтвердить, что причина устранена.
Один и тот же драйвер в нескольких дампах — ищите проблему в нём. Разные модули и разные стоп-коды — проверяйте железо: память, температуры, питание.
Когда анализ дампов не даёт ответа
Иногда отладчик честно пишет Probably caused by: hardware или стек вырождается в пару неинформативных строк. Это нормально: дамп фиксирует момент краха, а не всю историю порчи данных. Если драйвер повредил память ядра задолго до сбоя, виновник в дампе не останется.
В таких случаях переходите к аппаратной диагностике: тест ОЗУ, проверка диска (SMART и поверхностный тест), мониторинг температур под нагрузкой, проверка питания. Для поимки неуловимого драйвера существует Driver Verifier (verifier.exe) — встроенный механизм усиленной проверки драйверов, который заставляет сбой проявиться сразу и с точным указанием виновника.
⚠️ Внимание: Driver Verifier — инструмент для опытных. Он намеренно делает систему менее стабильной и может привести к циклическому BSOD при загрузке. Перед включением создайте точку восстановления и убедитесь, что знаете, как отключить проверку из безопасного режима командой verifier /reset.
Включите Driver Verifier только для сторонних (не Microsoft) драйверов — этого обычно достаточно, и риск проблем с загрузкой заметно ниже.
Часто задаваемые вопросы
Чем открыть файл MEMORY.DMP?
Полный дамп открывается только отладчиком уровня WinDbg. Для быстрого просмотра используйте малые дампы из папки Minidump — их читают и BlueScreenView, и WinDbg, а информации для типовой диагностики в них достаточно.
Можно ли удалять файлы дампов?
Да, дампы не нужны системе для работы — это диагностические файлы. Удаляйте их после анализа, чтобы освободить место, но сохраните копии, если проблема ещё не решена: история сбоев помогает увидеть закономерность.
Дамп указывает на ntoskrnl.exe — это вирус или сломанная Windows?
Почти наверняка ни то ни другое. Модуль ядра лишь фиксирует последствия ошибки, допущенной другим драйвером или железом. Смотрите стек вызовов в отчёте !analyze -v и ищите сторонний .sys-модуль, а при разных виновниках проверяйте память и температуры.
Как проанализировать дамп с другого компьютера?
Скопируйте файлы из папки Minidump на свой ПК (потребуются права администратора на обеих машинах) и откройте их в WinDbg или BlueScreenView локально. Анализ не требует запуска на исходной системе.
Синие экраны есть, а папка Minidump пуста — что делать?
Проверьте настройки записи отладочной информации в «Загрузка и восстановление», убедитесь, что файл подкачки не отключён и на диске C достаточно места. Также откройте «Просмотр событий» и найдите событие BugCheck — по стоп-коду можно начать диагностику даже без дампа.