Rozwiązywanie problemów

Jeśli aktualizacje bezpiecznego rozruchu nie wykazują postępu, zazwyczaj oznacza to, że proces aktualizacji nigdy się nie rozpoczął. W związku z tym brakuje oczekiwanych wartości rejestru bezpiecznego rozruchu i dzienników zdarzeń, ponieważ mechanizm aktualizacji nigdy nie został wyzwolony.

Co się stało

Proces aktualizacji bezpiecznego rozruchu nie został uruchomiony, więc na urządzeniu nie zastosowano żadnych certyfikatów bezpiecznego rozruchu ani zaktualizowanego menedżera rozruchu.

Jak ją rozpoznać

• Nie są dostępne żadne wartości rejestru obsługi bezpiecznego rozruchu, takie jak uefica2023Status.

• W dzienniku zdarzeń systemowych brakuje oczekiwanych zdarzeń bezpiecznego rozruchu (na przykład 1043, 1044, 1045, 1799 i 1801).

• Urządzenie nadal używa starszych certyfikatów bezpiecznego rozruchu i składników rozruchu.

Dlaczego tak się dzieje

Ten scenariusz występuje zazwyczaj, gdy spełniony jest co najmniej jeden z następujących warunków:

• Zaplanowane zadanie Secure-Boot-Update jest wyłączone lub 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 uruchomienie obsługiwanej wersji systemu Windows lub zainstalowanie wymaganych aktualizacji.

Co zrobić dalej

• Sprawdź, czy urządzenie spełnia wymagania dotyczące obsługi systemu Windows i uprawnień do platformy.

• Upewnij się, że w oprogramowaniu układowym włączono bezpieczny rozruch.

• Upewnij się, że zaplanowane zadanie SecureBootUpdate istnieje i jest włączone.

Jeśli zaplanowane zadanie jest wyłączone lub nie ma go, postępuj zgodnie ze wskazówkami zawartymi w artykule Bezpieczny rozruch zaplanowane zadanie jest wyłączone lub usunięte , aby je przywrócić. Po przywróceniu zadania uruchom ponownie urządzenie lub uruchom je ręcznie, aby zainicjować obsługę bezpiecznego rozruchu.

W niektórych przypadkach aktualizacje związane z bezpiecznym rozruchem mogą spowodować, że urządzenie wprowadzi funkcję odzyskiwania funkcji BitLocker. Zachowanie może być przejściowe lub trwałe, w zależności od przyczyny źródłowej.

Scenariusz 1: Jednorazowe odzyskiwanie funkcji BitLocker po aktualizacji bezpiecznego rozruchu

Co się dzieje

Urządzenie przechodzi do odzyskiwania funkcji BitLocker podczas pierwszego rozruchu po aktualizacji bezpiecznego rozruchu, ale uruchamia się normalnie po 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 uruchomić funkcję BitLocker. Powoduje to tymczasowe niedopasowanie wartości mierzonego rozruchu i wyzwala odzyskiwanie. Podczas następnego rozruchu oprogramowanie układowe prawidłowo zgłasza zaktualizowane wartości, funkcja BitLocker pomyślnie zapisuje ponownie, a problem nie występuje ponownie.

Jak ją rozpoznać

• Odzyskiwanie funkcji BitLocker występuje raz.

• Po wprowadzeniu klucza odzyskiwania kolejne buty nie monitują o odzyskanie.

• Nie ma bieżącego zlecenia rozruchu ani zaangażowania środowiska PXE.

Co 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 pierwszej konfiguracji rozruchu PXE

Co się dzieje

Urządzenie przechodzi do odzyskiwania funkcji BitLocker przy każdym rozruchu.

Dlaczego tak się dzieje

Urządzenie jest skonfigurowane do próby rozruchu PXE (sieciowego). Próba rozruchu PXE kończy się niepowodzeniem, a następnie oprogramowanie układowe wraca do menedżera rozruchu systemu Windows na dysku.

