Посібник із виправлення неполадок із безпечним завантаженням
Застосовується до
Вихідна дата публікації: 19 березня 2026 р.
Ідентифікатор KB: 5085046
У цій статті
Огляд
На цій сторінці наведено вказівки для адміністраторів і спеціалістів із підтримки в діагностиці та вирішенні проблем із безпечним завантаженням на пристроях Windows. До розділів належать помилки оновлення сертифіката безпечного завантаження, неправильні стани безпечного завантаження, неочікувані запити на відновлення BitLocker та помилки завантаження після змін конфігурації безпечного завантаження.
У посібнику пояснюється, як перевірити обслуговування та конфігурацію Windows, переглянути відповідні значення реєстру та журнали подій, а також визначити, коли обмеження мікропрограми або платформи вимагають оновлення OEM. Цей вміст призначено для діагностування проблем на наявних пристроях. Вона не призначена для планування нових розгортань. Цей документ буде оновлено в міру визначення нових сценаріїв виправлення неполадок і вказівок.
Як працює обслуговування сертифіката безпечного завантаження
Обслуговування сертифіката безпечного завантаження у Windows – це узгоджений процес між операційною системою та мікропрограмою UEFI пристрою. Мета полягає в оновленні критичних якорів довіри зі збереженням можливості завантаження на кожному етапі.
Процес керується запланованим завданням Windows, послідовністю оновлень на основі реєстру, а також вбудованим журналюванням і повторною поведінкою. Разом ці компоненти забезпечують оновлення сертифікатів безпечного завантаження та диспетчера завантаження Windows контрольованим, впорядкованим способом і лише після успішного виконання обов'язкових кроків.
Де почати під час виправлення неполадок
Якщо здається, що пристрій не виконує очікуваний процес застосування оновлень сертифіката безпечного завантаження, почніть із визначення категорії проблеми. Більшість проблем належать до однієї з чотирьох областей: стан обслуговування Windows, механізм оновлення безпечного завантаження, поведінка мікропрограми або обмеження платформи чи виробника оригінального обладнання.
Почніть із наведених нижче перевірок. У багатьох випадках цих кроків достатньо, щоб пояснити спостережувану поведінку та визначити наступні дії без глибшого дослідження.
-
Підтвердьте відповідність вимогам до обслуговування та платформи Windows
-
Переконайтеся, що пристрій відповідає основним вимогам для отримання оновлень сертифіката безпечного завантаження:
-
На пристрої інстальовано підтримувану версію Windows.
-
Інстальовано останні необхідні оновлення системи безпеки Windows.
-
Безпечне завантаження ввімкнуто в мікропрограмі UEFI.
-
Якщо будь-яка з цих умов не виконується, вирішіть їх, перш ніж продовжити подальше виправлення неполадок.
-
-
Перевірка стану завдання secure-Boot-Update
-
Переконайтеся, що механізм Windows, відповідальний за застосування оновлень сертифіката безпечного завантаження, присутній і працює:
-
Заплановане завдання secure-Boot-Update існує.
-
Завдання увімкнуто та виконується як локальна система.
-
Завдання виконується принаймні один раз після інсталяції останнього оновлення системи безпеки Windows.
-
Якщо завдання вимкнуто, видалено або не запущено, не можна застосувати оновлення сертифіката безпечного завантаження. Перш ніж досліджувати інші причини, виправлення неполадок слід зосередитися на відновленні завдання.
-
-
Перевірка параметрів реєстру на наявність очікуваного перебігу виконання
Перегляньте стан обслуговування безпечного завантаження пристрою в реєстрі:
-
Перевірте UEFICA2023Status, UEFICA2023Error і UEFICA2023ErrorEvent.
-
Перевірте AvailableUpdates і порівняйте його з очікуваним перебігом виконання (див. розділ Довідник і внутрішні дані).
Разом ці значення вказують на те, чи виконується обслуговування у звичайному режимі, повторна операція або зупинка на певному кроці.
-
-
Узгодження стану реєстру з подіями безпечного завантаження
Перегляньте події безпечного завантаження, пов'язані з системним журналом подій, і зв'язуйте їх зі станом реєстру. Дані події зазвичай підтверджують, чи виконується перебіг виконання пристрою, повторна спроба через тимчасову умову або заблокована мікропрограмою чи платформою.
Разом журнали реєстру та подій зазвичай вказують на те, чи є поведінка очікуваною, тимчасовою або вимагає коригувальних дій.
Заплановане завдання secure-Boot-Update
Обслуговування сертифіката безпечного завантаження здійснюється через заплановане завдання Windows під назвою Secure-Boot-Update. Завдання зареєстровано за таким шляхом:
\Microsoft\Windows\PI\Secure-Boot-Update
Завдання виконується як локальна система. За замовчуванням вона запускається під час запуску системи та кожні 12 годин після цього. Під час кожного запуску вона перевіряє, чи очікуються дії оновлення безпечного завантаження, і намагається застосувати їх послідовно.
Якщо це завдання вимкнуто або відсутнє, не можна застосувати оновлення сертифіката безпечного завантаження. Щоб обслуговування безпечного завантаження функціонуватиме, завдання secure-Boot-Update має залишатися ввімкненим.
Причини використання запланованого завдання
Оновлення сертифіката безпечного завантаження вимагають координації між мікропрограмою Windows і UEFI, зокрема написання змінних UEFI, у яких зберігаються ключі безпечного завантаження та сертифікати. Заплановане завдання дає змогу Windows спробувати ці оновлення, коли система перебуває в стані, у якому можна змінювати змінні мікропрограми.
Повторюваний 12-годинний розклад надає додаткові можливості повторити оновлення, якщо сталася помилка попередньої спроби, або якщо пристрій залишався ввімкнутим без перезавантаження. Ця конструкція допомагає забезпечити прогрес уперед, не вимагаючи ручного втручання.
Бітова маска реєстру AvailableUpdates
Завдання Secure-Boot-Update керується значенням реєстру AvailableUpdates . Це значення – 32-розрядна бітова маска, розташована за адресою:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Кожен біт у значенні відповідає певній дії оновлення безпечного завантаження. Процес оновлення починається, коли для availableUpdates установлюється ненульове значення ( автоматично Windows або явно адміністратором). Наприклад, значення, наприклад 0x5944 , вказує на те, що очікується кілька дій з оновлення.
Коли завдання Secure-Boot-Update виконується, він інтерпретує набір бітів як відкладену роботу та обробляє їх у визначеному порядку.
Послідовні оновлення, журналювання та поведінка повторного виконання
Оновлення сертифіката безпечного завантаження застосовуються в фіксованому порядку. Кожна дія оновлення безпечна для повторної спроби та виконання незалежної дії. Завдання Secure-Boot-Update не переходить до наступного кроку, доки поточна дія не завершиться успішно, а відповідний розряд буде видалено з AvailableUpdates.
У кожній операції використовуються стандартні інтерфейси UEFI для оновлення змінних безпечного завантаження, як-от DB і KEK, або для інсталяції оновленого диспетчера завантаження Windows. Windows записує результати кожного кроку в журналі системних подій. Події успіху підтверджують перебіг виконання, тоді як події помилки вказують на те, чому не вдалося завершити дію.
Якщо не вдається виконати крок оновлення, завдання припинить обробку, реєструє помилку та залишає пов'язаний набір бітів. Повторна операція виконується під час наступного виконання завдання. Ця поведінка відплати дає змогу пристроям автоматично відновлюватися після тимчасових умов, наприклад відсутність підтримки мікропрограм або відкладені оновлення OEM.
Адміністратори можуть відстежувати перебіг виконання, зв'ядаючи стан реєстру з записами журналу подій. Значення реєстру, як-от UEFICA2023Status, UEFICA2023Error і UEFICA2023ErrorEvent разом із бітовим маскою AvailableUpdates , вказують, який крок активний, завершений або заблокований.
Ця комбінація показує, чи виконується процес роботи пристрою у звичайному режимі, чи виконується повторна операція, чи зупинено.
Інтеграція з мікропрограмою OEM
Оновлення сертифіката безпечного завантаження залежать від правильної поведінки та підтримки в мікропрограмі UEFI пристрою. Хоча Windows організовує процес оновлення, мікропрограма відповідає за забезпечення політики безпечного завантаження та підтримки баз даних безпечного завантаження.
Виробники оригінального обладнання надають два критичні елементи, які забезпечують обслуговування сертифіката безпечного завантаження:
-
Ключ платформи– підписаний ключ Exchange ключі (KEKs), які уповноважує інсталяцію нових сертифікатів безпечного завантаження.
-
Упровадження мікропрограм, які правильно зберігають, додаємо та перевіряє бази даних безпечного завантаження під час оновлення.
Якщо мікропрограма не повністю підтримує такі дії, оновлення безпечного завантаження можуть зависати, повторити спробу на невизначений термін або призвести до помилок завантаження. У таких випадках Windows не може завершити оновлення без змін мікропрограми.
Корпорація Майкрософт працює з виробниками оригінального обладнання для виявлення проблем із мікропрограмою та забезпечення доступності виправлених оновлень. Якщо виправлення неполадок вказує на обмеження мікропрограми або дефект, можливо, адміністраторам знадобиться інсталювати останнє оновлення мікропрограми UEFI, надане виробником пристрою, щоб успішно завершити оновлення сертифіката безпечного завантаження.
Типові сценарії помилок і способи їх вирішення
Оновлення безпечного завантаження застосовуються запланованим завданням Secure-Boot-Update на основі стану реєстру AvailableUpdates .
За звичайних умов ці кроки відбуваються автоматично та записують події успіху після завершення кожного етапу. У деяких випадках поведінка мікропрограми, конфігурація платформи або попередні вимоги до обслуговування можуть запобігти перебігу виконання або призвести до неочікуваної поведінки завантаження.
У наведених нижче розділах описано найпоширеніші сценарії помилок, способи їх розпізнавання, причини їх виникнення та відповідні наступні кроки для відновлення нормальної роботи. Сценарії впорядковано від найпоширеніших до серйозних випадків завантаження.
Коли оновлення безпечного завантаження не показують перебігу виконання, зазвичай це означає, що процес оновлення ніколи не починалося. Як наслідок, відсутні очікувані значення реєстру безпечного завантаження та журнали подій, оскільки механізм оновлення ніколи не запускався.
Що сталося
Процес оновлення безпечного завантаження не почався, тому до пристрою не застосовано жодного сертифіката безпечного завантаження або оновленого диспетчера завантаження.
Як розпізнати його
-
Немає значень реєстру обслуговування безпечного завантаження, наприклад UEFICA2023Status.
-
У системному журналі подій відсутні очікувані події безпечного завантаження (наприклад, 1043, 1044, 1045, 1799, 1801).
-
Пристрій продовжує використовувати старі сертифікати безпечного завантаження та компоненти завантаження.
Чому це відбувається
Цей сценарій зазвичай виникає, коли виконується одна або кілька з наведених нижче умов.
-
Заплановане завдання secure-Boot-Update вимкнуто або відсутнє.
-
Безпечне завантаження вимкнуто в мікропрограмі UEFI.
-
Пристрій не відповідає вимогам до обслуговування Windows, таким як запуск підтримуваної версії Windows або наявність необхідних оновлень.
Подальші дії
-
Переконайтеся, що пристрій відповідає вимогам до обслуговування та платформи Windows.
-
Переконайтеся, що безпечне завантаження ввімкнуто в мікропрограмі.
-
Переконайтеся, що заплановане завдання SecureBootUpdate існує та ввімкнуто.
Якщо заплановане завдання вимкнуто або відсутнє, дотримуйтеся вказівок у розділі Заплановане безпечне завантаження, щоб відновити його. Після відновлення завдання перезавантажте пристрій або вручну запустіть завдання, щоб запустити обслуговування безпечного завантаження.
У деяких випадках оновлення, пов'язані з безпечним завантаженням, можуть призвести до введення пристрою відновлення BitLocker. Залежно від основної причини поведінка може бути тимчасовою або стійкою.
Сценарій 1. Одноразове відновлення BitLocker після оновлення безпечного завантаження
Що відбувається
Пристрій входить у bitLocker відновлення під час першого завантаження після оновлення безпечного завантаження, але зазвичай завантажується під час подальших перезавантажень.
Чому це відбувається
Під час першого завантаження після оновлення мікропрограма ще не повідомляє про оновлені значення безпечного завантаження, коли Windows намагається відновити BitLocker. Це призводить до тимчасової невідповідності у вимірюваних значеннях завантаження та викликає відновлення. Під час наступного завантаження мікропрограма правильно повідомляє про оновлені значення, BitLocker успішно заново завантажує їх, і проблема не повторюється.
Як розпізнати його
-
Відновлення BitLocker відбувається один раз.
-
Після введення ключа відновлення наступні чоботи не підкажуть відновлення.
-
Немає поточного порядку завантаження або залучення PXE.
Подальші дії
-
Щоб відновити Windows, введіть ключ відновлення BitLocker.
-
Перевірте наявність оновлень мікропрограм.
Сценарій 2. Повторне відновлення BitLocker через конфігурацію першого завантаження PXE
Що відбувається
Пристрій входить у bitLocker відновлення під час кожного завантаження.
Чому це відбувається
Пристрій настроєно на першу спробу завантаження PXE (мережі). Не вдається виконати спробу завантаження PXE, а мікропрограма повертається до диспетчера завантаження Windows на диску.
Це призводить до двох різних посилань підпису вимірюється протягом одного циклу завантаження:
-
Шлях завантаження PXE підписано Microsoft UEFI CA 2011.
-
Диспетчер завантаження Windows на диску підписаний Windows UEFI CA 2023.
Оскільки BitLocker спостерігає різні ланцюги довіри безпечного завантаження під час запуску, він не може встановити стабільний набір вимірювань TPM для відновлення. Як наслідок, BitLocker вводить відновлення під час кожного завантаження.
Як розпізнати його
-
Відновлення BitLocker активується під час кожного перезавантаження.
-
Введення ключа відновлення дає змогу запустити Windows, але запит повернеться під час наступного завантаження.
-
PXE або мережеве завантаження налаштовано попереду локального диска в порядку завантаження мікропрограми.
Подальші дії
-
Настройте порядок завантаження мікропрограми, тому спочатку використовується диспетчер завантаження Windows на диску.
-
Вимкніть завантаження PXE, якщо це не потрібно.
-
Якщо PXE обов'язковий, переконайтеся, що інфраструктура PXE використовує завантажувач Windows із підписом 2023.
Що сталося
Це відображає зміну на рівні мікропрограми, а не проблему Windows. Оновлення безпечного завантаження успішно завершено, але після пізнішого перезавантаження пристрій більше не завантажується у Windows.
Як розпізнати його
-
Пристрій не запускає Windows і може відображати мікропрограму або повідомлення BIOS, яке вказує на порушення безпечного завантаження.
-
Помилка виникає після скидання настройок безпечного завантаження до настройок мікропрограм за замовчуванням.
-
Вимкнення безпечного завантаження може дозволити пристрою знову завантажитися.
Чому це відбувається
Скидання безпечного завантаження до за замовчуванням мікропрограми очищує бази даних безпечного завантаження, що зберігаються в мікропрограмі. На пристроях, які вже перейшли до диспетчера завантаження Windows UEFI CA 2023, буде видалено сертифікати, необхідні для довіри цьому диспетчеру завантаження.
Як наслідок, мікропрограма більше не розпізнає інстальований диспетчер завантаження Windows як надійний і блокує процес завантаження.
Цей сценарій викликано не самим оновленням безпечного завантаження, а подальшою дією мікропрограми, яка видаляє оновлені прив'язки довіри.
Подальші дії
-
Скористайтеся програмою відновлення безпечного завантаження, щоб відновити потрібний сертифікат, щоб пристрій міг завантажитися знову.
-
Після відновлення переконайтеся, що на пристрої інстальовано останню версію доступної мікропрограми від виробника пристрою.
-
Уникайте скидання безпечного завантаження до настройок мікропрограм за замовчуванням, якщо мікропрограма OEM не містить оновлені стандартні параметри безпечного завантаження, які довіряють сертифікатам 2023.
Утиліта відновлення безпечного завантаження
Щоб відновити систему, виконайте наведені нижче дії.
-
На другому ПК з Windows, на якому інстальовано оновлення Windows за липень 2024 р. або новішої версії, скопіюйте SecureBootRecovery.efi з C:\Windows\Boot\EFI\.
-
Помістіть файл на USB-носій у форматі FAT32 в розділі \EFI\BOOT\ і перейменуйте його на bootx64.efi.
-
Завантажте пристрій, на який впливає проблема, з USB-носія та дозвольте запуск програми відновлення. Утиліта додасть Windows UEFI CA 2023 до бази даних.
Після відновлення сертифіката та перезавантаження системи Windows має запуститися у звичайному режимі.
Важливо: Цей процес повторно застосує лише один із нових сертифікатів. Після відновлення пристрою переконайтеся, що він повторно застосується до найновіших сертифікатів, і спробуйте оновити BIOS/UEFI системи до найновішої доступної версії. Це може допомогти запобігти повторенню проблеми скидання безпечного завантаження, оскільки багато виробників оригінального обладнання випустили виправлення мікропрограм для цієї проблеми.
Що сталося
Після застосування оновлення сертифіката безпечного завантаження та перезавантаження пристрою не вдається завантажити пристрій і він не досягне Windows.
Як розпізнати його
-
Пристрій не вдається виконати відразу після перезавантаження, потрібного для оновлення безпечного завантаження.
-
Може з'явитися помилка мікропрограми або безпечного завантаження або система може зупинитися перед завантаженням Windows.
-
Вимкнення безпечного завантаження може дозволити завантаження пристрою.
Чому це відбувається
Ця проблема може виникати через дефект у реалізації мікропрограми UEFI пристрою.
Коли Windows застосовує оновлення сертифіката безпечного завантаження, мікропрограма, як очікується, додає нові сертифікати до наявної бази даних підписів із дозволами безпечного завантаження (DB). Деякі впровадження мікропрограм неправильно перезаписують базу даних, а не додаються до неї.
У такому разі
-
Раніше надійні сертифікати, зокрема сертифікат завантажувача Microsoft 2011, видаляються.
-
Якщо система все ще використовує диспетчер завантаження, підписаний за допомогою сертифіката 2011 на той момент, мікропрограма більше не довіряє.
-
Мікропрограма відхиляє диспетчер завантаження та блокує процес завантаження.
У деяких випадках база даних також може пошкодитися, а не чисто перезаписувати, що призводить до того ж результату. Така поведінка спостерігається на певних прошивках і не очікується на сумісні мікропрограми.
Подальші дії
-
Введіть меню налаштування мікропрограми та спробуйте скинути настройки безпечного завантаження.
-
Якщо пристрій завантажується після скидання, перевірте на сайті підтримки виробника пристрою оновлення мікропрограми, яке виправляє обробку бази даних безпечного завантаження.
-
Якщо доступне оновлення мікропрограми, інсталюйте його перед повторним ввімкненням безпечного завантаження та повторним застосуванням оновлень сертифіката безпечного завантаження.
Якщо скидання безпечного завантаження не відновило функції завантаження, імовірно, для подальшого відновлення потрібні вказівки щодо певного виробника оригінального обладнання.
Що сталося
Оновлення сертифіката безпечного завантаження не завершено, воно залишається заблокованим на етапі оновлення ключа exchange (KEK).
Як розпізнати його
-
Значення реєстру AvailableUpdates залишається встановленим із бітом KEK (0x0004) і не очищається.
-
UEFICA2023Status не виконується до завершеного стану.
-
Журнал системних подій кілька разів записує ідентифікатор події 1803, що вказує на те, що не вдалося застосувати оновлення KEK.
-
Пристрій продовжує повторну спробу оновлення без перебігу виконання.
Чому це відбувається
Для оновлення KEK безпечного завантаження потрібна авторизація з ключа платформи (PK) пристрою, який належить виробнику оригінального обладнання.
Для успішного оновлення виробник пристрою повинен надати корпорації Майкрософт KEK із підписом PK для цієї конкретної платформи. Цей KEK із підписом OEM входить до складу оновлень Windows і дозволяє Windows оновлювати змінну KEK мікропрограми.
Якщо виробник оригінального обладнання не надав кек із підписом PK для пристрою, Windows не зможе завершити оновлення KEK. У цьому стані:
-
Оновлення безпечного завантаження заблоковано за допомогою конструктора.
-
Системі Windows не вдалося обійти відсутню авторизацію.
-
Пристрій може залишатися остаточно не в змозі завершити обслуговування сертифіката безпечного завантаження.
Це може статися на старіших або непід технічних пристроях, де виробник оригінального обладнання більше не надає оновлення мікропрограм або ключів. Для цієї умови немає підтримуваного шляху відновлення вручну.
Якщо не вдалося застосувати оновлення сертифіката безпечного завантаження, windows записує діагностичні події, які пояснюють, чому перебіг виконання заблоковано. Ці події записуються під час оновлення бази даних сигнатур безпечного завантаження (DB) або ключа обміну ключем (KEK) неможливо безпечно завершити через мікропрограму, стан платформи або конфігурацію. Сценарії в цьому розділі посилаються на ці події, щоб визначити типові моделі помилок і визначити відповідне виправлення. Цей розділ призначений для підтримки діагностики та інтерпретації проблем, описаних раніше, а не для впровадження нових сценаріїв помилок.
Повний список ідентифікаторів подій, описів і прикладів записів див. в статті Події оновлення змінних DB та DBX (KB5016061)).
Помилка оновлення KEK (оновлення бази даних виконано успішно, KEK не виконується)
Пристрій може успішно оновити сертифікати в бази даних безпечного завантаження, але не вдається під час оновлення KEK. У такому разі не вдалося завершити процес оновлення безпечного завантаження.
Ознаки
-
Події сертифіката бази даних вказують на перебіг виконання, але стадія KEK не завершена.
-
Для availableUpdates залишається встановлено значення 0x4004, а 0x0004 біт не очищається після виконання кількох завдань.
-
Подія 1795 або 1803 може бути присутня.
Інтерпретації
-
1795 зазвичай вказує на відмову мікропрограми під час спроби оновити змінну безпечного завантаження.
-
1803 вказує на те, що оновлення KEK не можна авториувати, оскільки потрібне навантаження KEK із підписом OEM недоступне для платформи.
Наступні кроки
-
Для 1795 перевірте наявність оновлень мікропрограм виробника оригінального обладнання та перевірте підтримку мікропрограм для оновлень змінних безпечного завантаження.
-
Для 1803 переконайтеся, що виробник оригінального обладнання надав корпорації Майкрософт КЕК із підписом PK, необхідний для моделі пристрою.
Помилка оновлення KEK у гостьових віртуальних машинах, розміщених на Hyper-V
На віртуальних машинах Hyper-V оновлення сертифіката безпечного завантаження потребують інсталяції оновлень Windows за березень 2026 року як на хості Hyper-V, так і на гостьовій ОС.
Помилки оновлення повідомляються з гостьового облікового запису, але подія вказує, де потрібно виправити оновлення:
-
Подія 1795 (наприклад, "Медіадані захищено від записування") указує на те, що хост Hyper-V відсутній в оновленні за березень 2026 року, і його потрібно оновити.
-
Подія 1803 , про який повідомляє гість , вказує на те, що гостьова віртуальна машина відсутня в оновленні за березень 2026 року, і її потрібно оновити.
Довідкові та внутрішні системи
Цей розділ містить додаткові довідкові відомості, призначені для виправлення неполадок і підтримки. Вона не призначена для планування розгортання. Він розширюється на механіку обслуговування безпечного завантаження, зведену раніше, і надає докладні довідкові матеріали для інтерпретації стану реєстру та журналів подій.
Примітка (ІТ-керовані розгортання): Якщо настроєно за допомогою Групова політика або Microsoft Intune, не слід плутати два схожі параметри. Значення AvailableUpdatesPolicy позначає стан налаштованої політики. Тим часом AvailableUpdates відображає стан роботи, що виконується, і виконується. Обидва можуть керувати однаковим результатом, але вони поводяться по-іншому, тому що політика з часом знову застосовується.
AvailableUpdates bits used for certificate servicing
Наведені нижче біти використовуються для дій диспетчера сертифікатів і завантаження, описаних у цьому документі. У стовпці Order (Порядок ) відображається послідовність, у якій завдання Secure-Boot-Update обробляє кожен біт.
|
Замовлення |
Bit setting |
Використання |
|---|---|---|
|
1 |
0x0040 |
Цей біт повідомляє заплановане завдання, щоб додати сертифікат Windows UEFI CA 2023 до бази даних безпечного завантаження. Це дає змогу Ос Windows довіряти диспетчерам завантаження, підписаним цим сертифікатом. |
|
2 |
0x0800 |
Цей біт повідомляє заплановане завдання, щоб застосувати Microsoft Option ROM UEFI CA 2023 до бази даних. Умовна поведінка. Якщо встановити позначку 0x4000 , заплановане завдання спочатку перевірить базу даних сертифіката UEFI CA 2011 корпорації Майкрософт . Він застосовуватиметься до сертифіката Microsoft Option ROM UEFI CA 2023, лише якщо є сертифікат 2011. |
|
3 |
0x1000 |
Цей біт повідомляє заплановане завдання, щоб застосувати Microsoft UEFI CA 2023 до бази даних. Умовна поведінка. Якщо встановлено позначку 0x4000 , заплановане завдання спочатку перевірить базу даних сертифіката UEFI CA 2011 корпорації Майкрософт . Він застосовуватиметься до сертифіката Microsoft UEFI CA 2023, лише якщо наявний сертифікат 2011 року. |
|
Модифікатор (позначка поведінки) |
0x4000 |
Цей біт змінює поведінку 0x0800 та 0x1000 бітів таким чином, що Microsoft UEFI CA 2023 і Microsoft Option ROM UEFI CA 2023 застосовуються, лише якщо база даних вже містить UEFI корпорації Майкрософт CA 2011. Щоб переконатися, що профіль безпеки пристрою залишається незмінним, цей біт застосовує ці нові сертифікати, лише якщо пристрій довіряє сертифікату Microsoft Corporation UEFI CA 2011. Не всі пристрої Windows довіряють цьому сертифікату. |
|
4 |
0x0004 |
У цьому біті заплановане завдання вказує на пошук ключа Exchange, підписаного ключем платформи (PK) пристрою. Керування ПК здійснюється виробником оригінального обладнання. Виробники оригінального обладнання підписують кек Microsoft за допомогою свого ПК та доставляють його до корпорації Майкрософт, де він входить до щомісячного сукупного пакета оновлень. |
|
5 |
0x0100 |
Цей біт повідомляє заплановане завдання, щоб застосувати диспетчер завантаження, підписаний Windows UEFI CA 2023, до розділу завантаження. Це замінить підписаний диспетчер завантаження PCA 2011 Microsoft Windows Production 2011. |
Примітки.
-
0x4000 біт залишиться встановленим після обробки всіх інших бітів.
-
Кожен біт обробляється запланованим завданням Secure-Boot-Update в порядку, указаному вище.
-
Якщо не вдалося обробити 0x0004-розрядну версію через відсутність підписаного пакета ПК KEK, заплановане завдання й надалі застосовуватиме оновлення диспетчера завантаження, позначене бітовою 0x0100.
Очікуваний перебіг виконання (AvailableUpdates)
Після успішного завершення операції Windows видаляє пов'язаний біт із availableUpdates. Якщо операцію не вдасться виконати, Windows реєструє подію та повторно виконує завдання.
У таблиці нижче показано очікуваний перебіг виконання значень AvailableUpdates під час виконання кожної дії оновлення безпечного завантаження.
|
Крок |
Біт оброблено |
Доступні Оновлення |
Опис |
Подію успішно записано |
Можливі коди подій помилок |
|---|---|---|---|---|---|
|
Пуск |
0x5944 |
Початковий стан перед початком обслуговування сертифіката безпечного завантаження. |
- |
- |
|
|
1 |
0x0040 |
0x5944 → 0x5904 |
Windows UEFI CA 2023 додано до бази даних безпечного завантаження. |
1036 |
1032, 1795, 1796, 1802 |
|
2 |
0x0800 |
0x5904 → 0x5104 |
Додайте Microsoft Option ROM UEFI CA 2023 до бази даних, якщо пристрій раніше довіряв Microsoft UEFI CA 2011. |
1044 |
1032, 1795, 1796, 1802 |
|
3 |
0x1000 |
0x5104 → 0x4104 |
Microsoft UEFI CA 2023 додається до бази даних, якщо пристрій раніше довіряв Microsoft UEFI CA 2011. |
1045 |
1032, 1795, 1796, 1802 |
|
4 |
0x0004 |
0x4104 → 0x4100 |
Застосовується новий microsoft KEK 2K CA 2023, підписаний ключем платформи OEM. |
1043 |
1032, 1795, 1796, 1802, 1803 |
|
5 |
0x0100 |
0x4100 → 0x4000 |
Інстальовано диспетчер завантаження, підписаний Windows UEFI CA 2023. |
1799 |
1797 |
Примітки
-
Після успішного завершення операції, пов'язаної з нею, цей біт видаляється з AvailableUpdates.
-
Якщо одна з цих операцій завершується помилкою, реєструється подія, і операцію буде повторено під час наступного запуску запланованого завдання.
-
0x4000 біт є модифікатором і не очищається. Остаточне значення AvailableUpdates 0x4000 вказує на успішне виконання всіх відповідних дій з оновлення.
-
Події 1032, 1795, 1796, 1802 зазвичай вказують на обмеження мікропрограми або платформи.
-
Подія 1803 указує на відсутність КЕК із підписом OEM PK.
Процедури виправлення
У цьому розділі наведено покрокове вирішення конкретних проблем із безпечним завантаженням. Кожна процедура відповідає правильно визначеній умові та призначена для виконання лише після того, як початковий діагноз підтвердить, що проблема застосовується. Скористайтеся цими процедурами, щоб відновити очікувану поведінку безпечного завантаження та забезпечити безпечне оновлення сертифіката. Не застосовуйте ці процедури широко або превентивно.
Увімкнення безпечного завантаження в мікропрограмі
Якщо безпечне завантаження вимкнуто в мікропрограмі пристрою, див. Windows 11 та безпечне завантаження, щоб дізнатися, як увімкнути безпечне завантаження.
Заплановане безпечне завантаження завдання вимкнуто або видалено
Для застосування оновлень сертифіката безпечного завантаження Windows потрібне заплановане завдання secure-Boot-Update . Якщо завдання вимкнуто або відсутнє, обслуговування сертифіката безпечного завантаження не перебігне.
Відомості про завдання
|
Ім'я завдання |
Secure-Boot-Update |
|
Шлях до завдання |
\Microsoft\Windows\PI\ |
|
Повний шлях |
\Microsoft\Windows\PI\Secure-Boot-Update |
|
Запускається як |
SYSTEM (локальна система) |
|
Triggers (Тригери) |
Під час запуску та кожні 12 годин |
|
Обов'язковий стан |
Включений |
Перевірка стану завдання
Запуск із командного рядка PowerShell у режимі адміністратора: schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Знайдіть поле Стан:
|
Стан |
Значення |
|---|---|
|
готові |
Завдання існує й увімкнуто. |
|
Вимкнуті |
Завдання існує, але його потрібно ввімкнути. |
|
Помилка або не знайдено |
Завдання відсутнє, і його потрібно створити повторно. |
Увімкнення або повторне створення завдання
Якщо поле стану для secure-Boot-Update вимкнуто, Помилка або Не знайдено, скористайтеся зразком сценарію, щоб увімкнути завдання: Зразок Enable-SecureBootUpdateTask.ps1
Примітка. Цей зразок сценарію не підтримується корпорацією Майкрософт. Адміністратори повинні переглядати та адаптувати його до свого середовища.
Приклад:
.\Enable-SecureBootUpdateTask.ps1 –тихо
Виконати вказівки
-
Якщо ви бачите відмовлено в доступі, повторно виконайте PowerShell із правами адміністратора.
-
Якщо сценарій не буде запущено через політику виконання, скористайтеся обходом процесу:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Потрібна додаткова довідка?
Потрібні додаткові параметри?
Ознайомтеся з перевагами передплати, перегляньте навчальні курси, дізнайтесь, як захистити свій пристрій тощо.
Спільноти допомагають ставити запитання й відповідати на них, надавати відгуки та дізнаватися думки висококваліфікованих експертів.
