Посібник із виправлення неполадок безпечного завантаження

Застосовується до
Windows 10, version 1607, all editions Win 10 Ent LTSB 2016 Win 10 IoT Ent LTSB 2016 Windows 10, version 1809, all editions Win 10 Ent LTSC 2019 Win 10 IoT Ent LTSC 2019 Windows 10 ESU Windows 10 Enterprise LTSC 2021 Windows 10 IoT Enterprise LTSC 2021 Windows 11 version 23H2, all editions Windows 11 version 24H2, all editions Windows 11 version 25H2, all editions Windows 11 version 26H1, all editions Windows Server 2016 Windows Server 2019 Windows Server 2022 Windows Server, version 23H2 Windows Server 2025

Примітка.

  • Дата початкової публікації: 19 березня 2026 р.
  • Ідентифікатор бази знань: 5085046

У цій статті

Огляд

Ця сторінка допомагає адміністраторам і спеціалістам служби підтримки діагностувати та вирішувати проблеми, пов'язані з безпечним завантаженням на пристроях Windows. Теми: помилки оновлення сертифіката безпечного завантаження, неправильні стани безпечного завантаження, неочікувані запити на відновлення BitLocker та помилки завантаження після змін у конфігурації безпечного завантаження.

У цьому керівництві пояснюється, як перевіряти обслуговування та конфігурацію Windows, переглядати відповідні значення реєстру та журнали подій, а також визначати, коли мікропрограма або обмеження платформи вимагають оновлення від виробника оригінального обладнання. Цей вміст призначено для діагностики проблем на наявних пристроях. Її не призначено для планування нового розгортання. Цей документ оновлюватиметься відповідно до нових сценаріїв усунення несправностей і рекомендацій із виправлення неполадок.

догори

Принцип роботи обслуговування сертифікатів безпечного завантаження

Обслуговування сертифікатів безпечного завантаження у Windows – це узгоджений процес між операційною системою та мікропрограмою інтерфейсу UEFI пристрою. Мета полягає в тому, щоб оновити критично важливі довірчі прив'язки, зберігаючи при цьому можливість завантаження на кожному етапі.

Цей процес керується запланованим завданням Windows, послідовністю дій оновлення на основі реєстру та вбудованими функціями журналювання та повторних спроб. Разом ці компоненти забезпечують контрольоване та впорядковане оновлення сертифікатів безпечного завантаження та диспетчера завантаження Windows лише після виконання необхідних дій.

догори

З чого почати виправляти неполадки

Якщо пристрій не досягає очікуваного прогресу під час застосування оновлень сертифікатів безпечного завантаження, спочатку визначте категорію проблеми. Більшість проблем припадає на одну з чотирьох областей: стан обслуговування Windows, механізм оновлення безпечного завантаження, поведінку мікропрограми або обмеження платформи чи виробника оригінального обладнання.

Почніть із перевірок нижче, у вказаному порядку. У багатьох випадках цих кроків достатньо, щоб пояснити спостережувану поведінку і визначити подальші дії без більш глибокого дослідження.

  1. Підтвердьте відповідність обслуговування та платформи Windows

    1. Переконайтеся, що пристрій відповідає основним вимогам для отримання оновлень сертифіката безпечного завантаження:
    2. Пристрій працює під керуванням підтримуваної версії Windows.
    3. Інстальовано останні необхідні оновлення системи безпеки Windows.
    4. Безпечне завантаження ввімкнуто в прошивці UEFI.
    5. Якщо хоча б одна з цих умов не виконується, усуньте їх, перш ніж продовжувати роботу з виправлення неполадок.
  2. Перевірка стану завдання безпечного завантаження

    1. Переконайтеся, що механізм Windows, який відповідає за застосування оновлень сертифікатів безпечного завантаження, присутній і працює:
    2. Існує заплановане завдання безпечного оновлення.
    3. Завдання ввімкнуто та виконується як локальна система.
    4. Це завдання було запущено принаймні один раз з моменту інсталяції останнього оновлення системи безпеки Windows.
    5. Якщо завдання вимкнуто, видалено або воно не виконується, оновлення сертифікатів безпечного завантаження не можуть бути застосовані. Під час виправлення неполадок слід зосередитися на відновленні завдання, перш ніж з'ясовувати інші причини.
  3. Перевірка параметрів реєстру для очікуваного перебігу виконання
    Перегляньте стан обслуговування пристрою Secure Boot в реєстрі:

    1. Ознайомтеся з UEFICA2023Status, UEFICA2023Error і UEFICA2023ErrorEvent.
    2. Перевірте Доступні оновлення та порівняйте їх із очікуваним перебігом подій (див. розділ «Довідкові матеріали» та «Внутрішні дані»).

    Разом ці значення вказують на те, чи обслуговування протікає нормально, повторює спробу операції або зупиняється на певному етапі.

  4. Співвіднесення стану реєстру з подіями безпечного завантаження
    Перегляньте події, пов'язані з безпечним завантаженням, у системному журналі подій і зіставте їх зі станом реєстру. Дані про події зазвичай підтверджують: пристрій виконує прогнозні дії, повторює спробу через тимчасовий стан або блокується через проблему з мікропрограмою чи платформою.
    Разом реєстр і журнали подій зазвичай указують, чи поведінка очікувана, тимчасова або така, що потребує коригувальних дій.