W wyniku tego podczas jednego cyklu rozruchu mierzone są dwa różne organy podpisywania:

• Ścieżka rozruchu środowiska PXE jest podpisana przez 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 zabezpieczenia. W wyniku tego funkcja BitLocker wprowadza odzyskiwanie przy każdym rozruchu.

Jak ją rozpoznać

• Odzyskiwanie funkcji BitLocker jest wyzwalane przy każdym ponownym uruchomieniu.

• Wprowadzenie klucza odzyskiwania umożliwia uruchomienie systemu Windows, ale monit wraca do następnego rozruchu.

• Środowisko PXE lub rozruch sieciowy jest skonfigurowany przed dyskami lokalnymi w kolejności rozruchu oprogramowania układowego.

Co zrobić dalej

• Skonfiguruj kolejność rozruchu oprogramowania układowego, aby najpierw był menedżer rozruchu systemu Windows na dysku.

• Wyłącz rozruch środowiska PXE, jeśli nie jest wymagany.

• Jeśli jest wymagane środowisko PXE, upewnij się, że infrastruktura środowiska PXE używa modułu ładującego rozruchu systemu Windows z podpisem 2023.

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 ją rozpoznać

• Na urządzeniu nie można uruchomić systemu Windows i może zostać wyświetlony komunikat oprogramowania układowego lub systemu BIOS wskazujący na naruszenie zasad bezpiecznego rozruchu.

• Błąd występuje po zresetowaniu ustawień bezpiecznego rozruchu do ustawień oprogramowania układowego.

• Wyłączenie bezpiecznego rozruchu może umożliwić ponowne uruchomienie urządzenia.

Dlaczego tak się dzieje

Zresetowanie bezpiecznego rozruchu do stanu domyślnego powoduje wyczyszczenie baz danych bezpiecznego rozruchu przechowywanych w oprogramowaniu układowym. Na urządzeniach, które już przeszły do menedżera rozruchu z podpisem interfejsu UEFI systemu Windows 2023, to zresetowanie usuwa certyfikaty wymagane do zaufania temu menedżerowi rozruchu.

W związku z tym oprogramowanie układowe nie rozpoznaje już zainstalowanego Menedżera rozruchu systemu Windows jako zaufanego i blokuje proces rozruchu.

Ten scenariusz nie jest spowodowany przez samą aktualizację bezpiecznego rozruchu, ale przez kolejne działanie oprogramowania układowego, które usuwa zaktualizowane kotwice zaufania.

Co zrobić dalej

• Użyj narzędzia odzyskiwania bezpiecznego rozruchu, aby przywrócić wymagany certyfikat, aby urządzenie było możliwe do ponownego rozruchu.

• Po odzyskaniu upewnij się, że urządzenie ma zainstalowane najnowsze dostępne oprogramowanie układowe od producenta urządzenia.

• Unikaj resetowania ustawień bezpiecznego rozruchu do stanu domyślnego oprogramowania układowego, chyba że oprogramowanie układowe producenta OEM zawiera zaktualizowane ustawienia domyślne bezpiecznego rozruchu, które są zaufane certyfikatom z wersji 2023.

Narzędzie odzyskiwania bezpiecznego rozruchu

Aby odzyskać system:

1. Na drugim komputerze z systemem Windows z zainstalowaną aktualizacją z lipca 2024 r. lub nowszą aktualizacją systemu Windows skopiuj plik SecureBootRecovery.efi z folderu C:\Windows\Boot\EFI\.

2. Umieść plik na dysku USB w formacie FAT32 w obszarze \EFI\BOOT\ i zmień jego nazwę na bootx64.efi.

3. Uruchom urządzenie, którego dotyczy problem, z dysku USB i zezwól na uruchomienie narzędzia odzyskiwania. Narzędzie doda interfejs UEFI SYSTEMU Windows CA 2023 do bazy danych.

Po przywróceniu certyfikatu i ponownym uruchomieniu systemu system Windows powinien uruchomić się normalnie.

