Синего экрана смерти больше нет. Точнее, экран‑то есть, просто не синий, а черный. Поменяли его еще в 24H2, заодно убрав и грустный смайлик, и QR‑код. Остались только стоп‑код да имя сбойного драйвера. Вот только компьютеры на Windows как уходили в незапланированный ребут, так и уходят. И цвет фона тут вообще ни на что не влияет. Значит, надо разбираться, что вся эта тарабарщина значит.

Стоп‑код вам ничего не скажет

Первое, что делает нормальный человек, увидев на экране надпись IRQL_NOT_LESS_OR_EQUAL, — идет гуглить эту надпись. И находит примерно ничего.

А все потому, что стоп‑код — это никакой не диагноз, а симптом. Причем довольно расплывчатый. Он сообщает, в какой момент ядро поняло, что дальше работать нельзя, но молчит о том, кто именно довел его до такого состояния. Один и тот же IRQL_NOT_LESS_OR_EQUAL вам выдадут и кривой сетевой драйвер, и разогнанная память, и антивирус, полезший туда, куда не следовало.

Пара самых ходовых стоп‑кода, чтобы было понятно, о чем речь:

• IRQL_NOT_LESS_OR_EQUAL (0xA). Кто‑то обратился к памяти на слишком высоком уровне прерывания. Классика драйверных косяков, хотя прилететь может и от битой планки.

• SYSTEM_SERVICE_EXCEPTION (0×3B). Исключение при переходе из пользовательского режима в режим ядра. Тоже чаще всего драйвер.

• PAGE_FAULT_IN_NONPAGED_AREA (0×50). Обращение к странице памяти, которой нет. Тут вилка ровно посередине между кривым драйвером и умирающей оперативкой.

• WHEA_UNCORRECTABLE_ERROR (0×124). А вот это уже почти всегда железо. Про него будет отдельный разговор.

Заметили закономерность? Как нет? Но ведь ее отсутствие — это тоже закономерность. А ведь и правда — почти везде получается или одно, или другое, только точного ответа вам никто не дает. И пока вы не заглянете в дамп, гадание на кофейной гуще так и останется гаданием.

Где лежит дамп и как его открыть

Каждый раз, когда система падает, она пишет минидамп — небольшой файл со слепком состояния ядра на момент краха. Лежат эти файлы в C:\Windows\Minidump, весят по паре сотен килобайт и никуда сами не деваются.

Если папки нет или она пустая, значит запись дампов отключена. В принципе это лечится. Идем в свойствах системы: Дополнительные параметры системы → Загрузка и восстановление → Параметры, и там в списке должно стоять Малый дамп памяти или Автоматический дамп памяти.

Только учтите, что для прошлых падений это уже не поможет. Дампы создаются с момента включения настройки и обратной силы не имеют. Как и попытки разогнать Windows программно, кстати.

Хотя бывает еще обиднее: настройка включена, а дампа все равно нет. Такое случается, когда система падает слишком жестко и просто не успевает ничего записать, или когда отключен файл подкачки на системном диске — без него писать дамп физически некуда. Ну и всякие чистильщики мусора любят подчищать эту папку без спроса.

Читать их будем через WinDbg. Сразу совет новичкам: не бойтесь, ничего страшного там нет. Ставится он из Microsoft Store, весит немного и денег не просит. Главное — действовать поэтапно:

1. Запускаем WinDbg от администратора, иначе он не сможет увидеть системную папку.

2. Прописываем путь к символам: File → Settings → Debugging settings → Symbol path, туда вставляем srv*C:\symbols*https://msdl.microsoft.com/download/symbols. Символы — это отладочная информация от Microsoft, без которой вместо имен функций вы увидите голые адреса.

3. Открываем сам дамп через File → Open dump file и ждем, пока внизу пропадет надпись про загрузку символов. В первый раз это займет минуту‑другую, потом все ляжет в кэш и будет открываться мгновенно.

Ну а дальше вводим !analyze ‑v и жмем ввод. Флаг ‑v,кстати, тут обязателен: без него вывод сокращается, и половина полезных полей просто не покажется.

Что читать в простыне вывода

Команда выплюнет экрана три текста, из которых вам нужны буквально четыре строчки.

BUGCHECK_CODE. Тот же стоп‑код, только в шестнадцатеричном виде. Мы такой уже видели на экране, так что тут ничего нового.

BUGCHECK_P1 — BUGCHECK_P4. А вот это интереснее. У каждого стоп‑кода есть четыре аргумента, и в них лежит вполне себе конкретная конкретика. Для 0xA и 0xD1, например, расклад такой: первый аргумент — это адрес, к которому обратились, второй — уровень прерывания, на котором это произошло, третий говорит, читали там или писали (0 и 1 соответственно), а четвертый содержит адрес инструкции, которая все это затеяла.

То есть уже по этим четырем цифрам видно, что случилось. Если в первом аргументе что‑то вроде 0000000000000000, значит кто‑то полез по нулевому указателю. А если там значение вида ffffffffffffffff или другой мусор, скорее всего речь идет о повреждении памяти.

IMAGE_NAME. Имя файла, на котором все сломалось. Вот это главное.

MODULE_NAME. То же самое, но без расширения.

PROCESS_NAME. Что за процесс работал в момент падения. Иногда сразу показывает виновника: если там висит имя какой‑нибудь программы, а не System, копать стоит в ее сторону.

И отдельно стоит запомнить FAILURE_BUCKET_ID, строку вида 0×3B_c0000005_somefilter!Unknown. Штука полезная тем, что по ней удобно гуглить. Если у кого‑то была ровно та же проблема, вы найдете обсуждение за минуту.

Есть еще одна тонкость. Иногда IMAGE_NAME и FAULTING_MODULE показывают разные файлы — тогда начинать надо с IMAGE_NAME, он обычно ближе к реальной причине.

Читаем стек вызовов

Впрочем, четырьмя строчками дело не ограничивается. Самое полезное в дампе это стек вызовов, то есть цепочка функций, которые привели систему к падению. Смотреть его нужно почти всегда, потому что именно там видно, кто кого позвал.

Команд для этого несколько, и различаются они уровнем подробностей:

• k показывает голый стек, без ничего.

• kb добавляет к нему первые три параметра каждого вызова.

• kn нумерует фреймы, что удобно, когда стек длинный.

• kv выводит еще и трапфреймы, то есть места перехода между режимами. Пожалуй, самый информативный вариант.

Выглядит результат примерно так:

# Child‑SP RetAddr Call Site

00 fffff20bba7fdfb0 fffff80223ae5e07 tcpip!FlpReturnNetBufferListChain+0×63ebe

01 fffff20bba7fe010 fffff80223ae5c28 NETIO!NetioDereferenceNetBufferList+0×87