догори

Заплановане завдання безпечного завантаження

Обслуговування сертифікатів безпечного завантаження реалізується через заплановане завдання Windows під назвою Secure-Boot-Update. Завдання реєструється за таким шляхом:

Примітка.

\Microsoft\Windows\PI\Secure-Boot-Update

Завдання запускається як локальна система. За замовчуванням він запускається під час запуску системи та кожні 12 годин після цього. Під час кожного запуску він перевіряє, чи очікують дії оновлення безпечного завантаження, і намагається застосовувати їх послідовно.

Якщо це завдання вимкнуто або відсутнє, оновлення сертифікатів безпечного завантаження не можуть бути застосовані. Щоб обслуговування безпечного завантаження працювало, завдання оновлення безпечного завантаження має залишатися ввімкнутим.

догори

Причини використання запланованого завдання

Оновлення сертифікатів безпечного завантаження вимагають узгодження між Windows і прошивкою UEFI, включно з записом змінних UEFI, які зберігають ключі та сертифікати безпечного завантаження. Заплановане завдання дає змогу Windows спробувати виконати ці оновлення, коли система перебуває в стані, коли змінні мікропрограми можна змінювати.

Повторюваний 12-годинний графік надає додаткові можливості для повторних спроб оновлень, якщо попередня спроба виявилася невдалою або якщо пристрій залишався ввімкненим без перезавантаження. Така конструкція допомагає забезпечити поступ без ручного втручання.

догори

Бітова маска реєстру AvailableUpdates

Виконання завдання безпечного завантаження залежить від значення реєстру AvailableUpdates . Це значення є 32-бітовою маскою, розташованою за адресою:

Примітка.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot

Кожен біт у цьому значенні відповідає певній дії оновлення безпечного завантаження. Процес оновлення починається, коли Windows або адміністратор явно встановлює ненульове значення для параметра AvailableUpdates . Наприклад, значення " 0x5944 " вказує на те, що очікується кілька дій оновлення.

Коли запускається завдання безпечного завантаження, воно інтерпретує визначені біти як відкладену роботу та обробляє їх у визначеному порядку.

догори

Послідовні оновлення, журналювання та повторна пробна версія

Оновлення сертифікатів безпечного завантаження застосовуються у фіксованому порядку. Кожну дію оновлення розроблено так, щоб можна було безпечно повторювати спроби та виконуватися незалежно. Завдання безпечного завантаження не переходить до наступного кроку, доки не завершиться поточна дія й відповідний біт не буде видалено з AvailableUpdates.

Кожна операція використовує стандартні інтерфейси UEFI для оновлення змінних безпечного завантаження, таких як DB і KEK, або для інсталяції оновленого диспетчера завантаження Windows. Windows записує результати кожного кроку в системний журнал подій. Події успіху підтверджують перебіг виконання завдань, а події невдачі вказують на причину неможливості виконати дію.