Ważne: Ten proces spowoduje ponowne zastosowanie tylko jednego z nowych certyfikatów. Po odzyskaniu urządzenia upewnij się, że ma ono ponownie zainstalowane najnowsze certyfikaty, i rozważ zaktualizowanie systemu BIOS/UEFI do najnowszej dostępnej wersji. Może to pomóc zapobiec ponownemu wystąpieniu problemu z zresetowaniem bezpiecznego rozruchu, ponieważ wielu producentach OEM wydało poprawki oprogramowania układowego dla tego konkretnego problemu.

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 ją rozpoznać

• Urządzenie kończy się niepowodzeniem 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 zatrzymać się przed załadowaniem systemu Windows.

• Wyłączenie bezpiecznego rozruchu może umożliwić rozruch urządzenia.

Dlaczego tak się dzieje

Ten problem może być spowodowany przez wadę implementacji oprogramowania układowego UEFI urządzenia.

Gdy system Windows zastosuje aktualizacje certyfikatu bezpiecznego rozruchu, oprogramowanie układowe powinno dołączyć nowe certyfikaty do istniejącej bazy danych z dozwolonym podpisem bezpiecznego rozruchu (DB). Niektóre implementacje oprogramowania układowego nieprawidłowo zastępują DB zamiast dołączać do niego.

W takim przypadku

• Wcześniej zaufane certyfikaty, w tym certyfikat bootloadera firmy Microsoft 2011, są usuwane.

• Jeśli system nadal używa menedżera rozruchu podpisanego certyfikatem 2011 w tym momencie, oprogramowanie układowe nie jest już zaufane.

• Oprogramowanie układowe odrzuca menedżera rozruchu i blokuje proces rozruchu.

W niektórych przypadkach baza danych może również ulec uszkodzeniu, a nie czysto zastąpić, co prowadzi do takiego samego wyniku. To zachowanie zaobserwowano w przypadku określonych implementacji oprogramowania układowego i nie jest oczekiwane w przypadku zgodnego oprogramowania układowego.

Co zrobić dalej

• Wprowadź menu konfiguracji oprogramowania układowego i spróbuj zresetować ustawienia bezpiecznego rozruchu.

• Jeśli urządzenie zostanie uruchomione po zresetowaniu, poszukaj w witrynie pomocy technicznej producenta urządzenia aktualizacji oprogramowania układowego, która poprawia obsługę bazy danych bezpiecznego rozruchu.

• Jeśli jest dostępna aktualizacja oprogramowania układowego, zainstaluj ją przed ponownym włączeniem bezpiecznego rozruchu i ponowne zastosowanie aktualizacji certyfikatu bezpiecznego rozruchu.

Jeśli zresetowanie bezpiecznego rozruchu nie przywróci funkcji rozruchu, dalsze odzyskiwanie prawdopodobnie wymaga wskazówek specyficznych dla 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 ją rozpoznać

• Wartość rejestru AvailableUpdates pozostaje ustawiona na bit KEK (0x0004) i nie jest czyszczona.

• Interfejs UEFICA2023Status nie jest w stanie ukończonym.

• Dziennik zdarzeń systemowych wielokrotnie rejestruje identyfikator zdarzenia 1803, co oznacza, że nie można zastosować aktualizacji KEK.

• Urządzenie będzie nadal ponawiać próbę aktualizacji bez postępów.

Dlaczego tak się dzieje

Aktualizacja klucza KEK bezpiecznego rozruchu wymaga autoryzacji z klucza platformy (PK) urządzenia, który jest własnością producenta OEM.

Aby aktualizacja powiodła się, producent urządzenia musi dostarczyć firmie Microsoft KEK z podpisem PK dla tej konkretnej platformy. Ten KEK podpisany przez producenta OEM jest dołączony do aktualizacji systemu Windows i umożliwia systemowi Windows aktualizowanie zmiennej KEK oprogramowania układowego.

