BSOD на новом Windows 11? Это не вирус и не обновления

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

BSOD на новом Windows 11 / Дзен.Уловка-32

Когда пользователь сталкивается с синим экраном смерти (BSOD) в Windows 11, первая мысль — проблема в программной части. Возможно, какой-то драйвер конфликтует с системой, или обновление установилось некорректно. Однако когда BSOD повторяется даже после полной переустановки Windows, вопрос перестаёт быть риторическим и требует чёткого, технически обоснованного подхода.

В этой статье я последовательно разберу поведение системы, проведу анализ событий из журнала и объясню, какие действия действительно помогут установить причину и устранить сбой. Всё, что вы прочитаете ниже, основано на реальных данных: диагностических логах, отчётах системы и результатах проверок оборудования. Без догадок и абстрактных советов. Только факты. Готовы? Поехали!

Что именно происходит: анализ журналов событий

Рассмотрим конкретную ситуацию. Устройство — ноутбук Asus ROG Strix G16, на котором установлена Windows 11 версии 24H2. Пользователь сталкивается с BSOD, происходящим во время выключения или запуска системы. Это уже даёт нам важный контекст: сбой связан с критическими этапами жизненного цикла ОС — инициализацией и завершением работы.

В журнале событий фиксируются два ключевых события:

• volmgr (Event ID 162) — ошибка управления томами, указывающая на путь \Device\HarddiskVolume3.
• Event ID 6008 — сообщение о неожиданном завершении работы, то есть о сбое.

📌 Важно: ошибка volmgr появляется примерно за 6 секунд до записи о выключении. Это ключевой факт. Он указывает, что причина сбоя — не внешнее воздействие (например, отключение питания), а системная ошибка, связанная с работой накопителя.

Почему переустановка Windows не помогла

На первый взгляд, переустановка Windows должна устранить большинство программных конфликтов. Но здесь мы видим обратное: система «падает» даже на свежей установке. Это значит, что причина либо вне системного диска, либо кроется в аппаратной части.

Однако пользователь провёл диагностику:

• Проверка файловой системы (sfc /scannow и chkdsk) не выявила ошибок.
• Тесты с HD Tune и CrystalDiskInfo показывают, что диск не перегревается и не имеет секторов с переотправкой (reallocated sectors).
• Диагностика оперативной памяти не выявила сбоев.

Формально — всё в порядке. Но BSOD продолжаются. Что это означает?

📌 На практике это типичная ситуация, когда аппаратная проблема носит нестабильный, интермиттирующий характер, то есть проявляется не всегда, а лишь при определённых условиях — высокой нагрузке, определённой температуре, или в момент обращения к конкретному сектору накопителя.

Возможная причина — аппаратный сбой SSD или контроллера питания

Сигналом к системному сбою служит ошибка volmgr. Это системный компонент, который отвечает за управление томами, в том числе монтирование, выгрузку и завершение работы с томами при выключении. Ошибка Event ID 162 — это не просто предупреждение. Это означает, что ОС не смогла корректно записать финальные данные в один из томов, указанный как \Device\HarddiskVolume3.

📌 Важно понимать: Windows присваивает такие обозначения не дискам в буквенном выражении (C:, D:), а логическим томам. Это может быть как основной раздел, так и служебный, например, Recovery или EFI. Ошибка в этом контексте может означать:

1. Сбой в логике работы SSD (фирменная прошивка накопителя);
2. Ошибка в передаче данных на шине (например, нестабильный NVMe-контроллер);
3. Проблемы в подаче питания во время выключения (особенно на ноутбуках с агрессивными энергосберегающими алгоритмами BIOS/UEFI).

На практике такие ошибки часто остаются незамеченными при диагностике, потому что проявляются лишь в динамике. Простой запуск HD Tune не даст нужной нагрузки, а CrystalDiskInfo ориентируется на SMART-показатели, которые не всегда отражают нестабильность в работе флеш-памяти или контроллера.

Как это проявляется в жизни

Вот типичный сценарий:

• Пользователь нажимает «Завершение работы».
• Windows инициирует выгрузку томов и начинает запись финальных данных на диск.
• В момент завершения этой операции SSD не подтверждает запись (по разным причинам: сбой прошивки, плохой контакт, ошибка контроллера).
• Windows не может закрыть лог, но питание уже почти снято.
• Происходит BSOD или «жёсткий» сбой с кодом 6008 на следующей загрузке.

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

Что делать: проверка в глубину

Чтобы выйти из «цикла неопределённости», нужны следующие шаги:

1. Проверить SMART-логи в динамике, а не в статике. Например, утилитой smartmontools, которая может логировать изменения по SMART-атрибутам с течением времени. Особенно важны: Media and Data Integrity Errors | Unsafe Shutdown Count | CRC Error Count
2. Отключить быстрый запуск Windows. Эта функция может вызывать проблемы с выгрузкой томов на некоторых устройствах. Настройки → Электропитание → Действия кнопок питания → Изменить параметры → убрать галочку с «Включить быстрый запуск».
3. Обновить BIOS и прошивку SSD. У Asus на ROG-ноутбуках часто выходят обновления BIOS, устраняющие проблемы с управлением питанием и работой NVMe-контроллера.
4. Проверить накопитель на другом устройстве. Если есть возможность, стоит подключить SSD к другому компьютеру и провести стресс-тест. Если сбой повторится — виноват накопитель.
5. Проанализировать дампы памяти (Minidump). Если Windows создаёт файл с расширением .dmp после BSOD, его можно открыть с помощью утилиты BlueScreenView или WinDbg. Это даст точную информацию о модуле, вызвавшем сбой.

Заключение

Синий экран смерти после переустановки Windows — это не признак того, что «Windows нестабильна», как считают многие. Это сигнал о проблеме, чаще всего аппаратной, которую невозможно решить с помощью обычной переустановки. В данном случае у нас есть чёткие факты: ошибка volmgr перед завершением работы и внезапные сбои. Всё указывает на нестабильность накопителя или контроллера, несмотря на внешнюю «исправность» в диагностических утилитах.

Если вы столкнулись с подобной проблемой, не спешите винить Windows. Лучше копать глубже: в энергопитание, накопители и прошивки. Именно там чаще всего прячется причина, которую не видно при поверхностной проверке.

Если статья помогла вам разобраться в причинах BSOD — поставьте 👍 лайк. Это улучшит рекомендации и подскажет алгоритму, что тема актуальна. А если у вас есть личный опыт борьбы с подобными сбоями — поделитесь им в комментариях.