Якщо крок оновлення завершується помилкою, завдання зупиняє обробку, записує помилку та залишає пов'язаний біт встановленим. Така операція повторюється під час наступного запуску завдання. Така поведінка під час повторного ознайомлення дозволяє пристроям автоматично відновлюватися після тимчасових умов, наприклад, відсутності підтримки мікропрограм або відкладення оновлень від виробника оригінального обладнання.

Адміністратори можуть відстежувати перебіг виконання, співвідносячи стан реєстру із записами журналу подій. Значення реєстру, як-от UEFICA2023Status, UEFICA2023Error і UEFICA2023ErrorEvent, разом із бітовою маскою AvailableUpdates указують, який крок активний, завершений або заблокований.

Ця комбінація вказує на те, чи пристрій прогресує нормально, повторює спробу операції або зупиняється.

догори

Інтеграція з OEM прошивкою

Оновлення сертифікатів безпечного завантаження залежать від належної поведінки та підтримки мікропрограми інтерфейсу UEFI пристрою. У той час як Windows керує процесом оновлення, мікропрограма відповідає за дотримання політики безпечного завантаження та підтримку баз даних безпечного завантаження.

Виробники оригінального обладнання надають два критично важливі елементи, які забезпечують обслуговування сертифікатів безпечного завантаження:

  • Ключі обміну ключами (KEK) із підписом ключа платформи, які авторизують інсталяцію нових сертифікатів безпечного завантаження.
  • Реалізації мікропрограм, які належним чином зберігають, додають і перевіряють бази даних безпечного завантаження під час оновлення.

Якщо мікропрограма не повністю підтримує цю поведінку, оновлення безпечного завантаження можуть затриматися, повторити спробу на невизначений час або призвести до збоїв завантаження. У таких випадках Windows не може завершити оновлення без змін у мікропрограмі.

Корпорація Майкрософт співпрацює з виробниками оригінального обладнання, щоб виявляти проблеми з мікропрограмами та надавати доступ до виправлених оновлень. Якщо виправлення неполадок вказує на обмеження або дефект мікропрограми, адміністратору може знадобитися інсталювати останнє оновлення мікропрограми інтерфейсу UEFI, надане виробником пристрою, перш ніж оновлення сертифікатів безпечного завантаження буде успішно завершено.

догори

Типові сценарії помилок і способи їх вирішення

Оновлення безпечного завантаження застосовуються запланованим завданням оновлення безпечного завантаження на основі стану реєстру AvailableUpdates .

За звичайних умов ці дії виконуються автоматично та реєструють успішні події після завершення кожного етапу. У деяких випадках поведінка мікропрограми, конфігурація платформи або попередні умови обслуговування можуть перешкоджати прогресу або призвести до неочікуваної поведінки завантаження.

У наведених нижче розділах описано найпоширеніші сценарії відмов, як їх розпізнати, чому вони виникають, і відповідні подальші кроки для відновлення нормальної роботи. Сценарії впорядковано від найчастіших до серйозніших випадків, що впливають на завантаження.

Оновлення безпечного завантаження не застосовуються (немає перебігу виконання)

Якщо оновлення за допомогою безпечного завантаження не відображають перебіг виконання, це зазвичай означає, що процес оновлення ніколи не розпочинався. Як наслідок, очікувані значення реєстру безпечного завантаження та журнали подій відсутні, оскільки механізм оновлення так і не було запущено.

Опис

Процес оновлення не розпочався, тому до пристрою не застосовано жодні сертифікати Secure Boot або оновлений диспетчер завантаження.

Як його розпізнати

  • Відсутні значення реєстру обслуговування безпечного завантаження, такі як UEFICA2023Status.
  • Очікувані події безпечного завантаження (наприклад, 1043, 1044, 1045, 1799, 1801) відсутні в системному журналі.
  • Пристрій продовжує використовувати старіші сертифікати безпечного завантаження та компоненти завантаження.

Причина

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

  • Заплановане завдання оновлення безпечного завантаження вимкнуто або воно відсутнє.
  • Безпечне завантаження вимкнено в прошивці UEFI.
  • Пристрій не відповідає попереднім вимогам до обслуговування Windows, таким як запуск підтримуваної версії Windows або інсталяція обов'язкових оновлень.

