Uwaga
- Data pierwotnej publikacji: 19 marcu 2026 r
- Identyfikator KB: 5085046
W tym artykule
- Omówienie
- Jak działa obsługa certyfikatów bezpiecznego rozruchu
- Gdzie zacząć podczas rozwiązywania problemów
- Zaplanowane zadanie aktualizacji bezpiecznego rozruchu
- Dlaczego używane jest zaplanowane zadanie
- Maska bitowa rejestru AvailableUpdates
- Integracja z oprogramowaniem sprzętowym OEM
- Typowe scenariusze awarii i rozwiązania
- Materiały referencyjne i wewnętrzne
- Bity funkcji AvailableUpdates używane do obsługi certyfikatów
- Oczekiwany postęp (dostępne_aktualizacje)
- Procedury korygujące
- Włączanie bezpiecznego rozruchu w oprogramowaniu układowym
- Zaplanowane zadanie bezpiecznego rozruchu jest wyłączone lub usunięte
Omówienie
Ta strona prowadzi administratorów i pracowników pomocy technicznej w diagnozowaniu i rozwiązywaniu problemów związanych z bezpiecznym rozruchem na urządzeniach z systemem Windows. Tematy dotyczą błędów aktualizacji certyfikatu bezpiecznego rozruchu, niepoprawnych stanów bezpiecznego rozruchu, nieoczekiwanych monitów odzyskiwania funkcji BitLocker i błędów rozruchu następujących po zmianach konfiguracji bezpiecznego rozruchu.
W tych wskazówkach wyjaśniono, jak zweryfikować obsługę i konfigurację systemu Windows, przejrzeć odpowiednie wartości rejestru i dzienniki zdarzeń oraz określić, kiedy ograniczenia oprogramowania układowego lub platformy wymagają aktualizacji przez producenta OEM. Ta zawartość jest przeznaczona do diagnozowania problemów na istniejących urządzeniach. Nie jest on przeznaczony do planowania nowych wdrożeń. Ten dokument będzie aktualizowany w miarę identyfikowania nowych scenariuszy i wskazówek dotyczących rozwiązywania problemów.
Jak działa obsługa certyfikatów bezpiecznego rozruchu
Obsługa certyfikatu bezpiecznego rozruchu w systemie Windows to skoordynowany proces pomiędzy systemem operacyjnym a oprogramowaniem układowym UEFI urządzenia. Celem jest zaktualizowanie krytycznych kotwic zaufania przy jednoczesnym zachowaniu możliwości rozruchu na każdym etapie.
Proces jest napędzany przez zaplanowane zadanie systemu Windows, sekwencję akcji aktualizacji opartą na rejestrze oraz wbudowane zachowanie rejestrowania i ponawiania prób. Razem te składniki zapewniają, że certyfikaty bezpiecznego rozruchu i menedżer rozruchu systemu Windows są aktualizowane w kontrolowany, uporządkowany sposób i tylko wtedy, gdy kroki wymagań wstępnych zakończą się pomyślnie.
Gdzie zacząć podczas rozwiązywania problemów
Jeśli urządzenie nie osiąga oczekiwanego postępu we wdrażaniu aktualizacji certyfikatu bezpiecznego rozruchu, zacznij od zidentyfikowania kategorii problemu. Większość problemów można podzielić na jeden z czterech obszarów: stan obsługi systemu Windows, mechanizm aktualizacji bezpiecznego rozruchu, zachowanie oprogramowania układowego lub ograniczenie platformy lub producenta OEM.
Rozpocznij od poniższych testów w podanej kolejności. W wielu przypadkach te kroki są wystarczające do wyjaśnienia zaobserwowanego zachowania i określenia kolejnych działań bez głębszego badania.
Potwierdź uprawnienia do obsługi systemu Windows i platformy
- Sprawdź, czy urządzenie spełnia podstawowe wymagania dotyczące otrzymywania aktualizacji certyfikatu bezpiecznego rozruchu:
- Na urządzeniu jest uruchomiona obsługiwana wersja systemu Windows.
- Zainstalowano najnowsze wymagane aktualizacje zabezpieczeń systemu Windows.
- Bezpieczny rozruch jest włączony w oprogramowaniu układowym UEFI.
- Jeśli którykolwiek z tych warunków nie jest spełniony, rozwiąż go przed kontynuowaniem dalszego rozwiązywania problemów.
Sprawdź stan zadania aktualizacji bezpiecznego rozruchu
- Upewnij się, że mechanizm systemu Windows odpowiedzialny za stosowanie aktualizacji certyfikatu bezpiecznego rozruchu jest obecny i działa:
- Istnieje zaplanowane zadanie Secure-Boot-Update.
- Zadanie jest włączone i działa jako system lokalny.
- Zadanie zostało uruchomione co najmniej raz od momentu zainstalowania najnowszej aktualizacji zabezpieczeń systemu Windows.
- Jeśli zadanie jest wyłączone, usunięte lub nie jest uruchomione, nie można zastosować aktualizacji certyfikatu bezpiecznego rozruchu. Rozwiązywanie problemów powinno koncentrować się na przywróceniu zadania, a nie na badaniu innych przyczyn.
Sprawdzanie ustawień rejestru pod kątem oczekiwanego postępu
Sprawdź stan obsługi bezpiecznego rozruchu urządzenia w rejestrze:- Sprawdź UEFICA2023Status, UEFICA2023Error i UEFICA2023ErrorEvent.
- Przeanalizuj dostępne aktualizacje i porównaj je z oczekiwanym postępem (zobacz Materiały referencyjne i wewnętrzne).
Razem te wartości wskazują, czy obsługa przebiega normalnie, ponawia próbę wykonania operacji, czy też zatrzymała się na określonym kroku.
Skorelowanie stanu rejestru ze zdarzeniami bezpiecznego rozruchu
Przejrzyj zdarzenia związane z bezpiecznym rozruchem w dzienniku zdarzeń systemowych i skoreluj je ze stanem rejestru. Dane zdarzeń zwykle potwierdzają, czy urządzenie postępuje, ponawia próbę z powodu stanu przejściowego lub jest blokowane przez problem z oprogramowaniem układowym lub platformą.
Rejestr razem z dziennikami zdarzeń zwykle wskazuje, czy dane zachowanie jest oczekiwane, tymczasowe, czy wymaga podjęcia działań naprawczych.
Zaplanowane zadanie aktualizacji bezpiecznego rozruchu
Obsługa certyfikatów bezpiecznego rozruchu jest implementowana za pośrednictwem zaplanowanego zadania systemu Windows o nazwie Secure-Boot-Update. Zadanie jest rejestrowane w następującej ścieżce:
Uwaga
\Microsoft\Windows\PI\Secure-Boot-Update
Zadanie jest uruchamiane jako system lokalny. Domyślnie jest uruchamiany podczas uruchamiania systemu, a następnie co 12 godzin. Za każdym razem, gdy jest uruchamiany, sprawdza, czy akcje aktualizacji bezpiecznego rozruchu są oczekujące, i próbuje zastosować je po kolei.
Jeśli to zadanie jest wyłączone lub go brakuje, nie można zastosować aktualizacji certyfikatu bezpiecznego rozruchu. Zadanie Secure-Boot-Update musi pozostać włączone, aby obsługa bezpiecznego rozruchu działała.
Dlaczego używane jest zaplanowane zadanie
Aktualizacje certyfikatu bezpiecznego rozruchu wymagają koordynacji między systemem Windows i oprogramowaniem układowym UEFI, w tym zapisania zmiennych UEFI, które przechowują klucze bezpiecznego rozruchu i certyfikaty. Zaplanowane zadanie umożliwia systemowi Windows podjęcie próby zainstalowania tych aktualizacji, gdy system znajduje się w stanie, w którym można modyfikować zmienne oprogramowania układowego.
Cykliczny 12-godzinny harmonogram zapewnia dodatkowe możliwości ponowienia próby aktualizacji, jeśli poprzednia próba się nie powiodła lub jeśli urządzenie pozostało włączone bez ponownego uruchomienia. Taki projekt pomaga zapewnić postęp bez konieczności ręcznej interwencji.
Maska bitowa rejestru AvailableUpdates
Zadanie Secure-Boot-Update jest sterowane przez wartość rejestru AvailableUpdates . Ta wartość to 32-bitowa maska bitowa znajdująca się w:
Uwaga
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Każdy bit w wartości odpowiada konkretnej akcji aktualizacji bezpiecznego rozruchu. Proces aktualizacji rozpoczyna się, gdy parametr AvailableUpdates jest ustawiony na wartość inną niż zero, automatycznie przez system Windows lub jawnie przez administratora. Na przykład wartość 0x5944 oznacza, że oczekuje na aktualizację wielu razy.
Po uruchomieniu zadania Secure-Boot-Update interpretuje ustawione bity jako oczekujące na pracę i przetwarza je w określonej kolejności.
Aktualizacje sekwencyjne, rejestrowanie i działanie związane z ponownymi próbami
Aktualizacje certyfikatu bezpiecznego rozruchu są stosowane w ustalonej kolejności. Każda akcja aktualizacji została zaprojektowana tak, aby można było bezpiecznie ponawiać próby i jest ona wykonywana niezależnie. Zadanie Secure-Boot-Update nie przechodzi do następnego kroku, dopóki bieżąca akcja nie zakończy się powodzeniem, a odpowiadający mu bit zostanie wyczyszczony z AvailableUpdates.
Każda operacja używa standardowych interfejsów UEFI do aktualizacji zmiennych bezpiecznego rozruchu, takich jak DB i KEK, lub do zainstalowania zaktualizowanego menedżera rozruchu systemu Windows. System Windows zapisuje wynik każdego kroku w dzienniku zdarzeń systemowych. Zdarzenia sukcesu potwierdzają postęp, a zdarzenia niepowodzenia wskazują, dlaczego nie można ukończyć akcji.
Jeśli wykonanie kroku aktualizacji zakończy się niepowodzeniem, zadanie przestaje przetwarzać, błąd jest rejestrowany i pozostawia skojarzony bit ustawiony. Operacja jest ponawiana przy następnym uruchomieniu zadania. To zachowanie podczas ponownych prób umożliwia automatyczne odzyskiwanie urządzeń po sytuacjach tymczasowych, takich jak brak obsługi oprogramowania układowego lub opóźnione aktualizacje OEM.
Administratorzy mogą śledzić postęp, korelując stan rejestru z wpisami dziennika zdarzeń. Wartości rejestru, takie jak UEFICA2023Status, UEFICA2023Error i UEFICA2023ErrorEvent, wraz z maską bitową AvailableUpdates wskazują, który krok jest aktywny, ukończony lub zablokowany.
Ta kombinacja pokazuje, czy urządzenie postępuje normalnie, ponawia operację, czy też utknęło w martwym punkcie.
Integracja z oprogramowaniem sprzętowym OEM
Aktualizacje certyfikatu bezpiecznego rozruchu zależą od poprawnego działania i obsługi w oprogramowaniu układowym UEFI urządzenia. Podczas gdy system Windows organizuje proces aktualizacji, oprogramowanie układowe jest odpowiedzialne za egzekwowanie zasad bezpiecznego rozruchu i obsługę baz danych bezpiecznego rozruchu.
Producenci OEM zapewniają dwa krytyczne elementy umożliwiające obsługę certyfikatów bezpiecznego rozruchu:
- Klucze wymiany kluczy (KEK) podpisane kluczem platformy, które autoryzują instalację nowych certyfikatów bezpiecznego rozruchu.
- Implementacje oprogramowania układowego, które poprawnie zachowują, dołączają i sprawdzają poprawność baz danych bezpiecznego rozruchu podczas aktualizacji.
Jeśli oprogramowanie układowe nie obsługuje w pełni tych zachowań, aktualizacje bezpiecznego rozruchu mogą się zatrzymać, ponawiać próbę w nieskończoność lub spowodować niepowodzenie rozruchu. W takich przypadkach system Windows nie może ukończyć aktualizacji bez zmian w oprogramowaniu układowym.
Firma Microsoft współpracuje z producentami OEM w celu identyfikowania problemów z oprogramowaniem układowym i udostępniania poprawionych aktualizacji. Gdy rozwiązywanie problemów wskazuje na ograniczenie lub defekt oprogramowania układowego, administratorzy mogą być zmuszeni do zainstalowania najnowszej aktualizacji oprogramowania układowego UEFI dostarczonej przez producenta urządzenia, zanim aktualizacje certyfikatu bezpiecznego rozruchu będą mogły zostać pomyślnie ukończone.
Typowe scenariusze awarii i rozwiązania
Aktualizacje bezpiecznego rozruchu są stosowane przez zaplanowane zadanie Secure-Boot-Update na podstawie stanu rejestru AvailableUpdates .
W normalnych warunkach te kroki są wykonywane automatycznie i rejestrują zdarzenia sukcesu po zakończeniu każdego etapu. W niektórych przypadkach zachowanie oprogramowania układowego, konfiguracja platformy lub wymagania wstępne usług serwisowych mogą uniemożliwiać postęp lub prowadzić do nieoczekiwanego zachowania rozruchu.
W poniższych sekcjach opisano najczęstsze scenariusze awarii, sposób ich rozpoznawania, przyczyny występowania oraz odpowiednie kolejne kroki w celu przywrócenia normalnego działania. Scenariusze są uporządkowane od najczęściej spotykanych do bardziej poważnych przypadków mających wpływ na rozruch.
Aktualizacje bezpiecznego rozruchu nie są stosowane (brak postępu)
Jeśli aktualizacje bezpiecznego rozruchu nie pokazują postępu, zwykle oznacza to, że proces aktualizacji nigdy się nie rozpoczął. W związku z tym brakuje oczekiwanych wartości rejestru i dzienników zdarzeń bezpiecznego rozruchu, ponieważ mechanizm aktualizacji nigdy nie został wyzwolony.
Co się stało?
Proces aktualizacji bezpiecznego rozruchu nie rozpoczął się, więc do urządzenia nie zostały zastosowane żadne certyfikaty bezpiecznego rozruchu ani zaktualizowany menedżer rozruchu.
Jak je rozpoznać
- Brak wartości rejestru obsługi bezpiecznego rozruchu, takich jak UEFICA2023Status.
- W dzienniku zdarzeń systemowych brakuje oczekiwanych zdarzeń bezpiecznego rozruchu (na przykład 1043, 1044, 1045, 1799, 1801).
- Urządzenie nadal używa starszych certyfikatów bezpiecznego rozruchu i składników rozruchowych.
Dlaczego tak się dzieje
Ten scenariusz występuje zazwyczaj, gdy spełniony jest co najmniej jeden z następujących warunków:
- Zaplanowane zadanie aktualizacji bezpiecznego rozruchu jest wyłączone lub go brakuje.
- Bezpieczny rozruch jest wyłączony w oprogramowaniu układowym UEFI.
- Urządzenie nie spełnia wymagań wstępnych obsługi systemu Windows, takich jak obsługiwana wersja systemu Windows lub zainstalowane wymagane aktualizacje.
Co należy zrobić dalej
- Sprawdź, czy urządzenie spełnia wymagania dotyczące obsługi i platformy systemu Windows.
- Upewnij się, że bezpieczny rozruch jest włączony w oprogramowaniu układowym.
- Upewnij się, że zaplanowane zadanie SecureBootUpdate istnieje i jest włączone.
Jeśli zaplanowane zadanie jest wyłączone lub go brakuje, postępuj zgodnie ze wskazówkami w artykule Zaplanowane zadanie bezpiecznego rozruchu zostało wyłączone lub usunięte , aby je przywrócić. Po przywróceniu zadania uruchom ponownie urządzenie lub uruchom zadanie ręcznie, aby zainicjować obsługę bezpiecznego rozruchu.
Urządzenie uruchamia się w trybie odzyskiwania funkcji BitLocker po aktualizacji bezpiecznego rozruchu
W niektórych przypadkach aktualizacje związane z bezpiecznym rozruchem mogą spowodować przejście urządzenia do trybu odzyskiwania funkcji BitLocker. To zachowanie może być przejściowe lub trwałe, w zależności od przyczyny leżącej u podstaw problemu.
Scenariusz 1: Jednorazowe odzyskiwanie funkcji BitLocker po aktualizacji bezpiecznego rozruchu
Efekt
Urządzenie przechodzi w tryb odzyskiwania funkcji BitLocker przy pierwszym rozruchu po aktualizacji bezpiecznego rozruchu, ale uruchamia się normalnie przy kolejnych ponownych uruchomieniach.
Dlaczego tak się dzieje
Podczas pierwszego rozruchu po aktualizacji oprogramowanie układowe nie zgłasza jeszcze zaktualizowanych wartości bezpiecznego rozruchu, gdy system Windows próbuje ponownie zapieczętować funkcję BitLocker. Powoduje to tymczasowe niedopasowanie zmierzonych wartości rozruchowych i wyzwala odzyskiwanie. Przy następnym rozruchu oprogramowanie układowe poprawnie zgłasza zaktualizowane wartości, funkcja BitLocker pomyślnie ponownie blokuje i problem nie wraca.
Jak je rozpoznać
- Odzyskiwanie funkcji BitLocker następuje raz.
- Po wprowadzeniu klucza odzyskiwania kolejne rozruchy nie powodują monitu o odzyskanie danych.
- Nie ma bieżącej kolejności rozruchu ani zaangażowania PXE.
Co należy zrobić dalej
- Wprowadź klucz odzyskiwania funkcji BitLocker, aby wznowić działanie systemu Windows.
- Sprawdź, czy są dostępne aktualizacje oprogramowania układowego.
Scenariusz 2: Powtarzające się odzyskiwanie funkcji BitLocker z powodu konfiguracji pierwszego rozruchu środowiska PXE
Efekt
Urządzenie przechodzi w tryb odzyskiwania funkcji BitLocker przy każdym rozruchu.
Dlaczego tak się dzieje
Urządzenie jest skonfigurowane tak, aby najpierw próbował uruchomić środowisko PXE (w sieci). Próba uruchomienia środowiska PXE kończy się niepowodzeniem, a oprogramowanie układowe powraca do menedżera rozruchu systemu Windows na dysku.
Powoduje to mierzenie dwóch różnych urzędów podpisujących podczas jednego cyklu rozruchu:
- Ścieżka rozruchu środowiska PXE jest podpisana przez interfejs Microsoft UEFI CA 2011.
- Menedżer rozruchu systemu Windows na dysku jest podpisany przez Windows UEFI CA 2023.
Ponieważ funkcja BitLocker obserwuje różne łańcuchy zaufania bezpiecznego rozruchu podczas uruchamiania, nie może ustanowić stabilnego zestawu pomiarów modułu TPM do ponownego zapieczętowania. W efekcie funkcja BitLocker przechodzi w tryb odzyskiwania przy każdym rozruchu.
Jak je rozpoznać
- Odzyskiwanie funkcji BitLocker jest wyzwalane przy każdym ponownym uruchomieniu.
- Wprowadzenie klucza odzyskiwania umożliwia uruchomienie systemu Windows, ale monit powraca przy następnym uruchomieniu.
- PXE lub rozruch sieciowy jest skonfigurowany przed dyskiem lokalnym w kolejności rozruchu oprogramowania układowego.
Co należy zrobić dalej
- Skonfiguruj kolejność rozruchu oprogramowania układowego, tak aby menedżer rozruchu systemu Windows na dysku był pierwszy.
- Wyłącz rozruch środowiska PXE, jeśli nie jest wymagany.
- Jeśli środowisko PXE jest wymagane, upewnij się, że infrastruktura środowiska PXE korzysta z modułu ładującego rozruchu systemu Windows podpisanego w 2023 r.
Urządzenie nie uruchamia się po zresetowaniu bezpiecznego rozruchu
Co się stało?
Odzwierciedla to zmianę na poziomie oprogramowania układowego, a nie problem z systemem Windows. Aktualizacja bezpiecznego rozruchu została ukończona pomyślnie, ale po późniejszym ponownym uruchomieniu urządzenie nie uruchamia się już w systemie Windows.
Jak je rozpoznać
- Urządzenie nie uruchamia systemu Windows i może wyświetlić komunikat oprogramowania układowego lub systemu BIOS wskazujący na naruszenie zasad bezpiecznego rozruchu.
- Błąd występuje po przywróceniu domyślnych ustawień oprogramowania układowego bezpiecznego rozruchu.
- Wyłączenie bezpiecznego rozruchu może umożliwić ponowne uruchomienie urządzenia.
Dlaczego tak się dzieje
Zresetowanie Bezpiecznego rozruchu do ustawień domyślnych oprogramowania układowego czyści bazy danych Bezpiecznego rozruchu przechowywane w oprogramowaniu układowym. W przypadku urządzeń, które przeszły już do menedżera rozruchu podpisanego przez Windows UEFI CA 2023, ten reset usuwa certyfikaty wymagane do zaufania temu menedżerowi rozruchu.
W rezultacie oprogramowanie układowe nie rozpoznaje już zainstalowanego menedżera rozruchu systemu Windows jako zaufanego i blokuje proces rozruchu.
Ten scenariusz nie jest spowodowany samą aktualizacją bezpiecznego rozruchu, ale kolejną akcją oprogramowania układowego, która usuwa zaktualizowane kotwice zaufania.
Co należy zrobić dalej
- Użyj narzędzia do odzyskiwania bezpiecznego rozruchu, aby przywrócić wymagany certyfikat, dzięki czemu urządzenie będzie mogło ponownie się uruchomić.
- Po odzyskaniu sprawności upewnij się, że urządzenie ma zainstalowane najnowsze oprogramowanie układowe udostępnione przez producenta urządzenia.
- Unikaj resetowania domyślnego oprogramowania sprzętowego bezpiecznego rozruchu, chyba że oprogramowanie układowe producenta OEM zawiera zaktualizowane ustawienia domyślne bezpiecznego rozruchu, które ufają certyfikatom z 2023 r.
Narzędzie do odzyskiwania bezpiecznego rozruchu
Aby odzyskać system:
- Na drugim komputerze z systemem Windows z zainstalowaną aktualizacją systemu Windows z lipca 2024 r. lub nowszą skopiuj plik SecureBootRecovery.efi z folderu C:\Windows\Boot\EFI\.
- Umieść plik na dysku USB sformatowanym w systemie FAT32 w obszarze \EFI\BOOT\ i zmień jego nazwę na bootx64.efi.
- Uruchom urządzenie, którego dotyczy problem, z dysku USB i poczekaj na uruchomienie narzędzia odzyskiwania. Narzędzie doda Windows UEFI CA 2023 do bazy danych.
Po przywróceniu certyfikatu i ponownym uruchomieniu systemu system Windows powinien uruchomić się normalnie.
Ważne: W ramach tego procesu zostanie ponownie zastosowany tylko jeden z nowych certyfikatów. Po odzyskaniu urządzenia upewnij się, że zastosowano na nim najnowsze certyfikaty, i rozważ zaktualizowanie systemu BIOS/interfejsu UEFI do najnowszej dostępnej wersji. Może to pomóc zapobiec ponownemu wystąpieniu problemu z resetowaniem bezpiecznego rozruchu, ponieważ wielu producentów OEM opublikowało poprawki oprogramowania układowego dla tego konkretnego problemu.
Urządzenie nie uruchamia się po aktualizacji bezpiecznego rozruchu z powodu nadpisania bazy danych oprogramowania układowego
Co się stało?
Po zastosowaniu aktualizacji certyfikatu bezpiecznego rozruchu i ponownym uruchomieniu urządzenie nie uruchamia się i nie dociera do systemu Windows.
Jak je rozpoznać
- Urządzenie ulega awarii natychmiast po ponownym uruchomieniu wymaganym przez aktualizację bezpiecznego rozruchu.
- Może zostać wyświetlony błąd oprogramowania układowego lub bezpiecznego rozruchu albo system może się zatrzymać przed załadowaniem systemu Windows.
- Wyłączenie bezpiecznego rozruchu może umożliwić uruchomienie urządzenia.
Dlaczego tak się dzieje
Ten problem może być spowodowany defektem implementacji oprogramowania układowego UEFI urządzenia.
Gdy system Windows stosuje aktualizacje certyfikatów bezpiecznego rozruchu, oprogramowanie układowe powinno dołączyć nowe certyfikaty do istniejącej bazy danych sygnatur dozwolonych za bezpieczny rozruch (DB). Niektóre implementacje oprogramowania układowego niepoprawnie zastępują bazę danych zamiast dołączać do niej.
W takim przypadku
- Poprzednio zaufane certyfikaty, w tym certyfikat programu ładującego Microsoft 2011, zostaną usunięte.
- Jeśli w tym momencie system nadal używa menedżera rozruchu podpisanego certyfikatem 2011, oprogramowanie układowe przestaje mu ufać.
- Oprogramowanie układowe odrzuca menedżera rozruchu i blokuje proces rozruchu.
W niektórych przypadkach baza danych może również zostać uszkodzona, a nie całkowicie nadpisana, co prowadzi do tego samego wyniku. To zachowanie zaobserwowano w określonych implementacjach oprogramowania układowego i nie jest oczekiwane w zgodnym oprogramowaniu układowym.
Co należy zrobić dalej
- Wejdź do menu konfiguracji oprogramowania układowego i spróbuj zresetować ustawienia bezpiecznego rozruchu.
- Jeśli urządzenie uruchamia się ponownie po zresetowaniu, sprawdź, czy w witrynie pomocy technicznej producenta urządzenia jest dostępna aktualizacja oprogramowania układowego, która koryguje obsługę bazy danych bezpiecznego rozruchu.
- Jeśli aktualizacja oprogramowania układowego jest dostępna, zainstaluj ją przed ponownym włączeniem bezpiecznego rozruchu i zastosowaniem aktualizacji certyfikatu bezpiecznego rozruchu.
Jeśli zresetowanie funkcji bezpiecznego rozruchu nie spowoduje przywrócenia funkcjonalności rozruchu, dalsze odzyskiwanie prawdopodobnie będzie wymagało wskazówek producenta OEM.
Aktualizacja bezpiecznego rozruchu zablokowana z powodu braku klucza KEK podpisanego przez producenta OEM
Co się stało?
Aktualizacja certyfikatu bezpiecznego rozruchu nie została ukończona i pozostaje zablokowana na etapie aktualizacji klucza wymiany kluczy (KEK).
Jak je rozpoznać
- Wartość rejestru AvailableUpdates pozostaje ustawiona za pomocą bitu KEK (0x0004) i nie jest czyszczona.
- UEFICA2023Stan nie przechodzi do stanu zakończenia.
- Dziennik zdarzeń systemowych wielokrotnie rejestruje zdarzenie o identyfikatorze 1803, co wskazuje, że nie można zastosować aktualizacji klucza KEK.
- Urządzenie kontynuuje ponawianie próby aktualizacji bez robienia postępów.
Dlaczego tak się dzieje
Aktualizacja klucza KEK bezpiecznego rozruchu wymaga autoryzacji z klucza platformy urządzenia (PK), który jest własnością producenta OEM.
Aby aktualizacja zakończyła się pomyślnie, producent urządzenia musi dostarczyć firmie Microsoft klucz KEK podpisany przez klucz katalogowy dla tej platformy. Ten podpisany przez producenta OEM klucz KEK jest uwzględniony w aktualizacjach systemu Windows i umożliwia systemowi Windows aktualizowanie zmiennej KEK oprogramowania układowego.
Jeśli producent OEM nie dostarczył klucza KEK podpisanego przez klucz sprzętowy dla urządzenia, system Windows nie będzie mógł ukończyć aktualizacji klucza KEK. W tym stanie:
- Aktualizacje bezpiecznego rozruchu są celowo blokowane.
- System Windows nie może obejść problemu z brakującą autoryzacją.
- Urządzenie może trwale nie być w stanie ukończyć obsługi certyfikatu bezpiecznego rozruchu.
Może się to zdarzyć w przypadku starszych lub nieobsługiwanych urządzeń, na których producent OEM nie zapewnia już aktualizacji oprogramowania układowego ani kluczy. Nie ma obsługiwanej ścieżki odzyskiwania ręcznego dla tego warunku.
Zdarzenia aktualizacji certyfikatu bezpiecznego rozruchu i wskaźniki niepowodzeń
Gdy nie można zastosować aktualizacji certyfikatu bezpiecznego rozruchu, system Windows rejestruje zdarzenia diagnostyczne, które wyjaśniają, dlaczego postęp został zablokowany. Te zdarzenia są zapisywane, gdy aktualizacja bazy danych sygnatur bezpiecznego rozruchu (DB) lub klucza wymiany kluczy (KEK) nie może być bezpiecznie ukończona ze względu na oprogramowanie układowe, stan platformy lub warunki konfiguracji. Scenariusze przedstawione w tej sekcji odwołują się do tych zdarzeń w celu zidentyfikowania typowych wzorców błędów i określenia odpowiednich środków zaradczych. Ta sekcja ma na celu wsparcie diagnozowania i interpretacji opisanych wcześniej problemów, a nie wprowadzanie nowych scenariuszy awarii.
Aby uzyskać pełną listę identyfikatorów zdarzeń, opisów i przykładowych wpisów, zobacz Zdarzenia aktualizacji zmiennych DB bezpiecznego rozruchu i DBX (KB5016061).
Błąd aktualizacji KEK (aktualizacje bazy danych kończą się powodzeniem, KEK nie)
Urządzenie może pomyślnie zaktualizować certyfikaty w bazie danych bezpiecznego rozruchu, ale nie powiedzie się podczas aktualizacji KEK. W takim przypadku nie można ukończyć procesu aktualizacji bezpiecznego rozruchu.
Objawy
- Zdarzenia certyfikatu DB wskazują postęp, ale etap KEK nie został ukończony.
- Parametr AvailableUpdates pozostaje ustawiony na wartość 0x4004, a bit 0x0004 nie jest czyszczony po wielu uruchomieniach zadań.
- Mogło występować zdarzenie 1795 lub 1803 .
Tłumaczenia ustne
- 1795 zazwyczaj wskazuje błąd oprogramowania układowego podczas próby aktualizacji zmiennej bezpiecznego rozruchu.
- 1803 wskazuje, że aktualizacja KEK nie może być autoryzowana, ponieważ wymagany ładunek KEK podpisany przez OEM PK nie jest dostępny dla platformy.
Następne kroki
- W przypadku wersji 1795 sprawdź dostępność aktualizacji oprogramowania układowego producenta OEM i potwierdź obsługę aktualizacji zmiennej bezpiecznego rozruchu.
- W przypadku wersji 1803 potwierdź, czy producent OEM dostarczył firmie Microsoft klucz KEK podpisany kluczem podstawowym wymagany dla modelu urządzenia.
Błąd aktualizacji KEK na maszynach wirtualnych gości hostowanych w funkcji Hyper-V
W przypadku maszyn wirtualnych Hyper-V aktualizacje certyfikatu bezpiecznego rozruchu wymagają, aby aktualizacje systemu Windows z marca 2026 r. zostały zainstalowane zarówno na hoście Hyper-V, jak i w systemie operacyjnym gościa.
Błędy aktualizacji są zgłaszane z poziomu gościa, ale zdarzenie wskazuje, gdzie wymagane jest podjęcie działań naprawczych:
- Zdarzenie 1795 (na przykład "Nośnik jest chroniony przed zapisem") zgłoszone w gościu wskazuje, że na hoście Hyper-V brakuje aktualizacji z marca 2026 r. i należy go zaktualizować.
- Zdarzenie 1803 zgłoszone w gościu wskazuje, że na maszynie wirtualnej gościa brakuje aktualizacji z marca 2026 r. i należy ją zaktualizować.
Materiały referencyjne i wewnętrzne
Ta sekcja zawiera zaawansowane informacje referencyjne dotyczące rozwiązywania problemów i pomocy technicznej. Nie jest on przeznaczony do planowania wdrożenia. Rozszerzono mechanikę obsługi bezpiecznego rozruchu podsumowaną wcześniej, a także udostępniono szczegółowe materiały referencyjne dotyczące interpretowania dzienników zdarzeń i stanów rejestru.
Uwaga (wdrożenia zarządzane przez dział IT): Po skonfigurowaniu za pośrednictwem zasady grupy lub usługi Microsoft Intune dwóch podobnych ustawień nie należy mylić. Wartość AvailableUpdatesPolicy oznacza skonfigurowany stan zasad. Tymczasem wartość AvailableUpdates odzwierciedla stan pracy w toku, czyszczenia bitów. Oba mogą prowadzić do tego samego wyniku, ale zachowują się inaczej, ponieważ polityka ponownie stosuje się w czasie.
Bity funkcji AvailableUpdates używane do obsługi certyfikatów
Poniższe bity są używane na potrzeby akcji związanych z certyfikatem i menedżerem rozruchu opisanych w tym dokumencie. Kolumna Kolejność odzwierciedla sekwencję, w jakiej zadanie Secure-Boot-Update przetwarza każdy bit.
| Lp | Ustawienie bitowe | Stosowanie |
|---|---|---|
| 1 | 0x0040 | Ten bit informuje zaplanowane zadanie o dodaniu certyfikatu Windows UEFI CA 2023 do bazy danych bezpiecznego rozruchu. Dzięki temu system Windows może ufać menedżerom rozruchu podpisanym za pomocą tego certyfikatu. |
| 2 | 0x0800 | Ten bit informuje zaplanowane zadanie o zastosowaniu Microsoft Option ROM UEFI CA 2023 do bazy danych. Zachowanie warunkowe: Po ustawieniu flagi 0x4000 zaplanowane zadanie najpierw sprawdzi bazę danych pod kątem certyfikatu Microsoft Corporation UEFI CA 2011 . Zastosuje certyfikat Microsoft Option ROM UEFI CA 2023tylko wtedy, gdy certyfikat 2011 jest obecny. |
| 3 | 0x1000 | Ten bit informuje zaplanowane zadanie o konieczności zastosowania interfejsu Microsoft UEFI CA 2023 do bazy danych. Zachowanie warunkowe: Po ustawieniu flagi 0x4000 zaplanowane zadanie najpierw sprawdzi bazę danych pod kątem certyfikatu Microsoft Corporation UEFI CA 2011 . Zastosuje certyfikat Microsoft UEFI CA 2023tylko wtedy, gdy certyfikat 2011 jest obecny. |
| Modyfikator (flaga zachowania) | 0x4000 | Ten bit modyfikuje zachowanie 0x0800 i 0x1000 bitów, dzięki czemu Microsoft UEFI CA 2023 i Microsoft Option ROM UEFI CA 2023 są stosowane tylko wtedy, gdy baza danych zawiera już interfejs Microsoft Corporation UEFI CA 2011. Aby zapewnić, że profil zabezpieczeń urządzenia pozostanie taki sam, ten bit stosuje te nowe certyfikaty tylko wtedy, gdy urządzenie ufa certyfikatowi Microsoft Corporation UEFI CA 2011. Nie wszystkie urządzenia z systemem Windows ufają temu certyfikatowi. |
| 4 | 0x0004 | Ten bit nakazuje zaplanowanemu zadaniu wyszukanie klucza wymiany kluczy podpisanego przez klucz platformy (PK) urządzenia. PK jest zarządzany przez OEM. Producenci OEM podpisują klucz KEK firmy Microsoft za pomocą klucza podstawowego i dostarczają go do firmy Microsoft, gdzie jest uwzględniany w comiesięcznych aktualizacjach zbiorczych. |
| 5 | 0x0100 | Ten bit informuje zaplanowane zadanie o konieczności zastosowania menedżera rozruchu, podpisanego przez Windows UEFI CA 2023, do partycji rozruchowej. Zastąpi on menedżera rozruchu podpisany przez Microsoft Windows Production PCA 2011 . |
Uwagi:
- Bit 0x4000 pozostanie ustawiony po przetworzeniu wszystkich innych bitów.
- Każdy bit jest przetwarzany przez zaplanowane zadanie Secure-Boot-Update w kolejności pokazanej powyżej.
- Jeśli 0x0004 bit nie może być przetworzony z powodu brakującego klucza podstawowego podpisanego KEK, zaplanowane zadanie nadal będzie stosować aktualizację menedżera rozruchu wskazywaną przez bit 0x0100.
Oczekiwany postęp (dostępne_aktualizacje)
Po pomyślnym ukończeniu operacji system Windows czyści skojarzony bit z AvailableUpdates. Jeśli operacja się nie powiedzie, system Windows rejestruje zdarzenie i ponawia próbę po ponownym uruchomieniu zadania.
W poniższej tabeli przedstawiono oczekiwany postęp wartości AvailableUpdates w miarę kończenia każdej akcji aktualizacji bezpiecznego rozruchu.
| Krok | Przetworzono bit | Dostępne aktualizacje | Opis | Zarejestrowano zdarzenie powodzenia | Kody zdarzeń możliwych błędów |
|---|---|---|---|---|---|
| Rozpoczęcie | 0x5944 | Stan początkowy przed rozpoczęciem obsługi certyfikatu bezpiecznego rozruchu. | - | - | |
| 1 | 0x0040 | 0x5944 → 0x5904 | Windows UEFI CA 2023 jest dodawany do bazy danych bezpiecznego rozruchu. | 1036 | 1032, 1795, 1796, 1802 |
| 2 | 0x0800 | 0x5904 → 0x5104 | Dodaj Microsoft Option ROM UEFI CA 2023 do bazy danych, jeśli urządzenie wcześniej ufało interfejsowi Microsoft UEFI CA 2011. | 1044 | 1032, 1795, 1796, 1802 |
| 3 | 0x1000 | 0x5104 → 0x4104 | Interfejs Microsoft UEFI CA 2023 jest dodawany do bazy danych, jeśli urządzenie wcześniej ufało interfejsowi Microsoft UEFI CA 2011. | 1045 | 1032, 1795, 1796, 1802 |
| 4 | 0x0004 | 0x4104 → 0x4100 | Zastosowano nowy klucz Microsoft KEK 2K CA 2023 podpisany kluczem platformy OEM. | 1043 | 1032, 1795, 1796, 1802, 1803 |
| 5 | 0x0100 | 0x4100 → 0x4000 | Zainstalowany jest menedżer rozruchu podpisany przez Windows UEFI CA 2023. | 1799 | 1797 |
Uwagi
- Po pomyślnym zakończeniu operacji skojarzonej z bitem ten bit jest usuwany z listy AvailableUpdates.
- Jeśli jedna z tych operacji zakończy się niepowodzeniem, zdarzenie zostanie zarejestrowane i operacja zostanie ponowiona przy następnym uruchomieniu zaplanowanego zadania.
- Bit 0x4000 jest modyfikatorem i nie jest czyszczony. Ostateczna wartość parametru AvailableUpdates wynosząca 0x4000 wskazuje pomyślne zakończenie wszystkich odpowiednich akcji aktualizacji.
- Zdarzenia 1032, 1795, 1796, 1802 zazwyczaj wskazują ograniczenia oprogramowania układowego lub platformy.
- Zdarzenie 1803 wskazuje na brak klucza KEK podpisanego przez klucz sprzętowy producenta OEM.
Procedury korygujące
Ta sekcja zawiera instrukcje krok po kroku dotyczące rozwiązywania określonych problemów z bezpiecznym rozruchem. Każda procedura jest ściśle określona i ma być stosowana dopiero po potwierdzeniu przez wstępną diagnozę, że problem ma zastosowanie. Poniższe procedury umożliwiają przywrócenie oczekiwanego zachowania bezpiecznego rozruchu i pozwalają na bezpieczne aktualizowanie certyfikatów. Nie należy stosować tych procedur szeroko lub prewencyjnie.
Włączanie bezpiecznego rozruchu w oprogramowaniu układowym
Jeśli funkcja bezpiecznego rozruchu jest wyłączona w oprogramowaniu układowym urządzenia, zobacz temat System Windows 11 i bezpieczny rozruch, aby uzyskać szczegółowe informacje na temat włączania funkcji bezpiecznego rozruchu.
Zaplanowane zadanie bezpiecznego rozruchu jest wyłączone lub usunięte
Zaplanowane zadanie Secure-Boot-Update jest wymagane, aby system Windows mógł zastosować aktualizacje certyfikatu bezpiecznego rozruchu. Jeśli zadanie jest wyłączone lub go brakuje, obsługa certyfikatów bezpiecznego rozruchu nie będzie postępować.
Szczegóły zadania
| Nazwa zadania | Aktualizacja bezpiecznego rozruchu |
|---|---|
| Ścieżka zadania | \Microsoft\Windows\PI\ |
| Pełna ścieżka | \Microsoft\Windows\PI\Secure-Boot-Update |
| Działa jako | SYSTEM (System lokalny) |
| Wyzwalacze | Przy uruchomieniu i co 12 godzin |
| Stan wymagany | Włączone |
Jak sprawdzić stan zadania
Uruchom z wiersza polecenia programu PowerShell z podwyższonym poziomem uprawnień:
schtasks.exe /query /TN "\Microsoft\Windows\PI\Secure-boot-Update" /FO LIST /V
Poszukaj pola Stan :
| Stan | Znaczenie |
|---|---|
| Gotowe | Zadanie istnieje i jest włączone. |
| Disabled | Zadanie istnieje, ale musi być włączone. |
| Błąd / Nie znaleziono | Brakuje zadania i należy je utworzyć ponownie. |
Jak włączyć lub ponownie utworzyć zadanie
Jeśli pole stanu aktualizacji bezpiecznego rozruchu to Wyłączone, Błąd lub Nie znaleziono, użyj przykładowego skryptu, aby włączyć zadanie: Przykładowy Enable-SecureBootUpdateTask.ps1
Uwaga: to jest przykładowy skrypt, który nie jest obsługiwany przez firmę Microsoft. Administratorzy powinni go przejrzeć i dostosować do swojego środowiska.
Przykład:
Uwaga
.\Enable-SecureBootUpdateTask.ps1 -cichy
Wskazówki dotyczące uruchamiania
- Jeśli zobaczysz komunikat Odmowa dostępu, uruchom ponownie program PowerShell jako administrator.
- Jeśli skrypt nie zostanie uruchomiony z powodu zasad wykonywania, użyj obejścia zakresu procesu:
Uwaga
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass