Отстраняване на неизправности
Отнася се за
Първоначална дата на публикуване: 19 март 2026 г.
ИД на КБ: 5085046
В тази статия
Общ преглед
Тази страница насочва администраторите и специалистите по поддръжка в диагностиката и разрешаването на проблеми, свързани със защитеното стартиране на устройства с Windows. Темите включват неуспешни актуализации на сертификат за защитено стартиране, неправилни състояния на защитено стартиране, неочаквани подкани за възстановяване на BitLocker и неуспешни стартирания след промени в конфигурацията на защитеното стартиране.
Указанията обясняват как да проверите обслужването и конфигурацията на Windows, да прегледате съответните стойности в системния регистър и регистрите на събитията и да разберете кога ограниченията на фърмуера или платформата изискват актуализация на OEM. Това съдържание е предназначено за диагностициране на проблеми на съществуващи устройства. То не е предназначено за планиране на нови разполагания. Този документ ще се актуализира с идентифицирането на нови сценарии и указания за отстраняване на неизправности.
Как работи обслужването на сертификата за защитено стартиране
Обслужването на сертификата за защитено стартиране на Windows е координиран процес между операционната система и фърмуера UEFI на устройството. Целта е да актуализирате котвите на критично доверие, като същевременно запазите възможността за зареждане на всеки етап.
Процесът се управлява от планирана задача на Windows, базирана на системния регистър последователност от действия за актуализиране и вградено регистриране и повторен опит за поведение. Заедно тези компоненти гарантират, че сертификатите за защитено стартиране и диспечерът за зареждане на Windows се актуализират по контролиран, подреден начин и само след като необходимите стъпки са успешни.
Откъде да започнете при отстраняване на неизправности
Когато изглежда, че дадено устройство не изпълнява очакван напредък при прилагането на актуализации на сертификата за защитено стартиране, започнете, като идентифицирате категорията на проблема. Повечето проблеми попадат в една от четири области: състояние на обслужване на Windows, механизъм за актуализация на защитеното стартиране, поведение на фърмуера или ограничение на платформа или OEM.
Започнете с проверките по-долу поред. В много случаи тези стъпки са достатъчни, за да се обясни наблюдаваното поведение и да се определят следващите действия без по-задълбочено проучване.
-
Потвърждаване на отговарянето на условията за обслужване и платформа на Windows
-
Уверете се, че устройството отговаря на основните изисквания за получаване на актуализации на сертификата за защитено стартиране:
-
На устройството се изпълнява поддържана версия на Windows.
-
Инсталирани са най-новите задължителни актуализации на защитата на Windows.
-
Защитеното стартиране е разрешено във фърмуера на UEFI.
-
Ако някое от тези условия не е изпълнено, отстранете ги, преди да продължите с по-нататъшно отстраняване на неизправности.
-
-
Проверка на състоянието на задачата за защитено стартиране
-
Уверете се, че механизмът на Windows, отговорен за прилагането на актуализации на сертификата за защитено стартиране, е наличен и функционира:
-
Планираната задача за защитено стартиране съществува.
-
Задачата е разрешена и се изпълнява като локална система.
-
Задачата се изпълнява поне веднъж след инсталирането на най-новата актуализация на защитата на Windows.
-
Ако задачата е забранена, изтрита или не се изпълнява, актуализациите на сертификата за защитено стартиране не могат да бъдат приложени. Отстраняването на неизправности трябва да се съсредоточи върху възстановяването на задачата, преди да се разследват други причини.
-
-
Проверете настройките на системния регистър за очакваното напредване
Прегледайте състоянието на обслужване на защитеното стартиране на устройството в системния регистър:
-
Прегледайте UEFICA2023Status, UEFICA2023Error и UEFICA2023ErrorEvent.
-
Прегледайте AvailableUpdates и го сравнете с очакваното напредване (вж. Справка и Вътрешни).
Заедно тези стойности показват дали обслужването напредва нормално, дали се опитва отново да се изпълни операция, или е прекъснато на определена стъпка.
-
-
Корелация на състоянието на системния регистър със събития на защитено стартиране
Прегледайте събития, свързани със защитеното стартиране, в регистъра на събитията на системата и ги свържете със състоянието на системния регистър. Данните за събитие обикновено потвърждават дали устройството напредва, прави повторен опит поради преходно състояние или е блокирано от проблем с фърмуер или платформа.
Регистрационните файлове на системния регистър и събитията обикновено показват дали поведението е очаквано, временно или изисква коригиращо действие.
Планирана задача за защитено стартиране
Обслужването на сертификата за защитено стартиране се изпълнява чрез планирана задача на Windows с име Secure-Boot-Update. Задачата е регистрирана по следния път:
\Microsoft\Windows\PI\Secure-Boot-Update
Задачата се изпълнява като локална система. По подразбиране се изпълнява при стартиране на системата и на всеки 12 часа след това. Всеки път, когато се изпълнява, той проверява дали са чакащи действия за актуализиране на защитеното стартиране и се опитва да ги приложи последователно.
Ако тази задача е забранена или липсва, актуализациите на сертификата за защитено стартиране не могат да бъдат приложени. Задачата за защитено стартиране трябва да остане разрешена, за да функционира обслужването на защитеното стартиране.
Защо се използва планирана задача
Актуализациите на сертификата за защитено стартиране изискват координация между фърмуера на Windows и UEFI, включително записване на променливи на UEFI, които съхраняват ключове и сертификати за защитено стартиране. Планирана задача позволява на Windows да опита тези актуализации, когато системата е в състояние, в което променливите на фърмуера могат да бъдат променени.
Повтарящият се 12-часов график предоставя допълнителни възможности за повторен опит за актуализиране, ако предишен опит е бил неуспешен или ако устройството е останало включено без рестартиране. Този модел помага да се гарантира напредъкът напред, без да се изисква ръчна намеса.
Bitmask на системния регистър AvailableUpdates
Задачата за защитено стартиране на актуализацията се управлява от стойността на системния регистър AvailableUpdates . Тази стойност е 32-битова маска, разположена в:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Всеки бит в стойността представлява конкретно действие за актуализация на защитеното стартиране. Процесът на актуализиране започва, когато AvailableUpdates е зададен на ненулева стойност – или автоматично от Windows, или изрично от администратор. Например стойност, като например 0x5944 показва, че са чакащи няколко действия за актуализиране.
Когато се изпълнява задачата за защитено стартиране на актуализацията, тя интерпретира набора битове като чакаща работа и ги обработва в определен ред.
Последователни актуализации, регистриране и поведение при повторен опит
Актуализациите на сертификата за защитено стартиране се прилагат в фиксиран ред. Всяко действие за актуализиране е създадено така, че да е безопасно да опитате отново и да завършите независимо. Задачата за защитено стартиране на актуализацията не преминава към следващата стъпка, докато текущото действие не успее, а съответният бит се изчиства от AvailableUpdates.
Всяка операция използва стандартни UEFI интерфейси за актуализиране на променливи на защитено стартиране, като например DB и KEK, или за инсталиране на актуализирания диспечер за зареждане на Windows. Windows записва резултата от всяка стъпка в регистъра на системните събития. Събитията за успех потвърждават напредъка напред, докато събитията за неуспех показват защо дадено действие не може да бъде завършено.
Ако дадена стъпка за актуализиране е неуспешна, задачата спира обработката, регистрира грешката и оставя свързания набор битове. При следващото изпълнение на задачата се прави повторен опит за операцията. Това поведение при повторен опит позволява на устройствата да се възстановяват автоматично от временни условия, като например липсваща поддръжка на фърмуера или забавени актуализации на OEM.
Администраторите могат да проследяват напредъка, като съпоставят състоянието на системния регистър със записите в регистъра на събитията. Стойностите в системния регистър, като например UEFICA2023Status, UEFICA2023Error и UEFICA2023ErrorEvent, заедно с bitmask AvailableUpdates , показват коя стъпка е активна, завършена или блокирана.
Тази комбинация показва дали устройството напредва нормално, опитва се отново да работи или е блокирало.
Интегриране с OEM фърмуер
Актуализациите на сертификата за защитено стартиране зависят от правилното поведение и поддръжка във фърмуера UEFI на устройството. Докато Windows организира процеса на актуализиране, фърмуерът е отговорен за спазването на правилата за защитено стартиране и поддържането на базите данни на защитеното стартиране.
OEM предоставят два критични елемента, които позволяват обслужване на сертификата за защитено стартиране:
-
Ключове за платформа – подписани ключове за обмен на ключове (KEK), които разрешават инсталирането на нови сертификати за защитено стартиране.
-
Внедряване на фърмуер, което правилно запазва, добавя и проверява бази данни със защитено стартиране по време на актуализации.
Ако фърмуерът не поддържа напълно тези поведения, актуализациите на защитеното стартиране могат да прекъснат, да изпробват за неопределено време или да доведат до неуспешни стартирания. В тези случаи Windows не може да завърши актуализацията без промени във фърмуера.
Microsoft работи с OEM, за да идентифицира проблеми с фърмуера и да предостави коригирани актуализации. Когато отстраняването на неизправности показва ограничение или дефект на фърмуера, може да се наложи администраторите да инсталират най-новата актуализация на фърмуера на UEFI, предоставена от производителя на устройството, преди актуализациите на сертификата за защитено стартиране да завършат успешно.
Често срещани сценарии и решения за неуспех
Актуализациите на защитеното стартиране се прилагат от планираната задача за защитено стартиране на базата на състоянието на системния регистър AvailableUpdates .
При нормални условия тези стъпки възникват автоматично и записват събитията за успех, когато всеки етап завърши. В някои случаи поведението на фърмуера, конфигурацията на платформата или задължителните изисквания за обслужване може да попречат на напредъка или да доведат до неочаквано поведение при стартиране.
Разделите по-долу описват най-често срещаните сценарии за неуспех, как да ги разпознавате, защо възникват и съответните следващи стъпки за възстановяване на нормалната операция. Сценариите са подредени от най-често срещаните до по-тежки случаи, които оказват влияние върху стартирането.
Когато актуализациите на защитеното стартиране не показват напредък, това обикновено означава, че процесът на актуализиране никога не е стартиран. В резултат на това очакваните стойности от системния регистър на защитеното стартиране и регистрите на събитията липсват, тъй като механизмът за актуализиране никога не е задействан.
Какво се е случило
Процесът на актуализиране на защитеното стартиране не се стартира, така че не са приложени сертификати за защитено стартиране или актуализиран диспечер за зареждане на устройството.
Как да го разпознаете
-
Няма налични стойности в системния регистър за обслужване на защитеното стартиране, като например UEFICA2023Status.
-
Очакваните събития на защитеното стартиране (например 1043, 1044, 1045, 1799, 1801) липсват от регистъра на системните събития.
-
Устройството продължава да използва по-стари сертификати и компоненти за стартиране на защитено стартиране.
Защо се случва
Този сценарий обикновено възниква, когато е изпълнено едно или повече от следните условия:
-
Планираната задача за защитено стартиране е забранена или липсва.
-
Защитеното стартиране е забранено във фърмуера на UEFI.
-
Устройството не отговаря на предварителните изисквания за обслужване на Windows, като например изпълняване на поддържана версия на Windows или инсталиране на необходимите актуализации.
Какво да направите след това
-
Уверете се, че устройството отговаря на изискванията за обслужване и отговаря на условията на платформата на Windows.
-
Уверете се, че защитеното стартиране е разрешено във фърмуера.
-
Уверете се, че планираната задача SecureBootUpdate съществува и е разрешена.
Ако планираната задача е забранена или липсва, следвайте указанията в Планирана задача за защитено стартиране е забранена или изтрита , за да я възстановите. След като задачата бъде възстановена, рестартирайте устройството или изпълнете задачата ръчно, за да стартирате обслужване на защитеното стартиране.
В някои случаи актуализациите, свързани със защитеното стартиране, могат да доведат до това дадено устройство да влезе в възстановяване на BitLocker. Поведението може да бъде преходно или постоянно в зависимост от основната причина.
Сценарий 1: Еднократно възстановяване на BitLocker след актуализация на защитеното стартиране
Какво се случва
Устройството влиза в възстановяване на BitLocker при първото стартиране след актуализацията на защитеното стартиране, но се зарежда нормално при следващи рестартирания.
Защо се случва
По време на първото стартиране след актуализацията фърмуерът все още не съобщава актуализираните стойности на защитеното стартиране, когато Windows се опитва да направи повторно BitLocker. Това води до временно несъответствие в измерените стойности за стартиране и задейства възстановяване. При следващото стартиране фърмуерът съобщава правилно актуализираните стойности, BitLocker се зарежда успешно и проблемът не се повтаря.
Как да го разпознаете
-
Възстановяването на BitLocker възниква веднъж.
-
След като въведете ключа за възстановяване, следващите ботуши не подканват за възстановяване.
-
Няма текущ ред за зареждане или участие на PXE.
Какво да направите след това
-
Въведете ключа за възстановяване на BitLocker, за да възобновите Windows.
-
Проверете за актуализации на фърмуера.
Сценарий 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 с инсталирана актуализация от юли 2024 г. или по-нова, копирайте SecureBootRecovery.efi от C:\Windows\Boot\EFI\.
-
Поставете файла на ФОРМАТИРАНО С FAT32 USB устройство под \EFI\BOOT\ и го преименувайте на bootx64.efi.
-
Стартирайте засегнатото устройство от USB устройството и разрешете на помощната програма за възстановяване да се стартира. Помощната програма ще добави Windows UEFI CA 2023 към базата данни.
След като сертификатът бъде възстановен и системата се рестартира, Windows трябва да стартира нормално.
Важно: Този процес ще приложи отново само един от новите сертификати. След като устройството бъде възстановено, уверете се, че то е приложило най-новите сертификати отново, и обмислете актуализиране на BIOS/UEFI на системата до най-новата налична версия. Това може да предотврати повторение на проблема със нулирането на защитеното стартиране, тъй като много OEM са пуснали корекции на фърмуера за този конкретен проблем.
Какво се е случило
След като се приложи актуализацията и рестартирането на сертификата за защитено стартиране, устройството не се стартира и не достига до Windows.
Как да го разпознаете
-
Устройството е неуспешно веднага след рестартирането, изисквано от актуализацията на защитеното стартиране.
-
Може да се покаже грешка във фърмуера или защитеното стартиране или системата може да спре, преди Windows да се зареди.
-
Забраняването на защитеното стартиране може да позволи на устройството да се стартира.
Защо се случва
Този проблем може да е причинен от дефект във внедряването на UEFI фърмуера на устройството.
Когато Windows прилага актуализации на сертификат за защитено стартиране, се очаква фърмуерът да добави нови сертификати към съществуващата база данни за подписи (DB) с разрешено защитено стартиране. Някои внедрявания на фърмуера неправилно презаписват базата данни, вместо да добавят към него.
Когато това се случи,
-
Преди надеждните сертификати, включително сертификата на bootloader на Microsoft 2011, се премахват.
-
Ако системата все още използва диспечер за зареждане, подписан със сертификата от 2011 в този момент, фърмуерът вече не му се доверява.
-
Фърмуерът отхвърля диспечера за зареждане и блокира процеса на зареждане.
В някои случаи базата данни също може да се повреди, а не чисто презаписани, което води до същия резултат. Това поведение е наблюдавано при специфични внедрявания на фърмуера и не се очаква на съвместим фърмуер.
Какво да направите след това
-
Въведете менютата за настройка на фърмуера и се опитайте да нулирате настройките за защитено стартиране.
-
Ако устройството се зарежда след нулирането, проверете сайта за поддръжка на производителя на устройството за актуализация на фърмуера, която коригира обработката на базата данни за защитено стартиране.
-
Ако е налична актуализация на фърмуера, инсталирайте я, преди да разрешите отново защитеното стартиране и да приложите отново актуализациите на сертификата за защитено стартиране.
Ако нулирането на защитеното стартиране не възстанови функционалността на зареждане, по-нататъшното възстановяване вероятно изисква указания, специфични за OEM.
Какво се е случило
Актуализацията на сертификата за защитено стартиране не е завършена и остава блокирана на етапа на актуализация на ключ за Exchange ключ (KEK).
Как да го разпознаете
-
Стойността в системния регистър AvailableUpdates остава зададена с KEK бита (0x0004) и не се изчиства.
-
UEFICA2023Status не напредва до завършено състояние.
-
Регистърът на системните събития неколкократно записва ИД на събитие 1803, което показва, че актуализацията на KEK не можа да бъде приложена.
-
Устройството продължава да опитва отново актуализацията, без да напредва напред.
Защо се случва
Актуализирането на KEK за защитено стартиране изисква удостоверяване от платформата ключ (PK) на устройството, който е собственост на OEM.
За да успее актуализацията, производителят на устройството трябва да предостави на Microsoft KEK, подписан с PK , за тази конкретна платформа. Този OEM подписан KEK е включен в актуализациите на Windows и позволява на Windows да актуализира променливата KEK на фърмуера.
Ако OEM не е предоставил PK-подписан KEK за устройството, Windows не може да завърши актуализацията на KEK. В това състояние:
-
Актуализациите на защитеното стартиране са блокирани от дизайна.
-
Windows не може да заобиколи липсващото удостоверяване.
-
Устройството може да остане постоянно в състояние да завърши обслужването на сертификата за защитено стартиране.
Това може да се случи на по-стари или извън поддръжка устройства, при които OEM вече не предоставя актуализации на фърмуера или ключа. Няма поддържан път за ръчно възстановяване за това условие.
Когато актуализациите на сертификата за защитено стартиране не се приложат, Windows записва събития за диагностика, които обясняват защо напредъкът е блокиран. Тези събития се записват при актуализиране на базата данни за подписи на защитеното стартиране (DB) или ключа на Exchange (KEK) не могат да бъдат завършени безопасно поради фърмуер, състояние на платформата или конфигурационни условия. Сценариите в този раздел се обръщат към тези събития, за да идентифицират често срещани модели на неуспех и да определят подходящото отстраняване. Този раздел има за цел да подкрепи диагностицирането и тълкуването на проблемите, описани по-горе, а не да въведе нови сценарии за неуспех.
За пълен списък на ИД на събития, описания и примерни записи вижте Събития за актуализиране на DB и DBX променливи (KB5016061).
Неуспешно актуализиране на KEK (актуализациите на DB са успешни, KEK не)
Дадено устройство може успешно да актуализира сертификати в базата данни за защитено стартиране, но е неуспешно по време на актуализацията на KEK. Когато това се случи, процесът на актуализация на защитеното стартиране не може да бъде завършен.
Симптоми
-
Събитията за DB сертификат показват напредъка, но етапът на KEK не е завършен.
-
AvailableUpdates остава настроен на 0x4004 и 0x0004 бит не се изчиства, след като се изпълни няколко задачи.
-
Възможно е да има събитие 1795 или 1803 .
Тълкуване
-
1795 обикновено показва отказ на фърмуера при опит за актуализиране на променлива за защитено стартиране.
-
1803 показва, че АКТУАЛИЗАЦИЯта на KEK не може да бъде разрешена, тъй като необходимият OEM PK-подписан полезен обем на KEK не е наличен за платформата.
Следващи стъпки
-
За 1795 проверете за актуализации на фърмуера на OEM и проверете поддръжката на фърмуера за актуализации на променливи на защитеното стартиране.
-
За 1803 потвърдете дали OEM е предоставил на Microsoft PK-подписан KEK, необходим за модела на устройството.
Неуспешно актуализиране на KEK на гост виртуални машини, хоствани на Hyper-V
На виртуални машини с Hyper-V актуализациите на сертификата за защитено стартиране изискват актуализациите на Windows от март 2026 г. да бъдат инсталирани както на Hyper-V хоста, така и на вторична ОС.
Неуспешни актуализации се съобщават от госта, но събитието показва къде се изисква отстраняване:
-
Събитие 1795 (например "Мултимедията е защитена срещу запис"), съобщено в госта , показва, че hyper-V хостът липсва актуализацията от март 2026 г. и трябва да бъде актуализиран.
-
Събитие 1803 , съобщено в госта , показва, че на самата гост виртуална машина липсва актуализацията от март 2026 г. и трябва да се актуализира.
Справка и вътрешни
Този раздел съдържа разширена информация за справка, предназначена за отстраняване на неизправности и поддръжка. Не е предназначен за планиране на разполагането. Той се разширява на монтьорите на обслужването на защитеното стартиране, обобщени по-рано, и предоставя подробни референтни материали за интерпретиране на състоянието на системния регистър и регистрите на събитията.
Забележка (Разполагания, управлявани от ИТ): Когато са конфигурирани чрез групови правила или Microsoft Intune, две подобни настройки не трябва да се бъркат. Стойността AvailableUpdatesPolicy представлява състоянието на конфигурираните правила. Междувременно AvailableUpdates отразява състоянието на работа, което се изпълнява в момента и се изчиства битът. И двете устройства могат да управляват един и същ резултат, но се държат по различен начин, защото правилата се прилагат повторно с течение на времето.
AvailableUpdates битове, използвани за обслужване на сертификати
Битовете по-долу се използват за действията на диспечера за зареждане и сертификата, описани в този документ. Колоната "Ред " отразява последователността, в която задачата за защитено стартиране обработва всеки бит.
|
Поръчка |
Настройка на бита |
Употреба |
|---|---|---|
|
1 |
0x0040 |
Този бит показва планираната задача да добави сертификата на Windows UEFI CA 2023 към базата данни за защитено стартиране. Това позволява на Windows да се довери на диспечерите за стартиране, подписани с този сертификат. |
|
2 |
0x0800 |
Този бит показва планираната задача да приложите Microsoft Option 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. За да се гарантира, че профилът за защита на устройството остава същият, този бит прилага тези нови сертификати само ако устройството се доверява на сертификата на Microsoft Corporation UEFI CA 2011. Не всички устройства с Windows се доверяват на този сертификат. |
|
4 |
0x0004 |
Този бит показва на планираната задача да търси ключ за обмен на ключ, подписан от ключа на платформата на устройството (PK). ТК се управлява от OEM. OEM подписват Microsoft KEK със своя PK и го доставят до Microsoft, където е включен в месечните кумулативни актуализации. |
|
5 |
0x0100 |
Този бит показва планираната задача да се приложи диспечерът за зареждане, подписан от Windows UEFI CA 2023, към дяла за стартиране. Това ще замести подписания диспечер за зареждане на Microsoft Windows Production PCA 2011. |
Забележки:
-
Битът 0x4000 ще остане зададен, след като се обработят всички други битове.
-
Всеки бит се обработва от планираната задача за защитено стартиране на актуализацията в реда, показан по-горе.
-
Ако 0x0004 бит не може да се обработи поради липсващ PK подписан 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 подписан KEK.
Процедури за лечение
Този раздел предоставя подробни процедури за отстраняване на конкретни проблеми със защитеното стартиране. Всяка процедура е в обхвата на добре дефинирано условие и е предназначена да бъде следвана само след като първоначалната диагноза потвърди, че проблемът се прилага. Използвайте тези процедури, за да възстановите очакваното поведение на защитеното стартиране и да разрешите актуализациите на сертификатите да продължат безопасно. Не прилагайте тези процедури като цяло или предварително.
Разрешаване на защитеното стартиране във фърмуера
Ако защитеното стартиране е забранено във фърмуера на устройството, вижте Windows 11 и защитено стартиране за подробности относно разрешаването на защитеното стартиране.
Планираната задача за защитено стартиране е забранена или изтрита
Планираната задача за защитено стартиране е задължителна, за да може Windows да приложи актуализации на сертификата за защитено стартиране. Ако задачата е забранена или липсва, обслужването на сертификата за защитено стартиране няма да се изпълнява.
Подробни данни за задачата
|
Име на задача |
Актуализация на защитено стартиране |
|
Път до задачата |
\Microsoft\Windows\PI\ |
|
Пълен път |
\Microsoft\Windows\PI\Secure-Boot-Update |
|
Изпълнява се като |
СИСТЕМА (локална система) |
|
раздела „Превключватели“, |
При стартиране и на всеки 12 часа |
|
Задължително състояние |
Разрешено |
Как се проверява състоянието на задачата
Изпълнение от подкана на PowerShell с администраторски права: schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Потърсете полето Състояние:
|
Състояние |
По смисъла |
|---|---|
|
Готови |
Задачата съществува и е разрешена. |
|
Забранени |
Задачата съществува, но трябва да бъде разрешена. |
|
Грешка/ не е намерена |
Задачата липсва и трябва да бъде създадена отново. |
Как да разрешите или създадете отново задачата
Ако полето за състояние на актуализацията на защитеното стартиране е Забранено, Грешка или Не е намерено, използвайте примерния скрипт, за да разрешите задачата: примерни Enable-SecureBootUpdateTask.ps1
Забележка: Това е примерен скрипт и не се поддържа от Microsoft. Администраторите трябва да го прегледат и приспособят към своята среда.
Пример:
.\Enable-SecureBootUpdateTask.ps1 - тих
Изпълнение на указания
-
Ако виждате Отказан достъп, изпълнете отново PowerShell като администратор.
-
Ако скриптът няма да се изпълни поради правилата за изпълнение, използвайте заобикаляне на обхвата на процеса:
Set-ExecutionPolicy - процес на обхвата - ExecutionPolicy заобикаляне
Нуждаете ли се от още помощ?
Искате ли още опции?
Разгледайте ползите от абонамента, прегледайте курсовете за обучение, научете как да защитите устройството си и още.
Общностите ви помагат да задавате и отговаряте на въпроси, да давате обратна връзка и да получавате информация от експерти с богати знания.