Подальші дії

  • Переконайтеся, що пристрій відповідає вимогам до обслуговування Windows і прийнятності платформи.
  • Переконайтеся, що в мікропрограмі ввімкнуто безпечне завантаження.
  • Переконайтеся, що заплановане завдання SecureBootUpdate наявне та чи активовано.

Якщо заплановане завдання вимкнуто або відсутнє, дотримуйтеся вказівок у розділі "Безпечне завантаження, заплановане завдання вимкнуто або видалено ", щоб відновити його. Після відновлення завдання перезавантажте пристрій або запустіть завдання вручну, щоб запустити обслуговування безпечного завантаження.

Пристрій завантажується в систему відновлення BitLocker після оновлення Secure Boot

Інколи оновлення, пов'язані з безпечним завантаженням, можуть спричинити відновлення пристрою BitLocker. Поведінка може бути минущою або постійною, залежно від основної причини.

Сценарій 1. Одноразове відновлення BitLocker після оновлення безпечного завантаження

Що відбувається

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

Причина

Під час першого завантаження після оновлення мікропрограма ще не повідомляє оновлені значення безпечного завантаження, коли Windows намагається повторно закрити BitLocker. Це призводить до тимчасової невідповідності виміряних значень завантаження та викликає відновлення. Під час наступного завантаження мікропрограма належним чином повідомляє про оновлені значення, BitLocker успішно повторює герметизацію, і ця проблема більше не повторюється.

Як його розпізнати

  • Відновлення BitLocker відбувається один раз.
  • Після введення ключа відновлення наступні завантаження не відображають запит на відновлення.
  • Немає поточного замовлення завантаження або участі в PXE.

Подальші дії

  • Введіть ключ відновлення BitLocker, щоб відновити роботу Windows.
  • Перевірте наявність оновлень мікропрограм.

Сценарій 2. Повторне відновлення BitLocker через конфігурацію PXE під час першого завантаження

Що відбувається

Пристрій запускає відновлення BitLocker під час кожного завантаження.

Причина

Пристрій налаштовано на спробу завантаження PXE (мережі) першим. Не вдається виконати спробу завантаження PXE, після чого мікропрограма повертається до диспетчера завантаження Windows на диску.

Це призводить до того, що протягом одного циклу завантаження вимірюються два різні центри підписання:

  • Шлях завантаження PXE підписаний центром сертифікації Microsoft UEFI 2011.
  • Диспетчер завантаження Windows на диску підписаний центром сертифікації Windows UEFI 2023.

Оскільки функція BitLocker спостерігає різні ланцюжки довіри безпечного завантаження під час запуску, вона не може встановити стабільний набір вимірювань TPM для повторного ущільнення. У результаті функція BitLocker запускає відновлення під час кожного завантаження.

Як його розпізнати

  • Відновлення BitLocker активується під час кожного перезавантаження.
  • Якщо ввести ключ відновлення, Windows запуститься, але запит повернеться під час наступного завантаження.
  • PXE або мережеве завантаження налаштовується перед локальним диском у порядку завантаження прошивки.

Подальші дії

  • Налаштуйте порядок завантаження мікропрограми, щоб диспетчер завантаження Windows на диску був першим.
  • Вимкніть завантаження PXE, якщо воно не потрібне.
  • Якщо потрібно використовувати технології PXE, переконайтеся, що в інфраструктурі PXE використовується завантажувач Windows із підписом 2023.
Не вдається завантажити пристрій після скидання функції безпечного завантаження

Опис

Це свідчить про зміну на рівні мікропрограми, а не про проблему Windows. Оновлення безпечного завантаження успішно завершено, але після пізнішого перезавантаження пристрій більше не завантажується у Windows.

Як його розпізнати

  • Пристрій не запускає Windows і може відображати мікропрограму або повідомлення BIOS, що вказує на порушення функції безпечного завантаження.
  • Ця помилка виникає після скидання настройок мікропрограми до значень за замовчуванням.
  • Якщо вимкнути безпечне завантаження, пристрій може знову завантажитися.

