КиберПротект приводит к INACCESSIBLE_BOOT_DEVICE

В чём суть проблемы

INACCESSIBLE_BOOT_DEVICE, это один из самых неприятных стоп-кодов Windows. Система на старте понимает, что не может достучаться до загрузочного раздела, и валится в синий экран сразу после включения. Чаще всего это прилетает после планового обновления Windows Update и особенно больно бьёт по боевым серверам: простой считается на часы, а причина на первый взгляд не очевидна.

Площадка была такая: продуктивный сервер 1С на платформе Supermicro, SAS3-бэкплейн, системный NVMe-диск, программное зеркало на Storage Spaces, сверху Windows Server 2022. Всё как у людей, и простой такого сервера бьёт сразу по бухгалтерии и всей работе с базой.

Как это выглядело

После обычного планового ребута, вызванного установкой накопительного обновления (Cumulative Update), сервер перестал загружаться. На экране стандартный синий экран с кодом INACCESSIBLE_BOOT_DEVICE, автоматический ребут по кругу, а штатная среда восстановления (WinRE) сама не поднималась. Единственное изменение перед сбоем: плановое обновление Windows. Руками в этот день никто ничего не трогал.

Алгоритм диагностики и восстановления

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

diskpart
list disk
list volume

select volume <номер EFI-раздела>
assign letter=S
exit
bcdboot C:\Windows /s S: /f UEFI

dism /image:W:\ /get-packages

dism /image:W:\ /remove-package /packagename:<точное имя пакета>

chkdsk W: /f /r

reg load HKLM\OFFSYS W:\Windows\System32\config\SYSTEM
reg query HKLM\OFFSYS\ControlSet001\Services\storahci
reg query HKLM\OFFSYS\ControlSet001\Services\stornvme

reg query "HKLM\OFFSYS\ControlSet001\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318}" /v UpperFilters
reg query "HKLM\OFFSYS\ControlSet001\Control\Class\{71a27cdd-812a-11d0-bec7-08002be2092f}" /v UpperFilters

reg add "HKLM\OFFSYS\ControlSet001\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318}" /v UpperFilters /t REG_MULTI_SZ /d "partmgr" /f
reg add "HKLM\OFFSYS\ControlSet001\Control\Class\{71a27cdd-812a-11d0-bec7-08002be2092f}" /v UpperFilters /t REG_MULTI_SZ /d "volsnap" /f
reg unload HKLM\OFFSYS

Почему виноват именно КиберПротект

Если совсем на пальцах, система, это слоёный пирог. Внизу железо, на нём операционная система, между ними драйверы, а сверху проводник, где вы уже открываете свои таблицы и базы. В слой драйверов можно встраивать собственные надстройки, так называемые фильтры. Агент бэкапа как раз ставит такой фильтр поверх драйвера общения с дисками, и именно он после обновления встал поперёк загрузки.

Технически это выглядит так. Агент Кибер Бэкап встраивает свой фильтр-драйвер CBT прямо в цепочку инициализации диска и тома. Делает он это не со зла: так технология отслеживает изменённые блоки и снимает инкрементальные копии быстро, не перечитывая весь том. Пока версия агента совпадает со сборкой ОС, всё работает как надо.

Проблема вылезает после накопительного обновления. Сборка ядра уезжает вперёд, а драйвер остаётся прежним, и в какой-то момент он встаёт поперёк доступа к загрузочному устройству. Это неочевидный слой: мало кто вообще держит в голове, что поверх драйвера дискового массива живут чьи-то надстройки, поэтому шаг с фильтрами так часто и пропускают. Отдельная ирония в том, что речь про лицензионный, платный и вполне отечественный продукт, от которого по умолчанию ждёшь надёжности. Но на уровне ядра любая надстройка, хоть импортная, хоть своя, одинаково способна уронить загрузку после апдейта. И самое обидное, что уронил сервер тот самый инструмент, который призван его страховать.

Ценность точной диагностики здесь именно в сэкономленном времени. Найденный фильтр-драйвер убирается из реестра за минуту, тогда как альтернатива, полная переустановка Windows с нуля и повторная настройка 1С, это ещё несколько часов простоя. Ради этой минуты и стоит доходить до конца, а не сдаваться на середине и нести систему в переустановку.

Как не наступить на эти грабли снова

• Держите агенты резервного копирования и антивирусы в актуальных версиях. Рассинхрон между версией стороннего ПО и сборкой Windows после Cumulative Update, это одна из самых частых причин подобных сбоев.
• Если инцидент случился на одном сервере, проверьте остальные с таким же стеком ПО. Вероятность повторить сценарий на них высокая.
• Разносите во времени обновление Windows и обновление защитного ПО. Так при сбое сразу понятно, кто виноват.
• Обкатывайте критичные обновления на некритичном контуре перед массовым раскатыванием, если инфраструктура это позволяет.

Итог

Если сервер не поднимается после обновления, а стандартные шаги (загрузчик, откат апдейта, chkdsk) результата не дают, копайте на уровень драйверов сторонних приложений. Чаще всего виновник сидит именно там, в цепочке инициализации диска, и молча ломает загрузку ещё до старта системы.