Windows Server 2019: Boot-Loop durch Update KB5010791?

Update[English]Frage in die Runde der Administratoren von Windows Server 2019-Systemen: Wie sind eure Erfahrungen in Bezug auf die Updates vom 11. Januar 2022 und Boot-Schleifen. Auf Domain Controllern sind die Boot-Loops ja bekannt, aber dort hat Microsoft ja Korrektur-Updates freigegeben. Mir ist ein Nutzerhinweis zugegangen, dass das Update KB5009557 einen Windows Server 2019 bisher stabil lief, das Update KB5010791 die Server aber in eine Boot-Schleife gezwungen habe. Ergänzung: Weitere Bestätigungen liegen vor.


Anzeige

Windows Server Boot-Loop

Die Sicherheitsupdates vom 11. Januar 2022 führten ja zu verschiedenen Problemen. Im Blog-Beitrag Microsoft Januar 2022 Patchday-Revisionen (14.1.2022) findet sich eine Übersicht über diese Probleme – Details lassen sich ggf. in den am Artikelende verlinkten Beiträgen nachlesen.

Speziell auf Windows Server wurden Domain Controller in eine Boot-Schleife gezwungen (siehe Windows Server: Januar 2022-Sicherheitsupdates verursachen Boot-Schleife). Zum 17.1. und 18.1.2022 legte Microsoft dann Korrekturupdates zum Beheben der Probleme vor. Für Windows Server 2019 steht seit dem 18. Januar 2022 das Sonderupdate KB5010791 bereit (siehe Sonderupdate für Windows Server 2019 fixt Jan. 2022-Patchday-Probleme (18.1.2022)).

Diese Updates korrigierten dann aber nicht alle aufgetretenen Patchday-Probleme. Blöd auch, dass die Updates teilweise nicht per Windows Update angeboten wurden – andererseits auf Windows-Maschinen trotz optionaler Klassifizierung automatisch installiert wurden. Im Blog-Beitrag Status der Januar 2022-Sicherheitsupdates von Microsoft (25.1.2022) hatte ich letztmalig eine Übersicht gegeben.

Boot-Schleife durch Update KB5010791

Nun hat sich Blog-Leser Holger M. bei mir zum 2. Februar 2022 per E-Mail gemeldet und berichtet von einer Boot-Schleife durch Update KB5010791 auf deren Windows Server 2019-Instanzen. Holger schrieb mir:

Wir haben gestern Abend das KB5010791 auf alle Windows Server 2019 eingespielt.

Das Update KB5009557 [vom 11.1.2022] lief auf diesen Servern, bis auf die DCs, seit dem 17.01 ohne Probleme.

Heute gegen 11 Uhr ist der Fileserver in eine Bootschleife gelaufen und hat im Abstand von wenigen Minuten 6 x gebootet.

KB5010791 scheint also auch wieder fehlerhaft zu sein…

Bedeutet also, dass das ursprüngliche Update KB5009557 vom 11.1.2022 ohne Probleme auf Windows Server 2019 lief, sofern dieser nicht als Domain Controller fungierte. Das Korrektur-Update KB5010791 vom 18.1.2022 (siehe Sonderupdate für Windows Server 2019 fixt Jan. 2022-Patchday-Probleme (18.1.2022)) verursacht dagegen eine Bootschleife auf diesem Server. Holger schreibt dabei von mehreren Maschinen mit Windows Server 2019 und hat mir folgenden Auszug aus der Fehlermeldung geschickt:

Protokollname: Application
Quelle:     Microsoft-Windows-Wininit
Datum:    02.02.2022 11:23:06
Ereignis-ID:   1015
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter: Klassisch
Benutzer:      Nicht zutreffend
Computer:      *****
Beschreibung:

Ein kritischer Systemprozess C:\Windows\system32\lsass.exe ist fehlgeschlagen mit den Statuscode c0000005. Der Computer muss neu gestartet werden.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Wininit" Guid="{206f6dea-d3c5-4d10-bc72-989f03c8b84b}" EventSourceName="Wininit" />
<EventID Qualifiers="49152">1015</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2022-02-02T10:23:06.826509700Z" />    <EventRecordID>23987</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>Application</Channel>
<Computer>***</Computer>
<Security />
</System>
<EventData>
<Data>C:\Windows\system32\lsass.exe</Data>
<Data>c0000005</Data>
</EventData>
</Event>

