Leitfaden zur Problembehandlung beim sicheren Start

Gilt für
Windows 10, version 1607, all editions Win 10 Ent LTSB 2016 Win 10 IoT Ent LTSB 2016 Windows 10, version 1809, all editions Win 10 Ent LTSC 2019 Win 10 IoT Ent LTSC 2019 Windows 10 ESU Windows 10 Enterprise LTSC 2021 Windows 10 IoT Enterprise LTSC 2021 Windows 11 version 23H2, all editions Windows 11 version 24H2, all editions Windows 11 version 25H2, all editions Windows 11 version 26H1, all editions Windows Server 2016 Windows Server 2019 Windows Server 2022 Windows Server, version 23H2 Windows Server 2025

Hinweis

  • Ursprüngliches Veröffentlichungsdatum: Montag, 19. März 2026
  • KB-ID: 5085046

Inhalt dieses Artikels

Übersicht

Auf dieser Seite finden Sie Anleitungen für Administratoren und Supportmitarbeiter bei der Diagnose und Lösung von Problemen mit dem sicheren Start auf Windows-Geräten. Zu den Themen gehören Fehler bei der Aktualisierung von Zertifikaten für den sicheren Start, falsche Status des sicheren Starts, unerwartete BitLocker-Wiederherstellungsaufforderungen und Startfehler nach Konfigurationsänderungen für den sicheren Start.

In diesem Leitfaden wird erläutert, wie Sie die Wartung und Konfiguration von Windows überprüfen, relevante Registrierungswerte und Ereignisprotokolle überprüfen und feststellen, wann Firmware- oder Plattformeinschränkungen ein OEM-Update erfordern. Dieser Inhalt dient zur Diagnose von Problemen auf vorhandenen Geräten. Sie ist nicht für die Planung neuer Bereitstellungen vorgesehen. Dieses Dokument wird aktualisiert, sobald neue Problembehandlungsszenarien und Anleitungen identifiziert werden.

Zurück zum Anfang

Funktionsweise der Zertifikatverwaltung 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. Ziel ist es, kritische Vertrauensanker zu aktualisieren und gleichzeitig die Möglichkeit zum Starten in jeder Phase beizubehalten.

Der Prozess wird durch eine geplante Windows-Aufgabe, eine registrierungsbasierte Abfolge von Updateaktionen und ein integriertes Protokollierungs- und Wiederholungsverhalten gesteuert. Zusammen stellen diese Komponenten sicher, dass Zertifikate für den sicheren Start und der Windows-Start-Manager kontrolliert und geordnet und nur dann aktualisiert werden, wenn die erforderlichen Schritte erfolgreich waren.

Zurück zum Anfang

Erste Schritte bei der Problembehandlung

Wenn ein Gerät bei der Anwendung von Secure Boot-Zertifikatupdates nicht die erwarteten Fortschritte zu machen scheint, identifizieren Sie zunächst die Kategorie des Problems. Die meisten Probleme fallen in einen von vier Bereichen: Windows-Wartungsstatus, Updatemechanismus für den sicheren Start, Firmwareverhalten oder eine Plattform- oder OEM-Einschränkung.

