Problembehandlung
Gilt für
Ursprüngliches Veröffentlichungsdatum: 19. März 2026
KB-ID: 5085046
In diesem Artikel
Übersicht
Auf dieser Seite werden Administratoren und Supportexperten bei der Diagnose und Behebung von Problemen im Zusammenhang mit sicherem Start auf Windows-Geräten geführt. Zu den Themen gehören Fehler beim Aktualisieren von Zertifikaten für den sicheren Start, falsche Zustände für den sicheren Start, unerwartete BitLocker-Wiederherstellungsaufforderungen und Startfehler nach Konfigurationsänderungen für den sicheren Start.
In diesem Leitfaden wird erläutert, wie Sie die Windows-Wartung und -Konfiguration überprüfen, relevante Registrierungswerte und Ereignisprotokolle überprüfen und ermitteln, wann Firmware- oder Plattformbeschränkungen ein OEM-Update erfordern. Dieser Inhalt dient zur Diagnose von Problemen auf vorhandenen Geräten. Es ist nicht für die Planung neuer Bereitstellungen vorgesehen. Dieses Dokument wird aktualisiert, wenn neue Problembehandlungsszenarien und Anleitungen identifiziert werden.
Funktionsweise der Zertifikatwartung für den sicheren Start
Die Zertifikatwartung für den sicheren Start unter Windows ist ein koordinierter Prozess zwischen dem Betriebssystem und der UEFI-Firmware eines Geräts. Das Ziel besteht darin, kritische Vertrauensanker zu aktualisieren und gleichzeitig die Fähigkeit zum Starten in jeder Phase zu erhalten.
Der Prozess wird durch eine geplante Windows-Aufgabe, eine registrierungsbasierte Sequenz von Updateaktionen und integriertes Protokollierungs- und Wiederholungsverhalten gesteuert. Zusammen stellen diese Komponenten sicher, dass Zertifikate für den sicheren Start und der Windows-Start-Manager auf kontrollierte, geordnete Weise aktualisiert werden und erst nach erfolgreichen erforderlichen Schritten ausgeführt werden.
Wo sie bei der Problembehandlung beginnen
Wenn ein Gerät anscheinend keinen erwarteten Fortschritt bei der Anwendung von Zertifikatupdates für den sicheren Start erzielt, identifizieren Sie zunächst die Kategorie des Problems. Die meisten Probleme fallen in einen von vier Bereichen: Windows-Wartungsstatus, den Mechanismus für das Update für den sicheren Start, das Firmwareverhalten oder eine Plattform- oder OEM-Einschränkung.
Beginnen Sie mit den folgenden Überprüfungen in der richtigen Reihenfolge. In vielen Fällen reichen diese Schritte aus, um das beobachtete Verhalten zu erklären und die nächsten Aktionen ohne eingehendere Untersuchung zu bestimmen.
-
Bestätigen der Windows-Wartung und Plattformberechtigung
-
Stellen Sie sicher, dass das Gerät die grundlegenden Anforderungen für den Empfang von Zertifikatupdates für den sicheren Start erfüllt:
-
Auf dem Gerät wird eine unterstützte Version von Windows ausgeführt.
-
Die neuesten erforderlichen Windows-Sicherheitsupdates werden installiert.
-
Sicherer Start ist in der UEFI-Firmware aktiviert.
-
Wenn eine dieser Bedingungen nicht erfüllt ist, beheben Sie sie, bevor Sie mit der weiteren Problembehandlung fortfahren.
-
-
Überprüfen sie den Task "Secure-Boot-Update", status
-
Vergewissern Sie sich, dass der Windows-Mechanismus, der für die Anwendung von Zertifikatupdates für den sicheren Start zuständig ist, vorhanden ist und funktioniert:
-
Der geplante Task Secure-Boot-Update ist vorhanden.
-
Die Aufgabe ist aktiviert und wird als lokales System ausgeführt.
-
Der Task wurde seit der Installation des letzten Windows-Sicherheitsupdates mindestens einmal ausgeführt.
-
Wenn die Aufgabe deaktiviert, gelöscht oder nicht ausgeführt wird, können Zertifikatupdates für den sicheren Start nicht angewendet werden. Die Problembehandlung sollte sich auf die Wiederherstellung der Aufgabe konzentrieren, bevor andere Ursachen untersucht werden.
-
-
Überprüfen der Registrierungseinstellungen auf den erwarteten Fortschritt
Überprüfen Sie den Wartungsstatus für den sicheren Start des Geräts in der Registrierung:
-
Untersuchen Sie UEFICA2023Status, UEFICA2023Error und UEFICA2023ErrorEvent.
-
Untersuchen Sie AvailableUpdates , und vergleichen Sie es mit dem erwarteten Fortschritt (siehe Referenz und Internements).
Zusammen geben diese Werte an, ob die Wartung normal verläuft, einen Vorgang wiederholt oder in einem bestimmten Schritt angehalten wurde.
-
-
Korrelieren des Registrierungsstatus mit Ereignissen für den sicheren Start
Überprüfen Sie Ereignisse im Zusammenhang mit sicherem Start im Systemereignisprotokoll, und korrelieren Sie sie mit dem Registrierungsstatus. Ereignisdaten bestätigen in der Regel, ob das Gerät fortschritte macht, aufgrund einer vorübergehenden Bedingung erneut versucht oder durch ein Firmware- oder Plattformproblem blockiert wird.
Zusammen geben die Registrierungs- und Ereignisprotokolle in der Regel an, ob das Verhalten erwartet, temporär ist oder Korrekturmaßnahmen erforderlich sind.
Geplante Aufgabe "Secure-Boot-Update"
Die Zertifikatwartung für den sicheren Start wird über eine geplante Windows-Aufgabe namens Secure-Boot-Update implementiert. Die Aufgabe wird unter dem folgenden Pfad registriert:
\Microsoft\Windows\PI\Secure-Boot-Update
Der Task wird als lokales System ausgeführt. Standardmäßig wird sie beim Systemstart und danach alle 12 Stunden ausgeführt. Bei jeder Ausführung wird überprüft, ob Aktualisierungsaktionen für den sicheren Start ausstehen, und versucht, sie nacheinander anzuwenden.
Wenn diese Aufgabe deaktiviert ist oder fehlt, können Zertifikatupdates für den sicheren Start nicht angewendet werden. Der Task "Secure-Boot-Update" muss aktiviert bleiben, damit die Wartung für den sicheren Start funktioniert.
Gründe für die Verwendung eines geplanten Vorgangs
Zertifikatupdates für den sicheren Start erfordern eine Koordination zwischen Windows und UEFI-Firmware, einschließlich des Schreibens von UEFI-Variablen, die Schlüssel und Zertifikate für den sicheren Start speichern. Eine geplante Aufgabe ermöglicht Es Windows, diese Updates zu versuchen, wenn sich das System in einem Zustand befindet, in dem Firmwarevariablen geändert werden können.
Der wiederkehrende 12-Stunden-Zeitplan bietet zusätzliche Möglichkeiten zum Wiederholen von Updates, wenn ein vorheriger Versuch fehlgeschlagen ist oder wenn das Gerät eingeschaltet bleibt, ohne neu zu starten. Dieser Entwurf trägt dazu bei, den Fortschritt zu gewährleisten, ohne dass ein manueller Eingriff erforderlich ist.
Die AvailableUpdates-Registrierungsbitmaske
Der Task Secure-Boot-Update wird vom Registrierungswert AvailableUpdates gesteuert. Dieser Wert ist eine 32-Bit-Bitmaske, die sich unter befindet:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Jedes Bit im -Wert stellt eine bestimmte Updateaktion für den sicheren Start dar. Der Updatevorgang beginnt, wenn AvailableUpdates auf einen Wert ungleich 0 festgelegt wird, entweder automatisch von Windows oder explizit von einem Administrator. Beispielsweise gibt ein Wert wie 0x5944 an, dass mehrere Aktualisierungsaktionen ausstehen.
Wenn der Task Secure-Boot-Update ausgeführt wird, interpretiert er die festgelegten Bits als ausstehende Arbeit und verarbeitet sie in einer definierten Reihenfolge.
Sequenzielle Updates, Protokollierung und Wiederholungsverhalten
Zertifikatupdates für den sicheren Start werden in einer festen Reihenfolge angewendet. Jede Aktualisierungsaktion ist so konzipiert, dass sie sicher wiederholt werden kann und unabhängig abgeschlossen wird. Der Task Secure-Boot-Update wechselt erst zum nächsten Schritt, wenn die aktuelle Aktion erfolgreich ist und das entsprechende Bit aus AvailableUpdates gelöscht wird.
Jeder Vorgang verwendet UEFI-Standardschnittstellen, um Sichere Startvariablen wie db und KEK zu aktualisieren oder den aktualisierten Windows-Start-Manager zu installieren. Windows zeichnet das Ergebnis jedes Schritts im Systemereignisprotokoll auf. Erfolgsereignisse bestätigen den Vorwärtsfortschritt, während Fehlerereignisse angeben, warum eine Aktion nicht abgeschlossen werden konnte.
Wenn bei einem Aktualisierungsschritt ein Fehler auftritt, beendet die Aufgabe die Verarbeitung, protokolliert den Fehler und lässt das zugeordnete Bit festgelegt. Der Vorgang wird bei der nächsten Ausführung der Aufgabe wiederholt. Dieses Wiederholungsverhalten ermöglicht es Geräten, sich automatisch nach temporären Bedingungen wie fehlender Firmwareunterstützung oder verzögerten OEM-Updates wiederherzustellen.
Administratoren können den Fortschritt nachverfolgen, indem sie den Registrierungsstatus mit Ereignisprotokolleinträgen korrelieren. Registrierungswerte wie UEFICA2023Status, UEFICA2023Error und UEFICA2023ErrorEvent geben zusammen mit der Bitmaske AvailableUpdates an, welcher Schritt aktiv, abgeschlossen oder blockiert ist.
Diese Kombination zeigt an, ob das Gerät normal ausgeführt wird, einen Vorgang wiederholt oder angehalten wird.
Integration in OEM-Firmware
Zertifikatupdates für den sicheren Start hängen vom richtigen Verhalten und der Unterstützung in der UEFI-Firmware eines Geräts ab. Während Windows den Updateprozess orchestriert, ist die Firmware für das Erzwingen der Richtlinie für den sicheren Start und die Wartung der Datenbanken für den sicheren Start verantwortlich.
OEMs stellen zwei wichtige Elemente bereit, die die Zertifikatwartung für den sicheren Start ermöglichen:
-
Vom Plattformschlüssel signierte Schlüsselaustauschschlüssel (Key Exchange Keys, KEKs), die die Installation neuer Zertifikate für den sicheren Start autorisieren.
-
Firmwareimplementierungen, die sichere Startdatenbanken während Updates ordnungsgemäß beibehalten, anfügen und überprüfen.
Wenn die Firmware dieses Verhalten nicht vollständig unterstützt, können Updates für den sicheren Start angehalten, auf unbestimmte Zeit wiederholt werden oder zu Startfehlern führen. In diesen Fällen kann Windows das Update nicht ohne Änderungen an der Firmware abschließen.
Microsoft arbeitet mit OEMs zusammen, um Firmwareprobleme zu identifizieren und korrigierte Updates verfügbar zu machen. Wenn die Problembehandlung auf eine Firmwareeinschränkung oder einen Fehler hinweist, müssen Administratoren möglicherweise das neueste UEFI-Firmwareupdate installieren, das vom Gerätehersteller bereitgestellt wird, bevor die Zertifikatupdates für den sicheren Start erfolgreich abgeschlossen werden können.
Häufige Fehlerszenarien und Lösungen
Updates für den sicheren Start werden vom geplanten Task Secure-Boot-Update basierend auf dem Registrierungsstatus AvailableUpdates angewendet.
Unter normalen Bedingungen treten diese Schritte automatisch auf und zeichnen Erfolgsereignisse auf, wenn die einzelnen Phasen abgeschlossen werden. In einigen Fällen können Firmwareverhalten, Plattformkonfiguration oder Wartungsvoraussetzungen den Fortschritt verhindern oder zu unerwartetem Startverhalten führen.
In den folgenden Abschnitten werden die häufigsten Fehlerszenarien beschrieben, wie sie erkannt werden, warum sie auftreten, und die entsprechenden nächsten Schritte zum Wiederherstellen des normalen Betriebs. Szenarien werden von den am häufigsten auftretenden bis hin zu schwerwiegenderen Boot-Beeinträchtigungsfällen sortiert.
Wenn updates für den sicheren Start keinen Fortschritt anzeigen, bedeutet dies in der Regel, dass der Updatevorgang nie gestartet wurde. Daher fehlen die erwarteten Registrierungswerte für den sicheren Start und die Ereignisprotokolle, da der Updatemechanismus nie ausgelöst wurde.
Was ist passiert
Der Updateprozess für den sicheren Start wurde nicht gestartet, sodass keine Zertifikate für den sicheren Start oder den aktualisierten Start-Manager auf das Gerät angewendet wurden.
So erkennen Sie es
-
Es sind keine Registrierungswerte für die Sichere Startwartung vorhanden, z. B. UEFICA2023Status.
-
Erwartete Ereignisse für den sicheren Start (z. B. 1043, 1044, 1045, 1799, 1801) fehlen im System-Ereignisprotokoll.
-
Das Gerät verwendet weiterhin ältere Zertifikate für den sicheren Start und Startkomponenten.
Warum dies geschieht
Dieses Szenario tritt in der Regel auf, wenn mindestens eine der folgenden Bedingungen zutrifft:
-
Die geplante Aufgabe Secure-Boot-Update ist deaktiviert oder fehlt.
-
Sicherer Start ist in der UEFI-Firmware deaktiviert.
-
Das Gerät erfüllt nicht die Voraussetzungen für die Windows-Wartung, z. B. das Ausführen einer unterstützten Windows-Version oder die Installation erforderlicher Updates.
Was ist als Nächstes zu tun?
-
Stellen Sie sicher, dass das Gerät die Windows-Wartungs- und Plattformberechtigungsanforderungen erfüllt.
-
Vergewissern Sie sich, dass der sichere Start in der Firmware aktiviert ist.
-
Stellen Sie sicher, dass die geplante Aufgabe SecureBootUpdate vorhanden und aktiviert ist.
Wenn die geplante Aufgabe deaktiviert ist oder fehlt, befolgen Sie die Anleitung unter Geplante Aufgabe für den sicheren Start deaktiviert oder gelöscht , um ihn wiederherzustellen. Nachdem die Aufgabe wiederhergestellt wurde, starten Sie das Gerät neu, oder führen Sie die Aufgabe manuell aus, um die Wartung für den sicheren Start zu initiieren.
In einigen Fällen können Updates im Zusammenhang mit dem sicheren Start dazu führen, dass ein Gerät in die BitLocker-Wiederherstellung wechselt. Das Verhalten kann je nach zugrunde liegender Ursache vorübergehend oder dauerhaft sein.
Szenario 1: Einmalige BitLocker-Wiederherstellung nach dem Update für den sicheren Start
Was ist los
Das Gerät wechselt beim ersten Start nach dem Update für den sicheren Start in die BitLocker-Wiederherstellung, startet aber bei nachfolgenden Neustarts normal.
Warum dies geschieht
Beim ersten Start nach dem Update meldet die Firmware die aktualisierten Werte für den sicheren Start noch nicht, wenn Windows versucht, BitLocker erneut zu versiegeln. Dies führt zu einem temporären Konflikt bei den gemessenen Startwerten und löst die Wiederherstellung aus. Beim nächsten Start meldet die Firmware die aktualisierten Werte ordnungsgemäß, BitLocker wird erfolgreich erneut verwendet, und das Problem tritt nicht erneut auf.
So erkennen Sie es
-
Die BitLocker-Wiederherstellung erfolgt einmal.
-
Nach der Eingabe des Wiederherstellungsschlüssels werden nachfolgende Neustarts nicht zur Wiederherstellung aufgefordert.
-
Es ist keine laufende Startreihenfolge oder PXE-Beteiligung vorhanden.
Was ist als Nächstes zu tun?
-
Geben Sie den BitLocker-Wiederherstellungsschlüssel ein, um Windows fortzusetzen.
-
Suchen Sie nach Firmwareupdates.
Szenario 2: Wiederholte BitLocker-Wiederherstellung aufgrund der pxe-Startkonfiguration
Was ist los
Das Gerät wechselt bei jedem Start zur BitLocker-Wiederherstellung.
Warum dies geschieht
Das Gerät ist so konfiguriert, dass zuerst versucht wird , PXE (Netzwerk) zu starten. Der PXE-Startversuch schlägt fehl, und die Firmware greift dann auf den Windows-Start-Manager auf dem Datenträger zurück.
Dies führt dazu, dass zwei verschiedene Signaturstellen während eines einzelnen Startzyklus gemessen werden:
-
Der PXE-Startpfad wird von der Microsoft UEFI CA 2011 signiert.
-
Der Windows-Start-Manager auf dem Datenträger wird von der Windows UEFI CA 2023 signiert.
Da BitLocker während des Startvorgangs unterschiedliche Vertrauensketten für den sicheren Start beobachtet, kann kein stabiler Satz von TPM-Messungen eingerichtet werden, für die ein erneutes Versiegeln durchgeführt werden soll. Daher wechselt BitLocker bei jedem Start in die Wiederherstellung.
So erkennen Sie es
-
Die BitLocker-Wiederherstellung wird bei jedem Neustart ausgelöst.
-
Wenn Sie den Wiederherstellungsschlüssel eingeben, kann Windows gestartet werden, aber die Eingabeaufforderung wird beim nächsten Start zurückgegeben.
-
PXE oder Netzwerkstart wird vor dem lokalen Datenträger in der Firmwarestartreihenfolge konfiguriert.
Was ist als Nächstes zu tun?
-
Konfigurieren Sie die Startreihenfolge der Firmware, sodass der Windows-Start-Manager auf dem Datenträger an erster Stelle steht.
-
Deaktivieren Sie den PXE-Start, wenn dies nicht erforderlich ist.
-
Wenn PXE erforderlich ist, stellen Sie sicher, dass die PXE-Infrastruktur ein 2023-signiertes Windows-Startladeprogramm verwendet.
Was ist passiert
Dies spiegelt eine Änderung der Firmwareebene statt eines Windows-Problems wider. Das Update für den sicheren Start wurde erfolgreich abgeschlossen, aber nach einem späteren Neustart startet das Gerät nicht mehr in Windows.
So erkennen Sie es
-
Das Gerät kann Windows nicht starten und zeigt möglicherweise eine Firmware- oder BIOS-Meldung an, die auf einen Verstoß gegen den sicheren Start hinweist.
-
Der Fehler tritt auf , nachdem die Einstellungen für den sicheren Start auf die Firmwarestandards zurückgesetzt wurden.
-
Wenn Sie den sicheren Start deaktivieren, kann das Gerät möglicherweise erneut gestartet werden.
Warum dies geschieht
Durch das Zurücksetzen des sicheren Starts auf Firmwarestandardeinstellungen werden die in der Firmware gespeicherten Datenbanken für den sicheren Start gelöscht. Auf Geräten, die bereits auf den Windows UEFI CA 2023-signierten Start-Manager umgestellt wurden, werden durch diese Zurücksetzung die Zertifikate entfernt, die erforderlich sind, um diesem Start-Manager zu vertrauen.
Daher erkennt die Firmware den installierten Windows-Start-Manager nicht mehr als vertrauenswürdig und blockiert den Startvorgang.
Dieses Szenario wird nicht durch das Update für den sicheren Start selbst verursacht, sondern durch eine nachfolgende Firmwareaktion, die die aktualisierten Vertrauensanker entfernt.
Was ist als Nächstes zu tun?
-
Verwenden Sie das Wiederherstellungsprogramm für den sicheren Start, um das erforderliche Zertifikat wiederherzustellen, damit das Gerät erneut gestartet werden kann.
-
Stellen Sie nach der Wiederherstellung sicher, dass auf dem Gerät die neueste verfügbare Firmware des Geräteherstellers installiert ist.
-
Vermeiden Sie das Zurücksetzen des sicheren Starts auf Firmwarestandardeinstellungen, es sei denn, die OEM-Firmware enthält aktualisierte Standardeinstellungen für den sicheren Start, die den 2023-Zertifikaten vertrauen.
Wiederherstellungsprogramm für den sicheren Start
So stellen Sie das System wieder her:
-
Kopieren Sie auf einem zweiten Windows-PC, auf dem das Windows-Update vom Juli 2024 oder höher installiert ist, SecureBootRecovery.efi aus C:\Windows\Boot\EFI\.
-
Platzieren Sie die Datei auf einem FAT32-formatierten USB-Laufwerk unter \EFI\BOOT\, und benennen Sie sie in bootx64.efi um.
-
Starten Sie das betroffene Gerät vom USB-Laufwerk, und lassen Sie die Ausführung des Wiederherstellungsprogramms zu. Das Hilfsprogramm fügt der Datenbank die Windows UEFI CA 2023 hinzu.
Nachdem das Zertifikat wiederhergestellt und das System neu gestartet wurde, sollte Windows normal gestartet werden.
Wichtig: Bei diesem Prozess wird nur eines der neuen Zertifikate erneut angewendet. Nachdem das Gerät wiederhergestellt wurde, stellen Sie sicher, dass die neuesten Zertifikate erneut angewendet wurden, und aktualisieren Sie das BIOS/UEFI des Systems auf die neueste verfügbare Version. Dies kann dazu beitragen, eine Wiederholung des Problems beim Zurücksetzen des sicheren Starts zu verhindern, da viele OEMs Firmwarekorrekturen für dieses spezifische Problem veröffentlicht haben.
Was ist passiert
Nach dem Anwenden des Zertifikatupdates für den sicheren Start und dem Neustart kann das Gerät nicht mehr gestartet werden und erreicht Windows nicht.
So erkennen Sie es
-
Das Gerät schlägt sofort nach dem Neustart fehl, der für das Update für den sicheren Start erforderlich ist.
-
Möglicherweise wird ein Firmware- oder Sicherer Startfehler angezeigt, oder das System kann vor dem Laden von Windows beendet werden.
-
Wenn Sie den sicheren Start deaktivieren, kann das Gerät möglicherweise gestartet werden.
Warum dies geschieht
Dieses Problem kann durch einen Fehler in der UEFI-Firmwareimplementierung des Geräts verursacht werden.
Wenn Windows Updates für das Zertifikat für den sicheren Start anwendet, wird erwartet, dass die Firmware neue Zertifikate an die vorhandene datenbank mit zulässigen Signaturen für den sicheren Start angibt . Einige Firmwareimplementierungen überschreiben die Datenbank fälschlicherweise, anstatt sie anzufügen.
Wenn dies der Fall ist,
-
Zuvor vertrauenswürdige Zertifikate, einschließlich des Microsoft 2011-Bootloaderzertifikats, wurden entfernt.
-
Wenn das System zu diesem Zeitpunkt noch einen Start-Manager verwendet, der mit dem Zertifikat 2011 signiert ist, vertraut die Firmware diesem nicht mehr.
-
Die Firmware lehnt den Start-Manager ab und blockiert den Startvorgang.
In einigen Fällen kann auch die Datenbank beschädigt werden, anstatt sauber überschrieben zu werden, was zum gleichen Ergebnis führt. Dieses Verhalten wurde bei bestimmten Firmwareimplementierungen beobachtet und wird bei kompatibler Firmware nicht erwartet.
Was ist als Nächstes zu tun?
-
Geben Sie die Firmware-Setupmenüs ein, und versuchen Sie, die Einstellungen für den sicheren Start zurückzusetzen.
-
Wenn das Gerät nach dem Zurücksetzen gestartet wird, suchen Sie auf der Supportwebsite des Geräteherstellers nach einem Firmwareupdate, das die Behandlung von Secure Boot DB korrigiert.
-
Wenn ein Firmwareupdate verfügbar ist, installieren Sie es, bevor Sie den sicheren Start erneut aktivieren und Zertifikatupdates für den sicheren Start erneut anwenden.
Wenn durch das Zurücksetzen des sicheren Starts die Startfunktionalität nicht wiederhergestellt wird, erfordert die weitere Wiederherstellung wahrscheinlich OEM-spezifische Anleitungen.
Was ist passiert
Das Update des Zertifikats für den sicheren Start ist nicht abgeschlossen und bleibt in der Updatephase des Schlüsselaustauschschlüssels (KEY Exchange Key, KEK) blockiert.
So erkennen Sie es
-
Der Registrierungswert AvailableUpdates bleibt mit dem KEK-Bit (0x0004) festgelegt und wird nicht gelöscht.
-
UEFICA2023Status wird nicht in den Status "Abgeschlossen" versetzt.
-
Das Systemereignisprotokoll zeichnet wiederholt die Ereignis-ID 1803 auf, die angibt, dass das KEK-Update nicht angewendet werden konnte.
-
Das Gerät versucht weiterhin, das Update zu wiederholen, ohne fortschritte zu machen.
Warum dies geschieht
Das Aktualisieren des KEK für den sicheren Start erfordert eine Autorisierung über den Plattformschlüssel (PLATFORM Key, PK) des Geräts, der sich im Besitz des OEM befindet.
Damit das Update erfolgreich ist, muss der Gerätehersteller Microsoft einen PK-signierten KEK für diese spezifische Plattform bereitstellen. Dieser vom OEM signierte KEK ist in Windows-Updates enthalten und ermöglicht Es Windows, die Firmware-KEK-Variable zu aktualisieren.
Wenn der OEM keinen PK-signierten KEK für das Gerät bereitgestellt hat, kann Windows das KEK-Update nicht abschließen. In diesem Zustand:
-
Updates für den sicheren Start sind standardmäßig blockiert.
-
Windows kann die fehlende Autorisierung nicht umgehen.
-
Das Gerät kann die Zertifikatwartung für den sicheren Start dauerhaft nicht abschließen.
Dies kann auf älteren oder nicht unterstützten Geräten auftreten, auf denen der OEM keine Firmware- oder Schlüsselupdates mehr bereitstellt. Es gibt keinen unterstützten manuellen Wiederherstellungspfad für diese Bedingung.
Wenn Zertifikatupdates für den sicheren Start nicht angewendet werden können, zeichnet Windows Diagnoseereignisse auf, die erklären, warum der Fortschritt blockiert wurde. Diese Ereignisse werden geschrieben, wenn das Aktualisieren der Datenbank für die Sichere Startsignatur (Secure Boot Signature Database, DB) oder der Schlüsselaustauschschlüssel (Key Exchange Key, KEK) aufgrund von Firmware, Plattformstatus oder Konfigurationsbedingungen nicht sicher abgeschlossen werden kann. Die Szenarien in diesem Abschnitt verweisen auf diese Ereignisse, um häufige Fehlermuster zu identifizieren und die geeignete Korrektur zu bestimmen. Dieser Abschnitt soll die Diagnose und Interpretation der zuvor beschriebenen Probleme unterstützen und nicht neue Fehlerszenarien einführen.
Eine vollständige Liste der Ereignis-IDs, Beschreibungen und Beispieleinträge finden Sie unter Updateereignisse für sichere Startdatenbank und DBX-Variablen (KB5016061).
KEK-Updatefehler (Datenbankupdates erfolgreich, KEK nicht)
Ein Gerät kann Zertifikate in der Datenbank für den sicheren Start erfolgreich aktualisieren, schlägt jedoch während des KEK-Updates fehl. In diesem Fall kann der Updatevorgang für den sicheren Start nicht abgeschlossen werden.
Symptome
-
Datenbankzertifikatereignisse zeigen den Fortschritt an, aber die KEK-Phase ist nicht abgeschlossen.
-
AvailableUpdates bleibt auf 0x4004 festgelegt, und das 0x0004 Bit wird nach mehreren Aufgabenausführungen nicht gelöscht.
-
Ereignis 1795 oder 1803 ist möglicherweise vorhanden.
Interpretation
-
1795 weist in der Regel auf einen Firmwarefehler beim Versuch hin, eine Variable für den sicheren Start zu aktualisieren.
-
1803 gibt an, dass das KEK-Update nicht autorisiert werden kann, da eine erforderliche VOM OEM pk signierte KEK-Nutzlast für die Plattform nicht verfügbar ist.
Nächste Schritte
-
Suchen Sie für Version 1795 nach OEM-Firmwareupdates, und überprüfen Sie die Firmwareunterstützung für Updates von Variablen für den sicheren Start.
-
Vergewissern Sie sich für 1803, ob der OEM Microsoft den für das Gerätemodell erforderlichen PK-signierten KEK bereitgestellt hat.
KEK-Updatefehler auf Gast-VMs, die auf Hyper-V gehostet werden
Auf virtuellen Hyper-V-Computern müssen für Zertifikatupdates für den sicheren Start die Windows-Updates vom März 2026 sowohl auf dem Hyper-V-Host als auch auf dem Gastbetriebssystem installiert sein.
Updatefehler werden innerhalb des Gasts gemeldet, aber das Ereignis gibt an, wo eine Korrektur erforderlich ist:
-
Das im Gast gemeldete Ereignis 1795 (z. B. "Das Medium ist schreibgeschützt") gibt an, dass der Hyper-V-Host das Update vom März 2026 fehlt und aktualisiert werden muss.
-
Das im Gast gemeldete Ereignis 1803 gibt an, dass auf dem virtuellen Gastcomputer selbst das Update vom März 2026 fehlt und aktualisiert werden muss.
Referenz und Internes
Dieser Abschnitt enthält erweiterte Referenzinformationen für die Problembehandlung und den Support. Es ist nicht für die Bereitstellungsplanung vorgesehen. Er erweitert die zuvor zusammengefassten Wartungsmechanismen für den sicheren Start und bietet detailliertes Referenzmaterial zum Interpretieren von Registrierungsstatus- und Ereignisprotokollen.
Hinweis (von der IT verwaltete Bereitstellungen): Wenn sie über Gruppenrichtlinie oder Microsoft Intune konfiguriert werden, sollten zwei ähnliche Einstellungen nicht verwechselt werden. Der Wert AvailableUpdatesPolicy stellt den konfigurierten Richtlinienstatus dar. In der Zwischenzeit spiegelt AvailableUpdates den Arbeitsstatus der Bitlöschung wider. Beides kann dasselbe Ergebnis erzielen, sie verhalten sich jedoch anders, da die Richtlinie im Laufe der Zeit erneut angewendet wird.
AvailableUpdates-Bits, die für die Zertifikatwartung verwendet werden
Die folgenden Bits werden für die in diesem Dokument beschriebenen Zertifikat- und Start-Manager-Aktionen verwendet. Die Spalte Order gibt die Reihenfolge an, in der der Secure-Boot-Update-Task jedes Bit verarbeitet.
|
Auftrag |
Biteinstellung |
Verwendung |
|---|---|---|
|
1 |
0x0040 |
Dieses Bit weist den geplanten Task an, das Windows UEFI CA 2023-Zertifikat der Datenbank für sicheren Start hinzuzufügen. Dadurch kann Windows Start-Managern vertrauen, die von diesem Zertifikat signiert wurden. |
|
2 |
0x0800 |
Dieses Bit weist den geplanten Task an, die Microsoft Option ROM UEFI CA 2023 auf die Datenbank anzuwenden. Bedingtes Verhalten: Wenn das 0x4000-Flag festgelegt ist, überprüft der geplante Task zuerst die Datenbank auf das Microsoft Corporation UEFI CA 2011-Zertifikat . Das Microsoft Option ROM UEFI CA 2023-Zertifikat wird nur angewendet , wenn das Zertifikat 2011 vorhanden ist. |
|
3 |
0x1000 |
Dieses Bit weist den geplanten Task an, die Microsoft UEFI CA 2023 auf die Datenbank anzuwenden. Bedingtes Verhalten: Wenn das 0x4000-Flag festgelegt ist, überprüft der geplante Task zuerst die Datenbank auf das Microsoft Corporation UEFI CA 2011-Zertifikat . Das Microsoft UEFI CA 2023-Zertifikat wird nur angewendet , wenn das Zertifikat 2011 vorhanden ist. |
|
Modifizierer (Verhaltensflag) |
0x4000 |
Dieses Bit ändert das Verhalten der 0x0800 und 0x1000 Bits, sodass microsoft UEFI CA 2023 und Microsoft Option ROM UEFI CA 2023 nur angewendet werden, wenn die Datenbank bereits die Microsoft Corporation UEFI CA 2011 enthält. Um sicherzustellen, dass das Sicherheitsprofil des Geräts identisch bleibt, wendet dieses Bit diese neuen Zertifikate nur an, wenn das Gerät dem Microsoft Corporation UEFI CA 2011-Zertifikat vertraut. Nicht alle Windows-Geräte vertrauen diesem Zertifikat. |
|
4 |
0x0004 |
Dieses Bit weist den geplanten Task an, nach einem Schlüsselaustauschschlüssel zu suchen, der vom Plattformschlüssel (PLATFORM Key, PK) des Geräts signiert ist. Die PK wird vom OEM verwaltet. OEMs signieren das Microsoft KEK mit ihrem PK und stellen es an Microsoft bereit, wo es in monatlichen kumulativen Updates enthalten ist. |
|
5 |
0x0100 |
Dieses Bit weist den geplanten Task an, den von der Windows UEFI CA 2023 signierten Start-Manager auf die Startpartition anzuwenden. Dadurch wird der von Microsoft Windows Production PCA 2011 signierte Start-Manager ersetzt. |
Hinweise:
-
Das 0x4000 Bit bleibt festgelegt, nachdem alle anderen Bits verarbeitet wurden.
-
Jedes Bit wird vom geplanten Task Secure-Boot-Update in der oben gezeigten Reihenfolge verarbeitet.
-
Wenn das 0x0004 Bit aufgrund eines fehlenden PK-signierten KEK nicht verarbeitet werden kann, wendet der geplante Task weiterhin das durch Bit 0x0100 angegebene Start-Manager-Update an.
Erwarteter Fortschritt (AvailableUpdates)
Wenn ein Vorgang erfolgreich abgeschlossen wird, löscht Windows das zugeordnete Bit aus AvailableUpdates. Wenn ein Vorgang fehlschlägt, protokolliert Windows ein Ereignis und wiederholt, wenn die Aufgabe erneut ausgeführt wird.
Die folgende Tabelle zeigt den erwarteten Fortschritt der AvailableUpdates-Werte , wenn jede Aktualisierungsaktion für den sicheren Start abgeschlossen ist.
|
Step |
Bit verarbeitet |
Verfügbare Updates |
Beschreibung |
Erfolgsereignis protokolliert |
Mögliche Fehlerereigniscodes |
|---|---|---|---|---|---|
|
Start |
0x5944 |
Anfangszustand, bevor die Zertifikatwartung für den sicheren Start beginnt. |
- |
- |
|
|
1 |
0x0040 |
0x5944 → 0x5904 |
Windows UEFI CA 2023 wird der Datenbank für den sicheren Start hinzugefügt. |
1036 |
1032, 1795, 1796, 1802 |
|
2 |
0x0800 |
0x5904 → 0x5104 |
Fügen Sie microsoft Option ROM UEFI CA 2023 zur Datenbank hinzu, wenn das Gerät zuvor der Microsoft UEFI CA 2011 vertraut hat. |
1044 |
1032, 1795, 1796, 1802 |
|
3 |
0x1000 |
0x5104 → 0x4104 |
Microsoft UEFI CA 2023 wird der Datenbank hinzugefügt, wenn das Gerät zuvor der Microsoft UEFI CA 2011 vertraut hat. |
1045 |
1032, 1795, 1796, 1802 |
|
4 |
0x0004 |
0x4104 → 0x4100 |
Das neue Microsoft KEK 2K CA 2023, das vom OEM-Plattformschlüssel signiert wird, wird angewendet. |
1043 |
1032, 1795, 1796, 1802, 1803 |
|
5 |
0x0100 |
0x4100 → 0x4000 |
Der von Windows UEFI CA 2023 signierte Start-Manager ist installiert. |
1799 |
1797 |
Notizen
-
Sobald der einem Bit zugeordnete Vorgang erfolgreich abgeschlossen wurde, wird dieses Bit aus AvailableUpdates gelöscht.
-
Wenn einer dieser Vorgänge fehlschlägt, wird ein Ereignis protokolliert, und der Vorgang wird bei der nächsten Ausführung der geplanten Aufgabe wiederholt.
-
Das 0x4000 Bit ist ein Modifizierer und wird nicht gelöscht. Der letzte AvailableUpdates-Wert von 0x4000 gibt an, dass alle anwendbaren Updateaktionen erfolgreich abgeschlossen wurden.
-
Die Ereignisse 1032, 1795, 1796, 1802 deuten in der Regel auf Firmware- oder Plattformbeschränkungen hin.
-
Ereignis 1803 gibt an, dass der VOM OEM PK signierte KEK fehlt.
Korrekturverfahren
Dieser Abschnitt enthält schrittweise Verfahren zum Beheben bestimmter Probleme beim sicheren Start. Jedes Verfahren ist auf einen klar definierten Zustand ausgelegt und soll nur befolgt werden, nachdem die erste Diagnose bestätigt hat, dass das Problem zutrifft. Verwenden Sie diese Verfahren, um das erwartete Verhalten beim sicheren Start wiederherzustellen und Zertifikatupdates sicher durchzuführen. Wenden Sie diese Verfahren nicht allgemein oder präemptiv an.
Aktivieren des sicheren Starts in der Firmware
Wenn der sichere Start in der Firmware eines Geräts deaktiviert ist, finden Sie weitere Informationen zum Aktivieren des sicheren Starts unter Windows 11 und Sicherer Start.
Geplante Aufgabe für den sicheren Start deaktiviert oder gelöscht
Die geplante Aufgabe "Secure-Boot-Update " ist erforderlich, damit Windows Zertifikatupdates für den sicheren Start anwenden kann. Wenn die Aufgabe deaktiviert ist oder fehlt, wird die Zertifikatwartung für den sicheren Start nicht fortgesetzt.
Vorgangsdetails
|
Aufgabenname |
Secure-Boot-Update |
|
Aufgabenpfad |
\Microsoft\Windows\PI\ |
|
Vollständiger Pfad |
\Microsoft\Windows\PI\Secure-Boot-Update |
|
Wird ausgeführt als |
SYSTEM (Lokales System) |
|
Trigger |
Beim Start und alle 12 Stunden |
|
Erforderlicher Zustand |
Aktiviert |
Überprüfen der aufgaben status
Führen Sie über eine PowerShell-Eingabeaufforderung mit erhöhten Rechten aus: schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Suchen Sie nach dem Feld Status:
|
Status |
Bedeutung |
|---|---|
|
Ready |
Der Task ist vorhanden und aktiviert. |
|
Disabled |
Der Task ist vorhanden, muss aber aktiviert werden. |
|
Fehler/Nicht gefunden |
Der Task fehlt und muss neu erstellt werden. |
Aktivieren oder Neuerstellen der Aufgabe
Wenn das status Feld für Secure-Boot-Update deaktiviert, Fehler oder Nicht gefunden ist, verwenden Sie das Beispielskript, um die Aufgabe zu aktivieren: Beispiel Enable-SecureBootUpdateTask.ps1
Hinweis: Dies ist ein Beispielskript, das von Microsoft nicht unterstützt wird. Administratoren sollten es überprüfen und an ihre Umgebung anpassen.
Beispiel:
.\Enable-SecureBootUpdateTask.ps1 -Quiet
Ausführungsleitfaden
-
Wenn Zugriff verweigert angezeigt wird, führen Sie PowerShell erneut als Administrator aus.
-
Wenn das Skript aufgrund einer Ausführungsrichtlinie nicht ausgeführt wird, verwenden Sie eine Prozessbereichsumgehung:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Benötigen Sie weitere Hilfe?
Möchten Sie weitere Optionen?
Erkunden Sie die Abonnementvorteile, durchsuchen Sie Trainingskurse, erfahren Sie, wie Sie Ihr Gerät schützen und vieles mehr.
In den Communities können Sie Fragen stellen und beantworten, Feedback geben und von Experten mit umfassendem Wissen hören.