Die Ereignisanzeige weist folgende Einträge bezüglich des Fehlers auf:

Protokollname: Application
Quelle:        Application Error
Datum:         02.02.2022 11:23:04
Ereignis-ID:   1000
Aufgabenkategorie: (100)
Ebene:         Fehler
Schlüsselwörter: Klassisch
Benutzer:      Nicht zutreffend
Computer:      ****

Beschreibung:
Name der fehlerhaften Anwendung: lsass.exe, Version: 10.0.17763.2213, Zeitstempel: 0xcb5bd01a

Name des fehlerhaften Moduls: msv1_0.DLL, Version: 10.0.17763.2458, Zeitstempel: 0xfa73c4ac

Ausnahmecode: 0xc0000005
Fehleroffset: 0x00000000000027e1
ID des fehlerhaften Prozesses: 0x2dc

Startzeit der fehlerhaften Anwendung: 0x01d8181e8f68b510
Pfad der fehlerhaften Anwendung: C:\Windows\system32\lsass.exe
Pfad des fehlerhaften Moduls: C:\Windows\system32\msv1_0.DLL
Berichtskennung: 1ea3bc96-f018-4f8b-b8da-839e5266bed0

Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2022-02-02T10:23:04.998430300Z" /><EventRecordID>23985</EventRecordID>
<Channel>Application</Channel>
<Computer>****</Computer>
<Security />
</System>
<EventData>
<Data>lsass.exe</Data>
<Data>10.0.17763.2213</Data>
<Data>cb5bd01a</Data>
<Data>msv1_0.DLL</Data>
<Data>10.0.17763.2458</Data>
<Data>fa73c4ac</Data>
<Data>c0000005</Data>
<Data>00000000000027e1</Data>
<Data>2dc</Data>
<Data>01d8181e8f68b510</Data>
<Data>C:\Windows\system32\lsass.exe</Data><Data>C:\Windows\system32\msv1_0.DLL</Data>
<Data>1ea3bc96-f018-4f8b-b8da-839e5266bed0</Data>
<Data></Data>
<Data></Data>
</EventData>
</Event>

Weitere Bestätigungen

Ergänzung: Inzwischen habe ich weitere Bestätigungen zu meinem Post in einer Facebook Admin-Gruppe erhalten. Jan S. schreibt:

Bei uns trat dieser Fehler bei einer VM auf. Kompletter Restore vom Backup hat geholfen …

Und Patrick K. hat auch entsprechende Beobachtungen gemacht:


Anzeige

Bootloop..Hatte das gestern in einer Terminalfarm..das ganze hat sich dann soweit hochgeschaukelt das 2 der Server neu installiert werden mussten.

Jemand von euch mit ähnlichen Erfahrungen?

Ähnliche Artikel:
Windows Server: Notfall-Update fixt Remote Desktop-Probleme (4.1.2022)
Patchday: Windows 8.1/Server 2012 R2-Updates (11. Januar 2022), mögliche Boot-Probleme
Patchday: Windows 10-Updates (11. Januar 2022)
Patchday: Windows 11-Updates (11.Januar 2022)
Patchday: Updates für Windows 7/Server 2008 R2 (11. Januar 2022)

Windows Server: Januar 2022-Sicherheitsupdates verursachen Boot-Schleife
Windows VPN-Verbindungen (L2TP over IPSEC) nach Januar 2022-Update kaputt
Windows Server 2012/R2: Januar 2022 Update KB5009586 brickt Hyper-V Host
Microsoft Januar 2022 Patchday-Revisionen (14.1.2022)
Microsoft Patchday-Probleme Jan. 2022: Bugs bestätigt, Updates zurückgezogen?

Sonderupdates für Windows mit Fixes für Jan. 2022-Patchday-Probleme (17.1.2022)
Windows 11/Server 2022 Sonderupdates mit Fixes für Jan. 2022-Patchday-Probleme (17.1.2022)
Windows 10/Server: Sonderupdates mit Fixes für Jan. 2022-Patchday-Probleme (17.1.2022)
Windows 7/8.1; Server 2008R2/2012R2: Sonderupdates mit Fixes für Jan. 2022-Patchday-Probleme (17.1.2022)
Sonderupdate für Windows Server 2019 fixt Jan. 2022-Patchday-Probleme (18.1.2022)

