Windows зависает через 5 минут: проверка задачи Secure-Boot-Update

Компьютер включается, работает несколько минут — и намертво зависает: не двигается курсор, не отвечает клавиатура, помогает только кнопка Reset. В журнале событий пусто, в безопасном режиме проблемы нет. Настораживает точность: остановка примерно через пять минут после старта, хоть входи в систему, хоть нет.

Одна из возможных и быстро проверяемых причин такого симптома — фоновая задача обновления сертификатов Secure Boot. Ниже — как проверить это за минуту и отличить норму от поломки.

Что за задача #

Windows меняет сертификаты Secure Boot 2011 года на версии 2023 года: KEK CA 2011 истёк 24 июня 2026, UEFI CA 2011 — 27 июня 2026, Windows Production PCA 2011 истекает 19 октября 2026. Ставит их штатная задача Secure-Boot-Update.

Путь: \Microsoft\Windows\PI\Secure-Boot-Update. Запуск — от имени SYSTEM, при старте системы и далее каждые 12 часов. Каждый запуск смотрит реестр HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates и по порядку выполняет действия, отмеченные битами: 0x0040 → 0x0800 → 0x1000 → 0x0004 → 0x0100. Старт обычно 0x5944, финиш 0x4000 (бит-модификатор, не ошибка). Неудачный шаг не двигается дальше: пишет событие и ждёт следующего запуска. Детали механизма — в руководстве Microsoft KB5085046.

Обычно это незаметно. Но если прошивка не умеет принять ключи (старый UEFI, нет OEM-подписанного KEK, установка в обход требований), система может зависать в момент отработки задачи. Характерный пример из жалоб: свежая Windows 11 зависает примерно через пять минут после старта — хоть со входом в систему, хоть без, — в журнале пусто, в безопасном режиме чисто. У части таких ПК ручной запуск задачи воспроизводит зависание, а её отключение его снимает (наблюдения пользователей). Оговорка: Microsoft официально не называла зависание известной проблемой этой задачи — поэтому ниже только проверка.

Кого касается #

ПК на Windows 10/11 с включённым Secure Boot, поддерживаемая версия + свежие накопительные обновления (это обязательные условия из руководства Microsoft). В группе риска по тому же руководству: прошивка, не умеющая принимать ключи, отсутствие OEM-подписанного KEK. Про установку в обход проверок: в жалобах встречались машины с установкой в обход требований — учитывайте это как отягчающий фактор, в документации Microsoft такого сценария нет. Если Secure Boot отключён в BIOS — задача не при чём, ищите в другом месте.

Проверка за минуту #

Откройте PowerShell от администратора и выполните:

schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V

Смотрите поле «Состояние» (Status): «Готово» (Ready) — задача на месте и включена; «Отключено» (Disabled) — отключена; ошибка / Not Found — удалена. По руководству Microsoft задача должна быть включена — иначе обслуживание сертификатов встаёт.

Дальше — Планировщик: нажмите Win+R, введите taskschd.msc, Enter. Слева: Библиотека планировщика → Microsoft → Windows → PI. В центре кликните Secure-Boot-Update. Внизу откройте вкладку «Триггеры»: по документации Microsoft там запуск при старте системы и повтор примерно каждые 12 часов — сверьте, что у вас. Для ориентира: в эталонном определении задачи (XML внутри образца Microsoft ниже) это триггер при загрузке с задержкой 5 минут (PT5M) и повтором каждые 12 часов (PT12H) — отсюда и берутся «пять минут» из жалоб. Если на вашей машине в триггерах этого нет, значит, задача отличается от эталонной (изменена или другой версии) — это само по себе диагностический сигнал. Точнее всего смотрят не триггеры, а факт запуска: вкладка «Журнал» (или поле времени последнего запуска) — совпало ли время запуска задачи со временем зависания минута в минуту. Плюс в журнале Windows перед зависанием не должно быть ошибок драйверов и диска. Путь и команда одинаковы для Windows 10 и 11.

Третья точка — реестр AvailableUpdates и события. Оставшийся бит + события 1032/1795/1796/1802 обычно означают ограничение прошивки; 1803 — нет OEM KEK. Об успехе говорят события 1036/1044/1045/1043/1799. Связку «реестр + журнал» Microsoft называет главным способом понять: идёт работа, повторная попытка или остановка. Про то, как платформа проверяет UEFI, Secure Boot и драйверы перед включением защиты, — в материале про целостность памяти HVCI.

Что делать #

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

Временно снять симптом иногда помогает отключение задачи в Планировщике — так описывают свой опыт часть пользователей. Но это костыль: без задачи новые сертификаты не будут установлены, а к 19 октября 2026 будет установлена замена загрузчика (бит 0x0100, событие 1799). Microsoft прямо требует держать задачу включённой и даёт образец скрипта Enable-SecureBootUpdateTask.ps1 для восстановления (образец — без поддержки Microsoft; с обновлений от 12 мая 2026 года он также лежит на самом компьютере в папке %systemroot%\SecureBoot\ExampleRolloutScripts). Поэтому после отключения зафиксируйте AvailableUpdates, события и версию UEFI — и вернитесь к прошивке, а не живите с выключенной задачей.

Задача, скорее всего, ни при чём, если: зависание в случайные моменты без привязки к старту, зависание до экрана блокировки, BSOD с указанием видеодрайвера, гаснущий экран с треском — проверяйте драйверы, диск и перегрев, а не сертификаты.

Ограничения #

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

FAQ #

Зависает примерно через 5 минут после старта — это точно Secure Boot? Сильный признак, но требует проверки. Подтверждается связкой: время зависания совпадает с запуском задачи (смотреть в «Журнале» задачи) + состояние «Готово» (Ready) + оставшиеся биты + пустой журнал драйверов. Без этой связки — лишь гипотеза.

Почему в безопасном режиме всё хорошо? Ни о чём конкретном: в безопасном режиме симптом уходит как при проблемах с драйверами, так и при проблемах с задачей — так было у автора исходной жалобы. Сам по себе чистый безопасный режим причину не называет, он лишь отсекает часть вариантов. Различают их дальше: совпадение запуска задачи со временем зависания и события в журнале.

Можно ли просто удалить задачу? Нет. Microsoft требует включённого состояния; удаление останавливает обновление баз и ключей (DB/KEK) и будущего загрузчика. Только временно для диагностики, потом восстановить скриптом Microsoft (ссылка выше) и чинить прошивку.

Что будет, если отключить задачу навсегда? ПК продолжит грузиться, обычные обновления встанут (так описывает Microsoft поведение без новых сертификатов). Но система останется без защиты на раннем этапе загрузки.

Вывод #

Зависание с точностью часов обычно указывает на расписание, а не на железо. Проверьте одну задачу: schtasks, папка PI, AvailableUpdates. Подтвердилось — обновляйте UEFI и держите задачу включённой. Не подтвердилось — не трогайте сертификаты и ищите в драйверах и железе.