Beginnen Sie der Reihe nach mit den folgenden Überprüfungen. In vielen Fällen reichen diese Schritte aus, um das beobachtete Verhalten zu erklären und die nächsten Maßnahmen ohne tiefere Untersuchung festzulegen.

  1. Bestätigen der Windows-Wartung und Plattformberechtigung

    1. Stellen Sie sicher, dass das Gerät die grundlegenden Anforderungen für den Empfang von Zertifikatupdates für den sicheren Start erfüllt:
    2. Auf dem Gerät wird eine unterstützte Version von Windows ausgeführt.
    3. Die neuesten erforderlichen Windows-Sicherheitsupdates werden installiert.
    4. Secure Boot ist in der UEFI-Firmware aktiviert.
    5. Wenn eine dieser Bedingungen nicht erfüllt ist, beheben Sie sie, bevor Sie mit der weiteren Problembehandlung fortfahren.

  2. Überprüfen des Status der Aufgabe "Secure-Boot-Update"

    1. Vergewissern Sie sich, dass der Windows-Mechanismus, der für das Anwenden von Zertifikatupdates für den sicheren Start verantwortlich ist, vorhanden ist und funktioniert:
    2. Die geplante Aufgabe Secure-Boot-Update ist vorhanden.
    3. Der Task ist aktiviert und wird als lokales System ausgeführt.
    4. Der Task wurde seit der Installation des letzten Windows-Sicherheitsupdates mindestens einmal ausgeführt.
    5. Wenn die Aufgabe deaktiviert, gelöscht oder nicht ausgeführt wird, können Updates von Zertifikaten für den sicheren Start nicht angewendet werden. Die Problembehandlung sollte sich auf die Wiederherstellung der Aufgabe konzentrieren, bevor andere Ursachen untersucht werden.

  3. Überprüfen der Registrierungseinstellungen auf erwarteten Fortschritt
    Überprüfen Sie den Wartungsstatus des Geräts für den sicheren Start in der Registrierung:

    1. Untersuchen Sie UEFICA2023Status, UEFICA2023Error und UEFICA2023ErrorEvent.
    2. Untersuchen Sie AvailableUpdates , und vergleichen Sie sie mit dem erwarteten Fortschritt (siehe Referenz und Interna).

    Zusammen geben diese Werte an, ob die Wartung normal fortgesetzt wird, ein Vorgang wiederholt wird oder bei einem bestimmten Schritt angehalten wurde.

  4. Korrelieren des Registrierungsstatus mit Secure Boot-Ereignissen
    Überprüfen Sie Ereignisse im Zusammenhang mit dem sicheren Start im Systemereignisprotokoll, und korrelieren Sie diese mit dem Registrierungsstatus. Ereignisdaten bestätigen in der Regel, ob das Gerät Fortschritte macht, es 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, vorübergehend ist oder Korrekturmaßnahmen erfordert.

Zurück zum Anfang

Geplante Aufgabe für sicheres Starten und Aktualisieren

Die Zertifikatwartung für den sicheren Start wird über eine geplante Windows-Aufgabe mit dem Namen Secure-Boot-Update implementiert. Die Aufgabe wird unter folgendem Pfad registriert:

Hinweis

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

Der Task wird als lokales System ausgeführt. Standardmäßig wird es beim Systemstart und danach alle 12 Stunden ausgeführt. Bei jeder Ausführung wird geprüft, ob Updateaktionen für den sicheren Start ausstehen, und versucht, sie nacheinander anzuwenden.

Wenn diese Aufgabe deaktiviert ist oder fehlt, können Updates von Zertifikaten für den sicheren Start nicht angewendet werden. Die Aufgabe "Sicherer Start" muss aktiviert bleiben, damit die Wartung für den sicheren Start funktioniert.

Zurück zum Anfang

Warum eine geplante Aufgabe verwendet wird

Updates von Zertifikaten für den sicheren Start erfordern eine Koordination zwischen Windows- und UEFI-Firmware, einschließlich des Schreibens von UEFI-Variablen, in denen Schlüssel und Zertifikate für den sicheren Start gespeichert werden. Ein geplanter Task 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, Updates zu wiederholen, wenn ein vorheriger Versuch fehlgeschlagen ist oder wenn das Gerät ohne Neustart eingeschaltet geblieben ist. Dieses Design trägt dazu bei, den Fortschritt sicherzustellen, ohne dass manuelle Eingriffe erforderlich sind.

Zurück zum Anfang

Die Registrierungsbitmaske "AvailableUpdates"

Die Aufgabe "Secure-Boot-Update" wird durch den Registrierungswert "AvailableUpdates " gesteuert. Dieser Wert ist eine 32-Bit-Bit-Bitmaske unter:

Hinweis

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot

Jedes Bit im Wert steht für eine bestimmte Secure Boot-Updateaktion. Der Updateprozess beginnt, wenn AvailableUpdates auf einen Wert ungleich Null festgelegt wird, entweder automatisch durch Windows oder explizit durch einen Administrator. Beispielsweise gibt ein Wert wie 0x5944 an , dass mehrere Updateaktionen ausstehen.

Wenn die Aufgabe Secure-Boot-Update ausgeführt wird, interpretiert sie die festgelegten Bits als ausstehende Arbeit und verarbeitet sie in einer definierten Reihenfolge.

Zurück zum Anfang

Sequenzielle Updates, Protokollierung und Wiederholungsverhalten