Причина

Скидання функції безпечного завантаження до значень мікропрограми за замовчуванням очищує бази даних безпечного завантаження, збережені в мікропрограмі. На пристроях, які вже перейшли на диспетчер завантаження з підписом Windows UEFI CA 2023, це скидання вилучає сертифікати, необхідні для довіри цьому диспетчеру завантаження.

В результаті прошивка більше не розпізнає встановлений диспетчер завантаження Windows як надійний і блокує процес завантаження.

Цей сценарій викликаний не самим оновленням безпечного завантаження, а подальшою дією мікропрограми, яка видалить оновлені прив'язки довіри.

Подальші дії

  • Відновіть необхідний сертифікат, щоб пристрій міг знову завантажитися за допомогою утиліти відновлення Secure Boot.
  • Після відновлення переконайтеся, що на пристрої інстальовано найновішу доступну мікропрограму від виробника пристрою.
  • Уникайте скидання безпечного завантаження до значень за замовчуванням, якщо мікропрограма виробника обладнання не включає оновлені параметри безпечного завантаження за замовчуванням, які довіряють сертифікатам 2023 року.

Утиліта відновлення безпечного завантаження

Щоб відновити систему, виконайте наведені нижче дії.

  1. На другому ПК з Windows, на якому інстальовано оновлення Windows за липень 2024 р. або пізніше, скопіюйте файл SecureBootRecovery.efi з C:\Windows\Boot\EFI\.
  2. Помістіть файл на USB-носій у форматі FAT32 під назвою \EFI\BOOT\ і перейменуйте його на bootx64.efi.
  3. Завантажте пристрій, на який впливає проблема, з USB-носія та запустіть утиліту відновлення. Утиліта додасть до БД Windows UEFI CA 2023.

Після відновлення сертифіката та перезавантаження системи Windows має запуститися у звичайному режимі.

Важливо: У результаті буде повторно застосовано лише один із нових сертифікатів. Після відновлення пристрою переконайтеся, що на ньому повторно застосовано найновіші сертифікати, і розгляньте можливість оновлення BIOS/UEFI системи до найновішої доступної версії. Це може допомогти запобігти повторенню проблеми зі скиданням безпечного завантаження, оскільки багато виробників оригінального обладнання випустили виправлення мікропрограми для цієї конкретної проблеми.

Пристрій не завантажується після оновлення Secure Boot через перезапис мікропрограми в базу даних

Опис

Після застосування оновлення сертифіката безпечного завантаження та перезавантаження пристрій не завантажується, і він не запускається на Windows.

Як його розпізнати

  • Пристрій аварійно завершує роботу відразу після перезавантаження, якого вимагає оновлення безпечного завантаження.
  • Може відображатися помилка мікропрограми або безпечного завантаження, або система може зупинитися до завантаження Windows.
  • Якщо вимкнути безпечне завантаження, пристрій може завантажитися.

Причина

Ця проблема може виникати через помилку в реалізації мікропрограми інтерфейсу UEFI пристрою.

Коли Windows застосовує оновлення сертифікатів безпечного завантаження, очікується, що мікропрограма додасть нові сертифікати до наявної бази даних дозволених підписів безпечного завантаження. Деякі реалізації мікропрограми неправильно перезаписують базу даних замість того, щоб додавати до неї.

Коли це відбувається,

  • Раніше довірені сертифікати, в тому числі сертифікат завантажувача Microsoft 2011, видаляються.
  • Якщо на той момент система все ще використовує диспетчер завантаження, підписаний сертифікатом 2011, мікропрограма більше не довіряє йому.
  • Прошивка відхиляє диспетчер завантаження та блокує процес завантаження.

У деяких випадках база даних також може бути пошкоджена, а не повністю перезаписана, що призведе до того ж результату. Така поведінка спостерігається на певних мікропрограмах, але не очікується у сумісній мікропрограмі.