Nachlese: Fix für Windows IPSec VPN-Verbindungproblem
Sonderupdate für Windows (17./18. Jan. 2022) fixen ReFS-Probleme nur teilweise
Nachlese: Fix für Hyper-V-Host Start-Problem in Windows (Januar 2022)
Status der Januar 2022-Sicherheitsupdates von Microsoft (25.1.2022)
Windows 10 / Windows Server Preview Updates (25.1.2022)


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Update, Windows Server abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

30 Antworten zu Windows Server 2019: Boot-Loop durch Update KB5010791?

  1. MP sagt:

    Guten Morgen,

    wir haben aktuell eine anderes Phänomen mit diesen CU's. Wenn wir die KB5009557 oder aber auch die KB5010791 versuchen zu installieren ( Citrix VDA ), scheitert die Installation und der Windows Komponentenspeicher ist anschließend hin (0x80073712). Andere WU funktionieren problemlos. Mit DISM lässt dieser sich zwar wieder reparieren aber nach einem neuen Versuch steht man wieder vor einem korrupten Store.

    Auf anderen Servern laufen die Updates ohne Probleme.

    • adrian sagt:

      Hallo MP, habe auf einem Citrix PVS Worker Server 2016 / Citrix VDA 7.15 auch den 0x80073712 Fehler. Konntest Du evlt. die Störung beheben? wenn ja wie? grüsse,

  2. Marc K. sagt:

    Hallo

    Ich habe KB5009557 nach den einschlägigen Hinweisen zu Problemen bewusst ausgelassen. Am 19.01.22 habe direkt KB5010791 installiert. Seither habe ich keine Probleme festgestellt auf meinen 2 2019er DCs.

    Grüsse
    Marc

  3. SF sagt:

    Mehrere 2019 (HV und VM) vor einigen Tagen Updates gemacht und bisher keine Auffälligkeiten.

  4. Anonymous sagt:

    Auch hier keine Probleme mit KB5010791 auf 2019 (HV-hosts und HV-guest)

  5. Michael Beck sagt:

    Ich habe KB5009557 im WSUS für die DCs nicht freigegeben, Memberserver schon. Als KB5010791 herauskam, habe ich über die Online Update Suche zunächst KB5009557 und nach dem Reboot und erneuter Suche KB5010791 installiert. Bei mir laufen alle Server wie sie sollen – DCs und Memberserver (Server 2019 Datacenter auf VMWare ESXi 7)
    ToiToiToi ;-)

  6. Foegi sagt:

    Das DC Bootproblem mit dem Update vom 11. Januar auf einem 2012R2 Server kann ich bestätigen, habe aber auch einige 2019er Server auf aktuellen Patchstand laufen, bis jetzt keine Probleme. Läuft alles auf VM 7.
    Leider steht dieses Jahr das Upgrade des DC an da AD Azure Connect ab Juni nicht mehr unterstützt wird, der stabilste und wartungsfreieste DC in meiner Admin Karriere :(

  7. Nico sagt:

    Bei uns gibt es mit der gefixten Version des CU bisher auf keine Probleme unter Server 2016 und 2019 ( Rund 20 VM,s unter VMware gepatcht )

  8. Mr. Bit sagt:

    Moin,

    ich habe auf meinen 2019er (fast) überall KB5009616 als letztes kumulatives Update laufen, dieses wurde mir nach der (verzögerten) Installation der problematischen Januar Updates direkt angeboten, die OOB Updates habe ich nicht installiert.

    • Robert Glöckner sagt:

      das denke ich auch, dass das KB5009616 die richtige Wahl ist, wenn man den ersten Wurf ausgelassen und nicht gleich den Patch zum Patch installiert hat. das heißt ja nicht umsonst kumulativ.
      Wobei ich das nicht als optionales Update angeboten bekomme nachdem das KB5010791 installiert war.
      und: 0XC000005 ist eine unbehandelte Null-Pointer-Exception, d.h. es wurde nicht geprüft ob das Ergebnis eines Funktionsaufrufs gültig ist. Das passiert gerne in jeder Art von Treibern und tritt deshalb nicht überall gleichartig auf.

  9. Fritz sagt:

    Hallo, in die lustige Fragestunde möchte ich auch mal ein Phänomen werfen:

    Ich habe neben vielen anderen zwei Server 2019 (Datacenter, unter VMware 7) , die das ganze letzte Jahr stabil liefen. Leider hatte ich KB5009557 freigegeben und installiert. Da keine DCs gab es auch keine weiteren Probleme.

    Einige Tage später konnte ich mich nicht mehr Remote anmelden, beide hingen beim Benutzerprofildienst. Nach einem Neustart über ESXi ging es jeweils wieder – für ca. einen Tag. Dann wieder dasselbe Problem.

    Da zu dieser Zeit die Meldungen zu den Problemen um die Patches 2022-01 eskalierten, habe ich sie dort wieder deinstalliert (bis auf den Servicing-Stack, der nicht deinstallierbar ist). Trotzdem gab es am nächsten Tag dasselbe Problem. Ich habe dann KB5010791 noch eine Chance gegeben, allerdings am nächsten Tag dann alles bis zum Stand 2021-12 zurückgerollt. Das Problem ist allerdings hartnäckig.

    Ursache scheint ein geplanter Task im Task-Scheduler zu sein. Leider habe ich noch nicht herausfinden können welcher – in diesem Zustand ist leider kein Zugriff mehr auf das Snapin für geplante Tasks möglich – es hängt einfach. Nach dem Neustart des Dienstes sieht man, daß einige Tasks nicht abgeschlossen werden können – unter anderem der Workplace-Join, der beim Login gestartet wird. Damit ist auch das hängende Login erklärlich.

    Sicherlich gibt es viele mögliche Gründe für so ein Problem, hier möchte ich nur die Frage abwerfen, ob jemandem so etwas genau im Zusammenhang mit den Patches 2022-01 untergekommen ist. Möglicherweise wurden durch den Patch ja geplante Aufgaben eingerichtet bzw. verändert, die bei der Installation nicht wieder zurück gerollt wurden. Da beide Server nicht wirklich kritisch sind (einer ist u.a. WSUS), würde ich demnächst sowieso mit älteren VMware Snapshots weiter untersuchen, wann das Problem angefangen hat – aber vielleicht ist es ja jemandem hier im Zusammenhang mit der letzten Patch-Katastrophe auch begegnet…

    • Andy sagt:

      Bei uns lief nach dem Patch der Zeitdienst W32tm nicht mehr, wodurch die Zeitstempel in der Domäne auseinanderdrifteten. Schau mal dort nach…

      • Fritz sagt:

        Danke für den wertvollen Hinweis.
        Der Zeitdienst hatte sich tatsächlich verabschiedet – und ich hatte die Zeitsynchronisierung durch den VMware-Host abgeschaltet (da sonst doppelt).
        Ob das die Problemursache war werde ich frühestens morgen wissen – aber es ist eine heiße Spur.

  10. Andreas K. sagt:

    Beide Updates installiert, läuft derzeit. Sowwohl HV als auch die anderen Server seit 46 Stunden außer nach dem Update kein Neustart. Server 2019 (1809).

  11. Robert sagt:

    2019er Server betreffend KB5010791 (Updates vom 11.01. ausgelassen) auf…
    6x DCs
    5x Member-Server
    3x Standalone Server (ohne AD, 2 davon als Hyper-V, 1 davon mit ReFS)
    …alle KEINE Probleme!

  12. 1ST1 sagt:

    Bisher mit den nachgereichten Updates keine Probleme, weder bei DCs, HyperV, Exchange, MS-SQL, Sharepoint, IIS, Terminalserver, Fileserver, … Allerdings hängen wir wegen der Verzögerungen und anfänglichen Unsicherheiten dem Patch-Zeitplan massiv hinterher.

  13. Singlethreaded sagt:

    Hier keine Probleme mit Update KB5010791 auf Server 2019

  14. Karl sagt:

    Bei meinen Kunden (alle auf Esxi 6,5 bzw. 7.0U2) in mehreren Kombinationen DC's und Memberserver am 21.01 nur 5010791 (bei 2012R2 5009546 + 5010794) installiert und bis jetzt keinerlei Auffälligkeiten und Probleme.
    Habe auch tlw. 2019 und 2012R2 gemischt im Betrieb.
    Auch bei Windows 10 nur 5010793 installiert.

  15. H.V. sagt:

    Hier ebenfalls:
    Als KB5010791 herauskam, habe ich über die Online Update Suche zunächst KB5009557 und nach dem Reboot und erneuter Suche KB5010791 installiert.
    2x 2019er als Member-Server (davon 1x als WSUS), keine Probleme.

    ***********************************************************************************
    Vielen Dank für die hier immer wieder geposteten Hilfen, Hinweise und Empfehlungen!!
    ***********************************************************************************

  16. Coreknabe sagt:

    Moin,

    ich habe die alten Updates für 2012R2 und 2019 auf unseren DCs wegen Dauerreboot deinstallieren müssen und danach im WSUS gesperrt (KB5009624 / KB5009595 / KB5009557) und die neuen installiert, aber nur auf den DCs (KB5010791 / KB5010794). Bisher keine Probleme, mal sehen was der Patchday nächste Woche lustiges bringt.

  17. Keine Chance den Hassern sagt:

    wie bekomme ich ein bootloop eigentlich wieder weg bei bare metal hardware also direkt auf x64 mit server2019 1809 normaler einfacher ms server. kein dc kein nix.

    danke fuer den expertenrat.
    wegen entscheidung zu microsoft wurde bei uns noch nie jemand gefeuert. da bin ich hier wenigstens sicher. danke. mfg.

    • Foegi sagt:

      Im abgesicherten Modus starten und Update deinstallieren?

      Kann mich aber dunkel erinnern das ich einmal davor noch einen Regkey setzen musste bei dem Regpfad SafeBoot Minimal irgendwas damit man im Abgesicherten Modus Programme deinstallieren kann.

      • der bug ist das ziel sagt:

        interessanter subthread:

        wie macht man das wenn man im bootloop ist? verstehe die herangehensweise nicht. wie kommt man in den safemode? vor windows urzeiten ging da ja mal was im preboot/bootsektor/earlybootloader mit tastendruck F8 erzwingen von safemodus.

        wie geht das heutzutage? :(

    • Günter Born sagt:

      So ad hoc würde ich die Maschine mit einem Windows PE booten (geht mit jedem Installationsdatenträger über die Computerreparaturoptionen). Dann sollten sich die Updates deinstallieren lassen.

  18. Michael Uray sagt:

    Habe jetzt letzte Woche alle Updates auf SRV2019 + DCs (alles in HV) eingespielt, soweit sind keine Probleme aufgetaucht.

  19. NuxV sagt:

    Die Lösung dürfte in der Installation von KB5009616 liegen – Zitat aus dem Artikel zu diesem Update (https://support.microsoft.com/en-us/topic/january-25-2022-kb5009616-os-build-17763-2510-preview-d395eb9c-40e9-425c-a026-ed2e0a0d9dd3):

    Addresses an issue that causes lsass.exe to stop working and the device restarts.
    This issue occurs when you query Windows NT Directory Services (NTDS) counters after the NTDS service has stopped.

    Habe mit diesem Update keinerlei Erfahrung, bei unseren ESXi 6.7-basierten 2019er-Servern ist das beschriebene Problem bisher nicht aufgetreten. Bis dato auch keine Probleme nach "Direkt-Installation" von KB5010791 (ohne vorherige Installation von KB5009557).

  20. Stephan sagt:

    Prima, gerade wollte ich die HVs mit dem KB5010791 patchen da ich den kompletten Jan Patchday ausgelassen habe….und schon lese ich dass es auch mit dem OOB Probleme geben kann, prima…

    Wenn der HV in einen Bootloop geht ist es echt ärgerlich, sowohl Neuinstallation als auch Patch deinstallieren daurt doch in der Regel mit Pech 1-2 Stunden

Schreibe einen Kommentar zu Anonymous Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.