Updates von Zertifikaten für den sicheren Start werden in einer festen Reihenfolge angewendet. Jede Updateaktion ist so konzipiert, dass sie sicher wiederholt werden kann und unabhängig abgeschlossen wird. Die Aufgabe "Secure-Boot-Update" geht erst dann zum nächsten Schritt über, wenn die aktuelle Aktion erfolgreich war und das entsprechende Bit aus "AvailableUpdates" gelöscht wurde.

Bei jedem Vorgang werden UEFI-Standardschnittstellen verwendet, um Variablen für den sicheren Start wie DB und KEK zu aktualisieren oder um 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 ein Updateschritt fehlschlägt, beendet der Task die Verarbeitung, protokolliert den Fehler und lässt das zugeordnete Bit gesetzt. Der Vorgang wird bei der nächsten Ausführung der Aufgabe wiederholt. Durch dieses Wiederholungsverhalten können Geräte nach vorübergehenden Bedingungen, z. B. fehlender Firmware-Unterstützung oder verzögerten OEM-Updates, automatisch wiederhergestellt werden.

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 fortschreitet, einen Vorgang wiederholt oder angehalten wurde.

Zurück zum Anfang

Integration mit OEM-Firmware

Zertifikatupdates für den sicheren Start hängen vom korrekten Verhalten und der Unterstützung in der UEFI-Firmware eines Geräts ab. Während Windows den Updateprozess orchestriert, ist die Firmware für die Durchsetzung der Richtlinie für den sicheren Start und die Verwaltung der Datenbanken für den sicheren Start verantwortlich.

OEMs stellen zwei wichtige Elemente bereit, die die Zertifikatwartung für den sicheren Start ermöglichen:

  • Plattformschlüssel-signierte Schlüsselaustauschschlüssel (Key Exchange Keys, KEKs), die die Installation neuer Zertifikate für den sicheren Start autorisieren.
  • Firmwareimplementierungen, die Datenbanken für den sicheren Start während Updates ordnungsgemäß beibehalten, anfügen und überprüfen.

Wenn die Firmware diese Verhaltensweisen nicht vollständig unterstützt, können Updates für den sicheren Start ins Stocken geraten, unbegrenzt 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 zur Verfügung zu stellen. Wenn die Problembehandlung auf eine Firmwareeinschränkung oder einen Defekt hinweist, müssen Administratoren möglicherweise das neueste UEFI-Firmwareupdate installieren, das vom Gerätehersteller bereitgestellt wird, bevor die Updates des Zertifikats für den sicheren Start erfolgreich abgeschlossen werden können.

Zurück zum Anfang

Häufige Fehlerszenarien und Lösungen

Secure Boot-Updates werden von der geplanten Aufgabe Secure-Boot-Update basierend auf dem Registrierungsstatus AvailableUpdates angewendet.

Unter normalen Bedingungen erfolgen diese Schritte automatisch und zeichnen Erfolgsereignisse auf, wenn jede Phase abgeschlossen ist. In einigen Fällen kann das Firmwareverhalten, die Plattformkonfiguration oder die Wartungsvoraussetzungen den Fortschritt verhindern oder zu einem unerwarteten Startverhalten führen.

In den nachstehenden Abschnitten werden die häufigsten Fehlerszenarien beschrieben, wie man sie erkennt, warum sie auftreten, und die entsprechenden nächsten Schritte zur Wiederherstellung des normalen Betriebs. Die Szenarien werden von den am häufigsten auftretenden bis zu schwerwiegenderen Fällen mit Auswirkungen auf den Start sortiert.

Secure Boot-Updates werden nicht angewendet (kein Fortschritt)

Wenn Secure Boot-Updates keinen Fortschritt anzeigen, bedeutet dies normalerweise, dass der Updateprozess nie gestartet wurde. Daher fehlen die erwarteten Registrierungswerte und Ereignisprotokolle für den sicheren Start, da der Updatemechanismus nie ausgelöst wurde.

Was ist geschehen?

Der Secure Boot-Updateprozess wurde nicht gestartet, sodass keine Secure Boot-Zertifikate oder aktualisierter Bootmanager auf das Gerät angewendet wurden.