Jeśli OEM nie dostarczył KEK z podpisem KEK dla urządzenia, system Windows nie może ukończyć aktualizacji KEK. W tym stanie:

• Aktualizacje bezpiecznego rozruchu są blokowane z założenia.

• System Windows nie może obejść braku autoryzacji.

• Urządzenie może trwale nie być w stanie ukończyć obsługi certyfikatu bezpiecznego rozruchu.

Może się tak zdarzyć na starszych lub nieobsłużanych urządzeniach, na których OEM nie udostępnia już aktualizacji oprogramowania układowego ani kluczowych. Dla tego warunku nie ma obsługiwanej ścieżki odzyskiwania ręcznego.

powrót do początku

Gdy nie można zastosować aktualizacji certyfikatu bezpiecznego rozruchu, system Windows rejestruje zdarzenia diagnostyczne wyjaśniające przyczynę zablokowania postępu. Te zdarzenia są zapisywane podczas aktualizowania bazy danych podpisu bezpiecznego rozruchu (DB) lub klucza KEK (Key Exchange Key) nie mogą zostać bezpiecznie ukończone ze względu na stan oprogramowania układowego, stan platformy lub warunki konfiguracji. Scenariusze w tej sekcji odwołują się do tych zdarzeń w celu zidentyfikowania typowych wzorców błędów i określenia odpowiedniego rozwiązania. Ta sekcja ma na celu wsparcie diagnostyki i interpretacji opisanych wcześniej problemów, a nie wprowadzenie nowych scenariuszy niepowodzeń.

Aby uzyskać pełną listę identyfikatorów zdarzeń, opisów i przykładowych wpisów, zobacz Zdarzenia aktualizacji zmiennych DB i DBX dotyczące bezpiecznego rozruchu (KB5016061).

Niepowodzenie aktualizacji KEK (aktualizacje bazy danych powiodły się, KEK nie)

Urządzenie może pomyślnie zaktualizować certyfikaty w bazie danych bezpiecznego rozruchu, ale kończy się niepowodzeniem podczas aktualizacji KEK. W takim przypadku nie można ukończyć procesu aktualizacji bezpiecznego rozruchu.

Oznaki

• Zdarzenia certyfikatu bazy danych wskazują postęp, ale etap KEK nie jest ukończony.

• Funkcja AvailableUpdates pozostaje ustawiona na wartość 0x4004, a 0x0004 bit nie jest czyszczony po wielu uruchomieniach zadań.

• Zdarzenie 1795 lub 1803 może być obecne.

Interpretacji

• System 1795 zazwyczaj wskazuje na błąd oprogramowania układowego podczas próby zaktualizowania 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 systemie 1795 sprawdź dostępność aktualizacji oprogramowania układowego OEM i sprawdź, czy są dostępne aktualizacje zmiennych bezpiecznego rozruchu.

• W systemie 1803 potwierdź, czy OEM dostarczył firmie Microsoft KEK podpisane przez PK wymagane dla modelu urządzenia.

Błąd aktualizacji KEK na maszynach wirtualnych gości hostowanych w funkcji Hyper-V 

Na maszynach wirtualnych Hyper-V aktualizacje certyfikatu bezpiecznego rozruchu wymagają zainstalowania aktualizacji systemu Windows z marca 2026 r. zarówno na hostze Hyper-V, jak i na systemie operacyjnym gościa.

Błędy aktualizacji są zgłaszane z poziomu gościa, ale zdarzenie wskazuje, gdzie wymagane jest rozwiązywanie problemów:

• Zdarzenie 1795 (na przykład "Multimedia są chronione zapisem") zgłoszone przez gościa wskazuje, że host Hyper-V nie ma aktualizacji z marca 2026 r. i musi zostać zaktualizowany.

• Zdarzenie 1803 zgłoszone w gościu wskazuje, że na maszynie wirtualnej gościa brakuje aktualizacji z marca 2026 r. i musi zostać zaktualizowana.