Подальші дії

  • Увійдіть у меню настроювання мікропрограми та спробуйте скинути параметри безпечного завантаження.
  • Якщо пристрій завантажується після скидання, відвідайте сайт підтримки виробника пристрою, щоб отримати оновлення мікропрограми, яке виправляє обробку бази даних безпечного завантаження.
  • Якщо оновлення мікропрограми доступне, інсталюйте його, перш ніж повторно ввімкнути безпечне завантаження та повторно застосувати оновлення сертифікатів безпечного завантаження.

Якщо скидання настройок не відновлює функціональність завантаження, для подальшого відновлення, швидше за все, потрібні вказівки виробника оригінального обладнання.

Оновлення безпечного завантаження заблоковано через відсутність підпису KEK від виробника оригінального обладнання

Опис

Оновлення сертифіката безпечного завантаження не завершено й залишається заблокованим на етапі оновлення ключа обміну ключами (KEK).

Як його розпізнати

  • Значення реєстру AvailableUpdates залишається встановленим у біті KEK (0x0004) і не очищується.
  • UEFICA2023Статус не переходить до завершеного стану.
  • У системний журнал подій багаторазово записується подія з кодом 1803, що вказує на те, що оновлення KEK не вдалося застосувати.
  • Пристрій продовжує спроби оновлення без подальших спроб.

Причина

Для оновлення безпечного завантаження KEK потрібна авторизація з використанням ключа платформи (PK) пристрою, який належить виробнику оригінального обладнання.

Щоб оновлення пройшло успішно, виробник пристрою повинен надати корпорації Майкрософт KEK з підписом PK для цієї конкретної платформи. Цей KEK із підписом OEM включено до оновлень Windows і дає змогу Windows оновлювати змінну KEK мікропрограми.

Якщо виробник оригінального обладнання не надав KEK з підписом PK для пристрою, Windows не зможе завершити оновлення KEK. У цьому стані:

  • Оновлення безпечного завантаження блокуються за задумом.
  • Системі Windows не вдається вирішити проблему відсутності авторизації.
  • Пристрій може залишатися остаточно неспроможним завершити обслуговування сертифіката безпечного завантаження.

Це може статися на старіших пристроях або пристроях, які не підтримуються, на яких виробник більше не надає оновлення мікропрограми або ключів. Для цього стану немає підтримуваного вручну способу відновлення.

догори

Події оновлення сертифіката безпечного завантаження та індикатори помилок

Коли не вдається застосувати оновлення сертифікатів безпечного завантаження, Windows записує події діагностики, які пояснюють причину блокування перебігу виконання. Ці події записуються, коли оновлення бази даних підписів безпечного завантаження (DB) або ключа обміну ключами ключів (KEK) не може бути безпечно завершено через мікропрограму, стан платформи або умови конфігурації. Сценарії в цьому розділі посилаються на ці події, щоб визначити поширені моделі помилок і відповідні способи їх усунення. Цей розділ призначено для підтримки діагностики й інтерпретації проблем, описаних вище, а не для введення нових сценаріїв відмови.

Повний список ідентифікаторів подій, описів і прикладів записів див. в статті "Події оновлення змінних даних бази даних безпечного завантаження та DBX" (KB5016061).

Помилка оновлення KEK (оновлення бази даних завершено успішно, KEK – ні)

Пристрій може успішно оновлювати сертифікати в базі даних безпечного завантаження, але стається збій під час оновлення KEK. У такому разі не можна завершити процес оновлення безпечного завантаження.

Ознаки захворювання

  • Події сертифікатів DB вказують на перебіг виконання, але етап KEK ще не завершено.
  • AvailableUpdates залишається 0x4004, а 0x0004 біт не очищається після кількох запусків завдань.
  • Може бути присутня подія 1795 або 1803 року.

Тлумачення

  • 1795 зазвичай вказує на помилку мікропрограми під час спроби оновити змінну безпечного завантаження.
  • 1803 указує, що оновлення KEK не можна авторизувати, оскільки для платформи недоступне обов'язкове корисне навантаження KEK з підписом OEM PK.

Наступні кроки

  • У версії 1795 перевірте наявність оновлень мікропрограми від виробника оригінального обладнання та перевірте підтримку мікропрограм для змінних оновлень безпечного завантаження.
  • У разі випуску 1803 перевірте, чи надав виробник оригінального обладнання корпорації Майкрософт KEK з підписом PK, необхідний для моделі пристрою.