So erkennen Sie es

  • Es sind keine Registrierungswerte für die Wartung des sicheren Starts vorhanden, z. B. UEFICA2023Status.
  • Erwartete Secure Boot-Ereignisse (z. B. 1043, 1044, 1045, 1799, 1801) fehlen im Systemereignisprotokoll.
  • Das Gerät verwendet weiterhin ältere Zertifikate und Startkomponenten.

Mögliche Gründe für die Benachrichtigung

Dieses Szenario tritt in der Regel auf, wenn eine oder mehrere der folgenden Bedingungen erfüllt sind:

  • Die geplante Aufgabe Secure-Boot-Update ist deaktiviert oder fehlt.
  • Secure Boot ist in der UEFI-Firmware deaktiviert.
  • Das Gerät erfüllt nicht die Windows-Wartungsvoraussetzungen, z. B. das Ausführen einer unterstützten Windows-Version oder die Installation erforderlicher Updates.

Was als nächstes zu tun ist

  • Vergewissern Sie sich, dass das Gerät die Windows-Wartungs- und Plattformberechtigungsanforderungen erfüllt.
  • Vergewissern Sie sich, dass Secure Boot 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, folgen Sie den Anweisungen unter Geplante Aufgabe "Sicherer Start" deaktiviert oder gelöscht , um sie wiederherzustellen. Nachdem die Aufgabe wiederhergestellt wurde, starten Sie das Gerät neu, oder führen Sie die Aufgabe manuell aus, um die Wartung des sicheren Starts zu initiieren.

Das Gerät startet nach dem Secure Boot-Update in die BitLocker-Wiederherstellung

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 vorübergehend oder dauerhaft sein, abhängig von der zugrunde liegenden Ursache.

Szenario 1: Einmalige BitLocker-Wiederherstellung nach Secure Boot-Update

Folgendes passiert:

Das Gerät beginnt die BitLocker-Wiederherstellung beim ersten Start nach dem Secure Boot-Update, startet aber bei nachfolgenden Neustarts normal.

Mögliche Gründe für die Benachrichtigung

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 einer vorübergehenden Diskrepanz zwischen den gemessenen Startwerten und löst eine Wiederherstellung aus. Beim nächsten Start meldet die Firmware die aktualisierten Werte ordnungsgemäß, BitLocker wird erfolgreich neu installiert, und das Problem tritt nicht erneut auf.

So erkennen Sie es

  • Die BitLocker-Wiederherstellung erfolgt einmal.
  • Nach Eingabe des Wiederherstellungsschlüssels wird bei nachfolgenden Starts keine Wiederherstellung aufgefordert.
  • Es ist keine laufende Startreihenfolge oder PXE-Beteiligung vorhanden.

Was als nächstes zu tun ist

  • Geben Sie den BitLocker-Wiederherstellungsschlüssel ein, um Windows fortzusetzen.
  • Suchen Sie nach Firmware-Updates.

Szenario 2: Wiederholte BitLocker-Wiederherstellung aufgrund der PXE-Konfiguration für den ersten Start

Folgendes passiert:

Das Gerät wechselt bei jedem Start in die BitLocker-Wiederherstellung.

Mögliche Gründe für die Benachrichtigung

Das Gerät ist so konfiguriert, dass es zuerst den PXE-Start (Netzwerk) versucht. 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 während eines einzelnen Startzyklus zwei verschiedene Signaturberechtigungen gemessen werden:

  • Der PXE-Startpfad wird von der Microsoft UEFI CA 2011 signiert.
  • Der Windows-Start-Manager auf dem Datenträger ist von der Windows UEFI CA 2023 signiert.

Da BitLocker beim Start unterschiedliche Vertrauensketten für den sicheren Start beobachtet, kann kein stabiler Satz von TPM-Messungen erstellt werden, um die Versiegelung erneut durchzuführen. Daher wird BitLocker bei jedem Start in die Wiederherstellung gestartet.

So erkennen Sie es

  • Die BitLocker-Wiederherstellung wird bei jedem Neustart ausgelöst.
  • Durch Eingabe des Wiederherstellungsschlüssels kann Windows gestartet werden, die Eingabeaufforderung wird jedoch beim nächsten Start zurückgegeben.
  • Der PXE- oder Netzwerkstart wird in der Firmware-Startreihenfolge vor dem lokalen Datenträger konfiguriert.