02 fffff20bba7fe060 fffff80223bf2ca0 fffff802`23c56b5e

Читается это снизу вверх, совсем как филиппинский алфавит: самый нижний фрейм случился раньше всех, верхний — последним, прямо перед падением.

И вот тут есть маленький лайфхачик. Обратите внимание на третью строку: там вместо имени функции указан просто адрес. Если так, это почти наверняка сторонний драйвер. Символы‑то есть только для системных модулей, а для драйверов от NVIDIA (говорят, кстати, что они лучше, чем у AMD — почитайте, там много интересного, Realtek или какого‑нибудь производителя мышек их не существует в природе — вот WinDbg и показывает голый адрес, потому что расшифровать его нечем.

Чтобы понять, чей это адрес, есть команда ln. Скармливаете ей адрес, а она отвечает, между какими известными функциями он находится и какому модулю принадлежит.

Ну и напоследок пара команд, которые экономят время:

• bugcheck — код и аргументы падения без всей простыни!analyze ‑v.

• vertarget — версия системы и время работы до краха. Второе полезнее, чем кажется: если система падает ровно через десять минут после старта, это уже зацепка.

• lmi имямодуля — полные данные о модуле, включая контрольные суммы и время сборки.

Кстати, про ограничения. Минидамп при открытии честно предупреждает: доступны только регистры и стек вызовов. Больше там ничего и нет, так что команды вроде!process или!pool работать не будут. Для них нужен полный дамп ядра, который весит уже гигабайты и включается там же, в настройках загрузки и восстановления.

Почему строчка Probably caused by врет

А вот теперь самое главное, из‑за чего половина разборов дампов заканчивается неправильными выводами.

WinDbg в конце анализа выдает строку Probably caused by и подставляет туда имя модуля. Выглядит как приговор, читается как приговор — и люди идут переустанавливать именно этот драйвер. Только вот это никакой не приговор, а подсказка. Причем подсказка, которая ошибается регулярно.

Классический пример — Wdf01000.sys. Увидели такое в дампе? Так вот, никакой это не виновник, а Windows Driver Framework. То есть прослойка, через которую работает добрая половина драйверов в системе. Упасть на ней может кто угодно, и сама она тут совершенно ни при чем.

Та же история с ntoskrnl.exe и ntkrnlmp.exe. Это ядро Windows. Если бы падало оно само, оно бы у всех падало.

А еще Probably caused by промахивается, когда реальная причина вообще не в софте: битая память, перегрев, нестабильный разгон, дохнущий процессор. Ядро в такой ситуации падает на первом же модуле, которому не повезло оказаться в неправильном месте, и его имя попадает в отчет. Драйвер невиновен, просто оказался рядом.

Есть, кстати, показательный пример из учебных материалов. Систему роняли специально, тестовым драйвером myfault.sys, то есть виновник был известен заранее. А WinDbg в дампе написал следующее:

BugCheck D1, {e1071800, 1c, 0, f7cda403}

*** ERROR: Module load completed but symbols could not be loaded for myfault.sys

Probably caused by: memory_corruption

Обратите внимание на две вещи. Во‑первых, вердикт указывает на повреждение памяти, хотя память тут абсолютно здорова. А во‑вторых, строчкой выше честно написано, что для myfault.sys символов нет. То есть виновник в дампе присутствует, просто анализатор его не опознал и списал все на память.

Вот примерно так это и работает в реальной жизни. Строчка с ошибкой загрузки символов часто оказывается полезнее самого вердикта.

Так что первым делом смотрим, что за файл в IMAGE_NAME:

• Сторонний драйвер вроде nvlddmkm.sys, rtwlane.sys или atikmdag.sys. Уже теплее, есть с кем работать.

• Системный файл Microsoft, то есть ntoskrnl.exe, hal.dll или Wdf01000.sys. Почти наверняка ложный след.

• Файл от программы, которую вы ставили руками. Антивирусы, всякие ускорители, драйверы для мышек с подсветкой. Вот эти ребята попадают в дампы чаще всех.

Нашли конкретный сторонний драйвер — прогоните по нему lmvm имядрайвера, например lmvm nvlddmkm. Команда покажет версию, дату сборки и путь к файлу.

И вот на дату посмотрите внимательно, потому что это отдельный сюжет. После перехода на 25H2 в поддержку посыпались жалобы на массовые падения, и разбор дампов раз за разом показывал одну картину: сетевые драйверы, собранные задолго до нового ядра. Скажем, интеловский e1d.sys образца июля 2024-го или реалтековский беспроводной от июня 2025-го. Оба прекрасно жили на 24H2 и оба посыпались на новом ядре.

Так что если падения начались сразу после обновления системы, а в дампе висит сторонний драйвер старше пары лет — вот вам и ответ. Ищите свежую версию на сайте производителя, потому что Windows в такой ситуации обычно уверяет, что установлен самый актуальный драйвер.

Когда виновато железо: разбираем WHEA

Отдельный случай — код 0×124, он же WHEA_UNCORRECTABLE_ERROR. Тут можно сразу выдохнуть: с драйверами это почти никогда не связано.

Аббревиатура расшифровывается как Windows Hardware Error Architecture. Это механизм, через который железо сообщает системе, что у него что‑то стряслось. И падение с таким кодом означает ровно одно: процессор поймал ошибку, которую не смог исправить.

Первый аргумент в дампе тут решает многое:

• Ноль. Фатальный machine check: ошибку поймали, исправить не смогли, система легла.

• Единица. Исправленный machine check. Такие обычно систему не роняют, но в логах остаются.

Дальше начинается неприятное. Второй аргумент содержит адрес структуры WHEA_ERROR_RECORD, где лежат все подробности. Вот только в минидамп эта структура обычно не попадает. Поэтому 0×124 и считается самым паршивым кодом для разбора: WinDbg покажет, что ошибка была, но не скажет какая.

Зато есть обходной путь, и работает он отлично.

Открываем Просмотр событий, идем в Журналы Windows → Система и фильтруем по источнику WHEA‑Logger. Ищем события с идентификатором 17, 18, 46 или 47. Внутри будет примерно такое:

Reported by component: Processor Core

Error Source: Machine Check Exception

Error Type: Cache Hierarchy Error

Processor APIC ID: 5

И вот тут уже есть с чем работать.

• Error Type говорит, где именно сломалось. Cache Hierarchy Error означает проблему с кэшем процессора, Translation Lookaside Buffer Error это сбой при обращении к буферу трансляции адресов, а Bus/Interconnect Error намекает, что процессор и остальная система чего‑то не поделили.

• Processor APIC ID — это номер логического ядра, на котором все случилось. Вот тут самое интересное. Соберите несколько событий подряд и посмотрите на этот номер. Каждый раз разный? Скорее всего дело в памяти или питании. А если ошибки упорно лезут с одного и того же ядра, вопрос уже к процессору.

Кстати, если разгон включен — снимите его первым делом, до всякой диагностики. Больше половины историй с 0×124 заканчиваются именно на этом.

Driver Verifier: мощно, но опасно

Допустим, дампы не помогли: там раз за разом системные модули, а падения продолжаются. Тогда есть тяжелая артиллерия — Driver Verifier.

Работает он так: нагружает выбранные драйверы дополнительными проверками, ловит их на нарушениях и роняет систему принудительно, но уже с внятным указанием виновника. То есть вы сознательно устраиваете себе синие экраны, чтобы поймать нарушителя за руку.

Только сперва прочитайте предупреждение, потому что оно серьезное. Если проблемный драйвер грузится при старте Windows, вы получите петлю из падений и в систему больше не войдете. Совсем. Вытаскивать придется через среду восстановления, а в тяжелых случаях — откатом из образа.

Поэтому порядок такой:

1. Сначала точка восстановления. Не пропускайте этот шаг, серьезно.

2. Запускаем verifier от администратора и выбираем создание нестандартных параметров.

3. Проверяем только сторонние драйверы. Не все подряд — иначе система ляжет от проверок Microsoft, и толку не будет.

4. Работаем как обычно, ждем падения. Обычно хватает суток‑двух.

5. После падения открываем дамп — там уже будет конкретное имя.

Ну а выключается все это командой verifier /reset с перезагрузкой. Если система не грузится, лезем в среду восстановления через тройное прерывание загрузки: Поиск и устранение неисправностей → Дополнительные параметры → Командная строка, и оттуда та же команда. Есть еще verifier /bootmode resetonbootfail — она автоматически отключает проверку, если система не смогла загрузиться. Ставить ее лучше сразу, вместе с остальными настройками.

Как отличить драйвер от железа

Собрал в короткий список, чтобы не гадать:

• Падает всегда при одном и том же действии. Запуск конкретной игры, подключение флешки, выход из сна. Драйвер, почти наверняка.

• Падает случайно, в разное время, с разными стоп‑кодами. А вот это уже похоже на железо. Особенно если коды каждый раз новые, потому что битая память умеет ронять систему десятком разных способов.

• В журнале есть WHEA‑Logger. Железо, тут даже думать нечего.

• Началось после обновления драйвера или установки программы. Ну, с этим все понятно.

• Началось после разгона или апгрейда памяти. Снимаем разгон, проверяем профиль XMP, гоняем memtest.

• Дампы каждый раз указывают на разные сторонние драйверы. Как ни странно, тоже похоже на железо. Один кривой драйвер падает стабильно на себе, а вот повреждение памяти роняет случайных прохожих.

Что делать с результатом

Нашли конкретный драйвер? Как ни странно, лучше сначала попробовать его откатить, а не обновить. Специально на такой случай в диспетчере устройств есть кнопка отката, и если проблема появилась после свежего обновления, это самый быстрый путь. Не помогло, сносим начисто и ставим версию с сайта производителя железа, а не ту, что подсунула Windows.

Заподозрили память, гоняем memtest86 хотя бы четыре прохода. Если стоит XMP или EXPO, для теста профиль лучше отключить, потому что половина проблем с памятью решается именно этим.

Увидели WHEA с одного ядра? Снимаем разгон, проверяем температуры, обновляем BIOS. И готовимся к тому, что вопрос может оказаться гарантийным.

Ну а если в дампах системные модули, WHEA молчит, а падения продолжаются, вот тогда и стоит доставать Driver Verifier. Но точку восстановления сделать не забудьте.

Что из всего этого следует

Стоп‑код на экране — это симптом, а не диагноз. Он говорит, что система упала, но молчит о том, кто ее уронил.

Настоящий ответ лежит в минидампе, и достать его оттуда — дело пяти минут. WinDbg, путь к символам, !analyze ‑v, вот и вся премудрость.

Только вот строчке Probably caused by верить нельзя. Половина ее вердиктов указывает на прослойки вроде Wdf01000.sys или на само ядро, а настоящая причина в это время может сидеть где‑нибудь в планке памяти.

Ну а с кодом 0×124 в дамп можно и не заглядывать. Идите сразу в журнал событий, там WHEA‑Logger напишет и тип ошибки, и номер ядра.

А у вас как? Ловили падения, разбирали дампы? Расскажите, что в итоге оказалось виновато — особенно интересны случаи, где WinDbg показывал одно, а на деле было совсем другое.