Помилка оновлення KEK на гостьових віртуальних машинах, розміщених на Hyper-V

На віртуальних машинах Hyper-V оновлення сертифікатів безпечного завантаження вимагають інсталяції оновлень Windows за березень 2026 р. як на вузлі Hyper-V, так і на гостьовій ОС.

Про помилки оновлення повідомляється безпосередньо від гостя, але подія вказує, де потрібні дії з виправлення:

  • Подія 1795 (наприклад, "Медіафайл захищено від запису"), про яку повідомляється в гості , вказує на те, що на вузлі Hyper-V відсутні оновлення за березень 2026 р. і його потрібно оновити.
  • Подія 1803 , зазначена в гостьовому пакеті , вказує на те, що на самій гостьовій віртуальній машині відсутні оновлення за березень 2026 р. і її потрібно оновити.

догори

Довідкові та внутрішні елементи

Цей розділ містить додаткову довідкову інформацію, призначену для виправлення неполадок і підтримки. Цей шаблон не призначено для планування розгортання. Він розширює механіку обслуговування безпечного завантаження, узагальнену раніше, і надає детальний довідковий матеріал для інтерпретації журналів стану реєстру та подій.

Примітка (розгортання під керуванням ІТ-відділу). Якщо ви налаштовуєте ці параметри за допомогою Групова політика або Microsoft Intune, не слід плутати два схожі параметри. Значення AvailableUpdatesPolicy відповідає налаштованому стану політики. Тим часом AvailableUpdates відображає стан незавершеної роботи з очищення розрядів. Обидва ці методи можуть призвести до одного й того ж результату, але поводяться по-різному, оскільки політика з часом знову застосовується.

догори

Біти доступних оновлень, які використовуються для обслуговування сертифікатів

Наведені нижче біти використовуються для дій із сертифікатом і диспетчером завантаження, описаних у цьому документі. Стовпець "Порядок " відображає послідовність обробки кожного розряду в завданні безпечного завантаження.

порядок Параметр розрядності Використання
1 0x0040 Цей біт повідомляє запланованому завданню додати сертифікат Windows UEFI CA 2023 до бази даних безпечного завантаження. Це дозволяє Windows довіряти диспетчерам завантаження, підписаним цим сертифікатом.
2 0x0800 Цей біт повідомляє запланованому завданню застосувати параметр Microsoft ROM UEFI CA 2023 до бази даних.
Умовна поведінка. Якщо прапорець 0x4000 установлено, заплановане завдання спочатку перевірить базу даних на наявність сертифіката Microsoft Corporation UEFI CA 2011 . Сертифікат Microsoft Option ROM UEFI CA 2023 буде застосовано лише за наявності сертифіката 2011 року.
3 0x1000 Цей біт повідомляє запланованому завданню застосувати Microsoft UEFI CA 2023 до бази даних.
Умовна поведінка. Якщо прапорець 0x4000 установлено, заплановане завдання спочатку перевірить базу даних на наявність сертифіката Microsoft Corporation UEFI CA 2011 . Він застосує сертифікат Microsoft UEFI CA 2023лише за наявності сертифіката 2011 року.
Модифікатор (позначка поведінки) 0x4000 Цей біт змінює поведінку 0x0800 та 0x1000 бітів таким чином, що Microsoft UEFI CA 2023 і Microsoft Option ROM UEFI CA 2023 застосовуються лише в тому випадку, якщо база даних уже містить Microsoft Corporation UEFI CA 2011.

Щоб гарантувати збереження профілю безпеки пристрою, цей біт застосовує нові сертифікати, лише якщо пристрій довіряє сертифікату UEFI CA 2011 корпорації Майкрософт. Не всі пристрої Windows довіряють цьому сертифікату.
4 0x0004 Цей біт наказує запланованому завданню шукати ключ обміну ключами, підписаний ключем платформи (PK) пристрою. PK управляється виробником оригінального обладнання. OEM підписують Microsoft KEK разом зі своїм PK і передають його корпорації Майкрософт, де він включається в щомісячні сукупні оновлення.
5 0x0100 Цей біт повідомляє запланованому завданню застосувати диспетчер завантаження, підписаний центром сертифікації Windows UEFI 2023, до розділу завантаження. Він замінить диспетчер завантаження з підписом PCA 2011 Microsoft Windows Production .