Was als nächstes zu tun ist

  • Konfigurieren Sie die Firmware-Startreihenfolge, sodass der Windows-Start-Manager auf dem Datenträger an erster Stelle steht.
  • Deaktivieren Sie den PXE-Start, wenn er nicht erforderlich ist.
  • Wenn PXE erforderlich ist, stellen Sie sicher, dass die PXE-Infrastruktur ein 2023 signiertes Windows-Startladeprogramm verwendet.
Fehler beim Booten des Geräts, nachdem der sichere Start zurückgesetzt wurde

Was ist geschehen?

Dies spiegelt eher eine Änderung auf Firmwareebene als ein Windows-Problem wider. Das Secure Boot-Update 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 eine Verletzung des sicheren Starts hinweist.
  • Der Fehler tritt auf, nachdem die Einstellungen für den sicheren Start auf die Standardwerte der Firmware zurückgesetzt wurden.
  • Wenn Sie den sicheren Start deaktivieren, kann das Gerät möglicherweise erneut gestartet werden.

Mögliche Gründe für die Benachrichtigung

Durch das Zurücksetzen des sicheren Starts auf die Firmwarestandardwerte 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.

Dies hat zur Folge, dass die Firmware den installierten Windows-Start-Manager nicht mehr als vertrauenswürdig erkennt und den Startvorgang blockiert.

Dieses Szenario wird nicht durch das Update für den sicheren Start selbst verursacht, sondern durch eine nachfolgende Firmware-Aktion, die die aktualisierten Vertrauensanker entfernt.

Was als nächstes zu tun ist

  • Verwenden Sie das Wiederherstellungshilfsprogramm für den sicheren Start, um das erforderliche Zertifikat wiederherzustellen, damit das Gerät wieder starten kann.
  • Stellen Sie nach der Wiederherstellung sicher, dass auf dem Gerät die neueste verfügbare Firmware vom Gerätehersteller installiert ist.
  • Vermeiden Sie das Zurücksetzen des sicheren Starts auf die Firmware-Standardeinstellungen, es sei denn, die OEM-Firmware enthält aktualisierte Standardeinstellungen für den sicheren Start, die den Zertifikaten für 2023 vertrauen.

Hilfsprogramm zur Wiederherstellung des sicheren Starts

So stellen Sie das System wieder her:

  1. 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\.
  2. Platzieren Sie die Datei auf einem USB-Laufwerk im FAT32-Format unter \EFI\BOOT\, und benennen Sie sie in bootx64.efi um.
  3. Starten Sie das betroffene Gerät vom USB-Laufwerk und lassen Sie das Wiederherstellungsprogramm laufen. Das Dienstprogramm fügt Windows UEFI CA 2023 zur Datenbank hinzu.

Nach dem Wiederherstellen des Zertifikats und dem Neustart des Systems sollte Windows normal starten.

Wichtig: Bei diesem Prozess wird nur eines der neuen Zertifikate erneut angewendet. Stellen Sie nach der Wiederherstellung des Geräts sicher, dass die neuesten Zertifikate erneut angewendet wurden, und aktualisieren Sie möglicherweise das BIOS/UEFI des Systems auf die neueste verfügbare Version. Dies kann dazu beitragen, ein erneutes Auftreten des Problems mit dem Zurücksetzen des sicheren Starts zu verhindern, da viele OEMs Firmware-Fixes für dieses spezielle Problem veröffentlicht haben.

Das Gerät bootet nach dem Secure Boot-Update nicht aufgrund von Firmware, die die DB überschreibt.

Was ist geschehen?

Nach dem Anwenden des Zertifikatupdates für den sicheren Start und dem Neustart kann das Gerät nicht gestartet werden und Windows nicht erreichen.

So erkennen Sie es

  • Das Gerät schlägt unmittelbar nach dem Neustart aus, der für das Secure Boot-Update erforderlich ist.
  • Möglicherweise wird ein Firmware- oder "Sicherer Start"-Fehler angezeigt, oder das System kann beendet werden, bevor Windows geladen wird.
  • Wenn Sie den sicheren Start deaktivieren, kann das Gerät möglicherweise gestartet werden.

Mögliche Gründe für die Benachrichtigung

Dieses Problem kann durch einen Fehler in der UEFI-Firmware-Implementierung des Geräts verursacht werden.

Wenn Windows Updates für Secure Boot-Zertifikate anwendet, wird erwartet, dass die Firmware neue Zertifikate an die vorhandene Datenbank für zugelassene Signaturen für den sicheren Start (DB) anfügt . Einige Firmwareimplementierungen überschreiben die Datenbank fälschlicherweise, anstatt sie anzuhängen.

In diesem Fall werden folgende Schritte ausgeführt:

  • Zuvor vertrauenswürdige Zertifikate, einschließlich des Microsoft 2011 Bootloader-Zertifikats, werden entfernt.
  • Wenn das System zu diesem Zeitpunkt noch einen Start-Manager verwendet, der mit dem 2011-Zertifikat signiert wurde, vertraut die Firmware ihm nicht mehr.
  • Die Firmware lehnt den Bootmanager ab und blockiert den Bootvorgang.

In einigen Fällen wird die Datenbank möglicherweise auch beschädigt, anstatt sauber überschrieben zu werden, was zum gleichen Ergebnis führt. Dieses Verhalten wurde bei bestimmten Firmwareimplementierungen beobachtet und ist bei konformer Firmware nicht zu erwarten.

Was als nächstes zu tun ist

  • Rufen Sie die Firmware-Setupmenüs auf, und versuchen Sie, die Einstellungen für den sicheren Start zurückzusetzen.
  • Wenn das Gerät nach dem Zurücksetzen startet, 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 die Zertifikatupdates für den sicheren Start erneut anwenden.

Wenn das Zurücksetzen des sicheren Starts die Startfunktionalität nicht wiederherstellt, erfordert die weitere Wiederherstellung wahrscheinlich OEM-spezifische Anleitungen.

Secure Boot-Update aufgrund fehlender OEM-signierter KEK blockiert

Was ist geschehen?

Das Update des Zertifikats für den sicheren Start wird nicht abgeschlossen und bleibt in der Aktualisierungsphase 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 wechselt nicht zu einem abgeschlossenen Status.
  • Das Systemereignisprotokoll zeichnet wiederholt die Ereignis-ID 1803 auf, die angibt, dass das KEK-Update nicht angewendet werden konnte.
  • Das Gerät setzt die Wiederholung des Updates fort, ohne Fortschritte zu machen.

Mögliche Gründe für die Benachrichtigung

Zum Aktualisieren des KEK für den sicheren Start ist die Autorisierung über den Plattformschlüssel (PK) des Geräts erforderlich, 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 OEM-signierte KEK ist in Windows-Updates enthalten und ermöglicht Windows, die Firmware KEK-Variable zu aktualisieren.

Wenn der OEM keine PK-signierte KEK für das Gerät bereitgestellt hat, kann Windows das KEK-Update nicht abschließen. In diesem Zustand:

  • Secure Boot-Updates werden entwurfsbedingt blockiert.
  • Die fehlende Autorisierung kann nicht von Windows umgehen.
  • Das Gerät kann dauerhaft nicht in der Lage sein, die Zertifikatwartung für den sicheren Start abzuschließen.

Dies kann auf älteren Geräten oder nicht mehr unterstützt werden, wenn der OEM keine Firmware- oder wichtigen Updates mehr bereitstellt. Für diese Bedingung gibt es keinen unterstützten manuellen Wiederherstellungspfad.

Zurück zum Anfang

Updateereignisse und Fehlerindikatoren für das Update des Secure Boot-Zertifikats