Нотатки.

  • Біт 0x4000 залишиться встановленим після обробки всіх інших бітів.
  • Кожен біт обробляється запланованим завданням безпечного завантаження (у зазначеному вище порядку).
  • Якщо 0x0004 біт не може бути оброблений через відсутність підпису PK KEK, заплановане завдання все одно застосовуватиме оновлення диспетчера завантаження, позначене бітом 0x0100.

догори

Очікуваний перебіг виконання (доступні оновлення)

Коли операція успішно завершується, Windows видаляє пов'язаний біт із AvailableUpdates. Якщо стається помилка, Windows реєструє подію та повторює спробу, коли завдання запуститься знову.

У таблиці нижче показано очікуваний перебіг набрання значень AvailableUpdates після виконання кожної дії оновлення безпечного завантаження.

Крок Біт оброблено Доступні UpdatesОновлення Опис Подію успіху записано Можливі коди подій помилок
Початок 0x5944 Початковий стан до початку обслуговування сертифіката безпечного завантаження. - -
1 0x0040 0x5944 → 0x5904 Windows UEFI CA 2023 додано до бази даних безпечного завантаження. 1036 1032, 1795, 1796, 1802
2 0x0800 0x5904 → 0x5104 Додайте опцію Microsoft 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 вказує на відсутність KEK з підписом OEM PK.

догори

Процедури санації

У цьому розділі наведено покрокові інструкції з усунення певних проблем із безпечним завантаженням. Кожна процедура обмежена чітко визначеним станом і призначена для дотримання лише після того, як первинна діагностика підтвердить, що проблема застосовується. Скористайтеся цими процедурами, щоб відновити очікувану поведінку безпечного завантаження та дозволити оновлення сертифікатів безпечно. Не застосовуйте ці процедури широко або завчасно.

догори

Увімкнення безпечного завантаження у мікропрограмі

Якщо функцію безпечного завантаження вимкнуто на мікропрограмі пристрою, перегляньте розділи Windows 11 і безпечне завантаження, щоб дізнатися більше про її ввімкнення.

догори

Заплановане завдання безпечного завантаження вимкнуто або видалено

Заплановане завдання оновлення безпечного завантаження необхідне для того, щоб Windows застосувала оновлення сертифікатів безпечного завантаження. Якщо завдання вимкнуто або воно відсутнє, обслуговування сертифікатів безпечного завантаження не перебігатиме.

Відомості про завдання

Ім'я завдання Безпечне завантаження
Шлях завдання \Microsoft\Windows\PI\
Повний шлях \Microsoft\Windows\PI\Secure-Boot-Update
Працює як SYSTEM (локальна система)
Тригери Під час запуску та кожні 12 годин
Обов'язковий штат Увімкнуто

Перевірка стану завдання

Запуск із командного рядка PowerShell із правами адміністратора:
schtasks.exe /query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V

Знайдіть поле "Стан ":

Стан Значення
Готовий Завдання існує й активоване.
Спільний доступ Завдання існує, але його потрібно ввімкнути.
Помилка / Не знайдено Завдання відсутнє, і його потрібно створити повторно.

Увімкнення або повторне створення завдання

Якщо поле стану для оновлення безпечного завантаження вимкнуто, відображається помилка або не знайдено, активуйте завдання за допомогою наведеного сценарію. Зразок Enable-SecureBootUpdateTask.ps1

Примітка. Це зразок сценарію, який не підтримується корпорацією Майкрософт. Адміністратори мають переглянути й адаптувати його до свого середовища.

Приклад:

Примітка.

.\Enable-SecureBootUpdateTask.ps1 – тихий

Виконати вказівки

  • Якщо відображається відмова в доступі, повторно запустіть PowerShell із правами адміністратора.
  • Якщо сценарій не запускатиметься через політику виконання, обійдіть область процесу:

Примітка.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

догори