Wenn Zertifikatupdates für den sicheren Start nicht angewendet werden, zeichnet Windows Diagnoseereignisse auf, die erklären, warum der Fortschritt blockiert wurde. Diese Ereignisse werden geschrieben, wenn die Aktualisierung der Datenbank für den sicheren Start (DB) oder des Schlüsselaustauschschlüssels (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 Behebung zu bestimmen. Dieser Abschnitt dient der Unterstützung der Diagnose und Interpretation der zuvor beschriebenen Probleme, nicht der Einführung neuer Fehlerszenarien.

Eine vollständige Liste der Ereignis-IDs, Beschreibungen und Beispieleinträge finden Sie unter Ereignisse zum Aktualisieren von DB- und DBX-Variablen für den sicheren Start (KB5016061).

Fehler bei der KEK-Aktualisierung (Datenbankupdates erfolgreich, KEK nicht)

Ein Gerät kann Zertifikate in der Datenbank für den sicheren Start erfolgreich aktualisieren, schlägt jedoch während der KEK-Aktualisierung fehl. In diesem Fall kann der Secure Boot-Updateprozess nicht abgeschlossen werden.

Symptome

  • DB-Zertifikatereignisse 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.
  • Möglicherweise liegt Ereignis 1795 oder 1803 vor.

Auslegung

  • 1795 weist in der Regel auf einen Firmware-Fehler hin, während versucht wird, eine Secure Boot-Variable zu aktualisieren.
  • 1803 gibt an, dass das KEK-Update nicht autorisiert werden kann, da eine erforderliche OEM PK-signierte KEK-Nutzlast für die Plattform nicht verfügbar ist.

Nächste Schritte

  • Suchen Sie für 1795 nach OEM-Firmwareupdates, und überprüfen Sie die Firmwareunterstützung für sichere Startvariablen-Updates.
  • Überprüfen Sie für 1803, ob der OEM Microsoft den PK-signierten KEK zur Verfügung gestellt hat, der für das Gerätemodell erforderlich ist.

KEK-Updatefehler auf Gast-VMs, die auf Hyper-V gehostet werden

Auf virtuellen Hyper-V-Computern erfordern Zertifikatupdates für den sicheren Start, dass die Windows-Updates vom März 2026 sowohl auf dem Hyper-V-Host als auch auf dem Gastbetriebssystem installiert werden.

Updatefehler werden innerhalb des Gasts gemeldet, aber das Ereignis gibt an, wo eine Behebung erforderlich ist:

  • Das im Gast gemeldete Ereignis 1795 (z. B. "Das Medium ist schreibgeschützt") gibt an, dass auf dem 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.

Zurück zum Anfang

Referenz und Interna

Dieser Abschnitt enthält erweiterte Referenzinformationen zur Problembehandlung und zum Support. Sie ist nicht für die Bereitstellungsplanung vorgesehen. Es erweitert die zuvor zusammengefassten Wartungsmechanismen für den sicheren Start und bietet detailliertes Referenzmaterial für die Interpretation von Registrierungsstatus- und Ereignisprotokollen.

Hinweis (IT-verwaltete Bereitstellungen): Bei der Konfiguration über Gruppenrichtlinie oder Microsoft Intune sollten zwei ähnliche Einstellungen nicht verwechselt werden. Der AvailableUpdatesPolicy-Wert stellt den konfigurierten Richtlinienstatus dar. In der Zwischenzeit spiegelt AvailableUpdates den aktuellen Arbeitsstatus beim Bitlöschen wider. Beide können zum gleichen Ergebnis führen, verhalten sich aber unterschiedlich, da die Richtlinie im Laufe der Zeit wieder gilt.

Zurück zum Anfang

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 "Reihenfolge " gibt die Reihenfolge an, in der der Secure-Boot-Update-Task jedes Bit verarbeitet.

Reihenfolge Bit-Einstellung Verwendung
1 0x0040 Dieses Bit weist die geplante Aufgabe an, das Windows UEFI CA 2023-Zertifikat zur Datenbank für den sicheren Start hinzuzufügen. Dadurch kann Windows Start-Managern vertrauen, die mit diesem Zertifikat signiert sind.
2 0x0800 Dieses Bit weist die geplante Aufgabe an, die Microsoft-Option ROM UEFI CA 2023 auf die Datenbank anzuwenden.
Bedingtes Verhalten: Wenn das 0x4000-Flag festgelegt ist, überprüft die geplante Aufgabe zunächst die Datenbank auf das Microsoft Corporation UEFI CA 2011-Zertifikat . Das Microsoft Option ROM UEFI CA 2023-Zertifikat wird nur angewendet, wenn das Zertifikat von 2011 vorhanden ist.
3 0x1000 Dieses Bit weist die geplante Aufgabe an, Microsoft UEFI CA 2023 auf die Datenbank anzuwenden.
Bedingtes Verhalten: Wenn das 0x4000-Flag festgelegt ist, überprüft die geplante Aufgabe zunächst die Datenbank auf das Microsoft Corporation UEFI CA 2011-Zertifikat . Das Microsoft UEFI CA 2023-Zertifikat wird nur angewendet, wenn das Zertifikat von 2011 vorhanden ist.
Modifizierer (Verhaltenskennzeichnung) 0x4000 Dieses Bit ändert das Verhalten der 0x0800- und 0x1000-Bits so, dass 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 gleich 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 die geplante Aufgabe an, nach einem Schlüsselaustauschschlüssel zu suchen, der vom Plattformschlüssel (PK) des Geräts signiert ist. Die PK wird vom OEM verwaltet. OEMs signieren den Microsoft KEK mit ihrer PK und liefern ihn an Microsoft, wo er in monatlichen kumulativen Updates enthalten ist.
5 0x0100 Dieses Bit weist die geplante Aufgabe an, den von der Windows UEFI CA 2023 signierten Start-Manager auf die Startpartition anzuwenden. Dieser ersetzt den Microsoft Windows Production PCA 2011-signierten Start-Manager.

Hinweise:

  • Das 0x4000 Bit bleibt gesetzt, 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 Boot-Manager-Update an.

Zurück zum Anfang

Erwarteter Fortschritt (AvailableUpdates)

Wenn ein Vorgang erfolgreich abgeschlossen wurde, löscht Windows das zugeordnete Bit aus AvailableUpdates. Wenn ein Vorgang fehlschlägt, protokolliert Windows ein Ereignis und versucht es erneut, wenn die Aufgabe erneut ausgeführt wird.

Die folgende Tabelle zeigt die erwartete Progression der AvailableUpdates-Werte beim Abschluss jeder Secure Boot-Updateaktion.

Schritt Bit verarbeitet Verfügbare Updates Beschreibung Erfolgsereignis protokolliert Mögliche Fehlerereignisse
Start 0x5944 Anfangsstatus, bevor die Zertifikatswartung 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 der Datenbank Microsoft Option ROM UEFI CA 2023 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 als vertrauenswürdig eingestuft hat. 1045 1032, 1795, 1796, 1802
4 0x0004 0x4104 → 0x4100 Der neue Microsoft KEK 2K CA 2023, der vom OEM-Plattformschlüssel signiert ist, 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

Hinweise

  • Sobald der mit einem Bit verknüpfte 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. Ein endgültiger AvailableUpdates-Wert von 0x4000 gibt an, dass alle anwendbaren Updateaktionen erfolgreich abgeschlossen wurden.
  • Die Ereignisse 1032, 1795, 1796 und 1802 weisen in der Regel auf Firmware- oder Plattformeinschränkungen hin.
  • Ereignis 1803 gibt an, dass OEM-PK-signierter KEK fehlt.

Zurück zum Anfang

Korrekturverfahren

Dieser Abschnitt enthält schrittweise Verfahren zum Beheben bestimmter Probleme mit dem sicheren Start. Jedes Verfahren ist auf einen genau definierten Zustand beschränkt und soll erst ausgeführt werden, nachdem die Erstdiagnose bestätigt hat, dass das Problem zutrifft. Verwenden Sie diese Verfahren, um das erwartete Verhalten beim sicheren Start wiederherzustellen und sicherzustellen, dass Zertifikatsaktualisierungen sicher fortgesetzt werden können. Wenden Sie diese Verfahren nicht allgemein oder präventiv an.

Zurück zum Anfang

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.

Zurück zum Anfang

Geplanter Vorgang "Sicherer 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.

Aufgabendetails

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

So überprüfen Sie den Aufgaben-Status

Ausführen über eine PowerShell-Eingabeaufforderung mit erhöhten Rechten:
schtasks.exe /query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /v

Suchen Sie nach dem Feld "Status ":

Status Bedeutung
Bereit Aufgabe vorhanden und aktiviert.
Disabled Die Aufgabe ist vorhanden, muss aber aktiviert werden.
Fehler/Nicht gefunden Aufgabe fehlt und muss neu erstellt werden.

So aktivieren Sie die Aufgabe oder erstellen sie neu

Wenn das status Feld für Secure-Boot-Update Deaktiviert, Fehler oder Nicht gefunden lautet, 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:

Hinweis

.\Enable-SecureBootUpdateTask.ps1 -Quiet

Leitfaden zur Ausführung

  • 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 Umgehung des Prozessbereichs:

Hinweis

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Zurück zum Anfang