Windows Server 2019/Windows 10 Enterprise 2019 LTSC: Performance-Probleme mit Update KB5041578

Windows[English]Zum 13. August 2024 (zweiter Dienstag im Monat, Patchday bei Microsoft) wurde das kumulative Update KB5041578 für Windows 10 Enterprise 2019 LTSC  und Windows Server 2019 veröffentlicht. Inzwischen liegen mir Leserhinweise über gravierende Performance-Probleme mit dem Update vor. Von langsamen Systemen über schwarze Bildschirme werden diverse Fehlerbilder berichtet. Hier eine kurze Übersicht des Themas und eine mögliche Lösung.

Windows Update KB5041578

Das kumulative Update KB5041578 steht nur für Windows 10 2019 Enterprise LTSC und Windows 10 2019 IoT Enterprise LTSC sowie Windows Server 2019 bereit (Patchday: Windows 10/Server-Updates (13. August 2024)). Das Update enthält eine Reihe Bugfixes, die im Supportbeitrag aufgelistet sind. Unter anderem wird das Bitlocker-Problem aus dem Juli 2024-Update behoben. Und es werden diverse Härtungsmaßnahmen für Windows aktiviert.

Wegen der als kritisch (CVEv3 Score 9.8) eingestuften Windows TCP/IP Remote Code Execution-Schwachstelle CVE-2024-38063 sollte das Update zeitnah installiert werden. Die kritische RCE-Schwachstelle in Windows TCP/IP wird als „Exploitation More Likely“ eingestuft. Ein Angreifer kann diese Sicherheitslücke remote ausnutzen, indem er speziell gestaltete IPv6-Pakete an einen Host sendet. Microsoft empfiehlt, IPv6 zu deaktivieren, da nur IPv6-Pakete zur Ausnutzung dieser Sicherheitslücke missbraucht werden können.

Probleme mit dem Update KB5041578

Das kumulative Update KB5041578 scheint sowohl bei Windows 10 als auch bei Windows Server 2019 bei bestimmten Konstellationen Probleme zu bereiten.

Meldung 1: Windows 10 Enterprise 2019 LTSC

Blog-Leser Arthur hat mich per E-Mail kontaktiert, weil er in seinem Umfeld in massive Probleme mit dem Update KB5041578 auf Windows 10 2019 Enterprise LTSC-Systemen gelaufen ist. Er schreibt, dass die Geräte nach dem Update Ewigkeiten zum Anmelden brauchen. Anschließend bleibt der Desktop für mehrere Minuten schwarz. Ist der Desktop geladen, läuft das System so langsam, dass betroffene Geräte nicht zu nutzen sind. Auch die Remote Powershell funktioniert in dem Zustand nicht.

Laut Leser sind in seinem Umfeld zwar hauptsächlich Legacy-BIOS-Geräte betroffen . Allerdings schreibt er, dass auch einige UEFI-Rechner sind dabei. Wird das Update deinstalliert, sei alles wieder normal, schreibt der Leser. Sobald das Update erneut installiert wird, ist das Fehlerbild wieder da. Er fragt, ob das Problem in der Community bekannt sei, da er online überhaupt nichts dazu finden konnte? Ich selbst kann auf meinem Windows 10 2019 IoT Enterprise LTSC-System nichts dergleichen feststellen, das System läuft wie vor dem Update.

Meldung 2: Windows Server 2019

Ergänzung: Inzwischen hat sich Michael per Mail gemeldet, weil bei ihm das Update KB5041578 auf drei Servern Probleme machte. Die [Windows Server 2019] liefen nach der Update-Installation so langsam, weil die Systeme ausgelastet waren. Was er am schlimmsten fand, war der Umstand, dass der Remote Desktop nicht mehr funktionierte oder auch nur sehr, sehr langsam reagierte. Ein remote arbeiten ist so nicht mehr möglich. Er hat dann mit der PowerShell die Updates deinstalliert, was laut seiner Aussage auch Stunden dauerte.

Meldung 3: Windows Server 2019

Inzwischen sind hier im Blog zum Beitrag Patchday: Windows 10/Server-Updates (13. August 2024) Kommentare hinterlassen worden, die ähnliches berichten. Hary schreibt in diesem Kommentar, dass er in das Problem gelaufen sei, dass nach dem Update auf Windows Server 2029, die RDP-Verbindung nur noch schwarzes Bild zeigte. Nach ca. einer Stunde erschien auf dem Remote Desktop zwar ein Bild. Aber das System bzw. über die Verbindung reagiert alles extrem träge und es sei keine Interaktion möglich. Nicht mal der Taskmanager ließ sich öffnen, und der Administrator hat nur per RDP Zugriff auf das System. Das Fehlerbild klingt wie die obige Beschreibung.

Weiter Bestätigung und eine mögliche Lösung

In diesem Kommentar präzisiert Hary dieses Fehlerbild. Ein weiterer Leser weist auf diesen reddit.com-Thread hin, wo das Fehlerbild (einige laggende Server 2019) ebenfalls beschrieben wird.

kb5041578 is causing us issues on a few 2019 servers (but not all) , when installed it causes lagging and apps are unresponsive at times. Once uninstalled everything returns to normal. Does anyone have any ideas on what might be going on? We haven’t been able to identify a pattern to this issue.

Was mir auffällt: Es trifft nicht alle Nutzer von Windows Server 2019 oder Windows 10 2019 Enterprise LTSC und Windows 10 2019 IoT Enterprise LTSC. Aber möglicherweise gibt es eine Erklärung und einen Fix.

Lösung catroot2-Ordner leeren?

Ein Nutzer antwortet darauf, dass bei seinen betroffenen Systemen das Löschen des Inhalts des Ordners:

C:\Windows\System32\catroot2

dieses Problem in seiner Umgebung zu beheben scheint. Das Löschen des Ordnerinhalts vor dem Patchen scheint laut Nutzer das Problem überhaupt nicht zu verursachen.

net stop cryptsvc
del c:\windows\system32\catroot2 /s /q
net start cryptsvc

Ein Leser hat mir dann noch die obige Befehlsfolge gepostet, mit denen sich der oben genannte Ordner leeren lässt. Habe ich aber nicht getestet – da selbst nicht betroffen.

Was die Ursache sein könnte

Die spannende Frage ist, warum es bei einigen Leuten Server und Clients betrifft, andere jedoch nicht. Im oben verlinkten Reddit.com-Thread bin ich der Ursache möglicherweise auf die Spur gekommen. Der Betroffene wurde auf Reddit gefragt, wie er auf die Lösung kam.

Der Administrator bemerkte bei der Fehleranalyse eine hohe CPU-Auslastung durch die Verschlüsselungsdienste auf allen betroffenen Rechnern. Er gibt an, dass etwas schnell Protokolle in catroot2 schrieb und löschte. Danach hat er einfach nach möglichen Ursachen und Lösungen gegoogelt.

Ein weiterer Nutzer merkt an, dass einige Systeme den kryptografischen Dienst stoppen, mehrere Minuten lang in der Stop-Pending-Phase hängen bleiben. Dann werden die Protokolldateien durchforstet, und das System beruhigt sich, der kryptografische Dienst läuft wieder. Allerdings werden die Protokolldateien in System32\catroot2 auf problematischen Systemen alle 2 Minuten neu erstellt.

Vielleicht hilft es Betroffenen weiter. Danke an Arthur und die restlichen Blog-Leser für die Hinweise.

Ähnliche Artikel:
Microsoft Security Update Summary (9. Juli 2024)
Patchday: Windows 10/Server-Updates (13. August 2024)
Windows Server 2019/Windows 10 Enterprise 2019 LTSC: Performance-Probleme mit Update KB5041578

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

19 Antworten zu Windows Server 2019/Windows 10 Enterprise 2019 LTSC: Performance-Probleme mit Update KB5041578

  1. Stefan A. sagt:

    Gibt es auch Berichte / Betroffene zu Server 2016 oder Server 2022 oder treten die Probleme bisher nur bei Server 2019 auf?

    Inzwischen ist jeder Patchday nur noch eine Qual!
    Einerseits will man schnell Lücken stopfen, andererseits holt man sich neue Probleme dazu…

    • Günter Born sagt:

      Ich habe noch keinen Überblick diesbezüglich – vielleicht kommt was von ggf. betroffenen Blog-Lesern. Bei Windows Server 2022 und Windows 11 gibt es andere Problemberichte – da habe ich mir aber noch kein Bild gemacht.

  2. Stefan (AT) sagt:

    Hab hier auf 2016 Server und 2016 RDS keine Probleme, lief auch bei 2019 und Windows 10 sowie Windows 11 ohne jegliche Probleme. Mehrere verschiedene Kunden und Systeme.

  3. StefanS sagt:

    Ich konnte keines der Probleme nachvollziehen.
    Weder unter Server 2019 ( RDS ), noch unter Win10 LTSC 2019 (MBR und UEFI ).
    Bestimmt schon 40 Systeme gepatch.

  4. Matthias Keller sagt:

    Hatten das Problem auf unseren 2016 Servern auch gehabt, nach dem Reboot war kein Zugriff per RDP möglich, auch über das VC (Vmware) war keine Anmeldung über die Console möglich, der Login Screen erschien nicht, nur ein sich immer währender drehender Kreis (auf blauem Hintergrund), als ob die Installation noch nicht richtig fertig gewesen wäre. Nach gefühlt 1h Stunde oder mehr, war der Zugriff dann möglich. Wir hatten dann testweise auf den anderen Server den Sophos Endpoint während der Installation deaktiviert, und hatten dann bei allen anderen Server 2016 keine Probleme mehr nach dem Reboot.
    Server 2022 liefen dagegen anstandslos.

  5. Matthias G. sagt:

    Also hier keine vergleichbaren Probleme (Server 2019, Windows 10 und 11).
    Nur auf den Servern das üblicher, dass ein, zwei Dienste beim ersten Neustart nicht automatisch neu starten.

  6. hary sagt:

    Guten morgen zusammen,
    Danke, das hat meinen Server wieder in den Normalzustand gebracht!

    Ich hatte zuvor den Patch wieder deinstalliert , weil nichts mehr ging.
    Dann folgendes ausgeführt
    net stop cryptSvc
    Ren C:\Windows\System32\catroot2 Catroot2.old
    net start cryptSvc
    Dann den Patch installiert und keine Performance Probleme mehr.

    Besten Dank,
    Hary!

  7. UPuetz sagt:

    Tja, bin mir nicht sicher, ob ich davon betroffen war – vor über einem Monat! Damals hatte ich bei einem Server 2019 das Problem. Sowohl per RDP wie auch per Rustdesk nur schwarzes Bild mit Cursor.
    Habe damals absolut nichts dazu gefunden und nach ein paar Stunden ein Backup wiederhergestellt (und danach keine Updates mehr installiert…)

  8. TBR sagt:

    Bei und auch keinerlei Performanceprobleme, weder 2026 oder 2019 noch 2022. Windows 10 und 11 auch problemlos.

  9. Nico sagt:

    Bei uns bisher auch alles Problemlos ( Diverse 2016er und 2019er Server unter VMWare )

  10. Phatair sagt:

    Wir konnten den Fehler bisher auch bei keinem Server 2019 (Datacenter) feststellen.

    Ich bin noch nicht so weit die DCs zu aktualisieren.
    Konnte aber jemand von euch diesen Fehler mit dem Item Level Targeting bestätigen?
    https://www.reddit.com/r/sysadmin/comments/1eso8iy/kb5041578_breaks_new_itemlevel_targeting_in_gpos/

    • Frank sagt:

      Ja das konnte ich nachstellen, neue GPOs lassen sich nicht mit dem Item Level Targeting erstellen. Laut einem Reddit Post sollen aber bestehende GPOs nicht betroffen sein, habe das aber nicht getestet.

  11. martin hess sagt:

    Wir hatten bei diversen Endkunden diverse 2019er Server, welche betroffen waren. Es sind keine Gemeinsamkeiten unter den betroffenen (DC’s, normale Member Server, RDS etc) bzw nicht betroffenen Servern zu finden.

    Am einfachsten hat sich der Zugriff via das Computer Management Snapin auf einem anderen Server gezeigt.

  12. Lars Rosplesch sagt:

    Spontan gibt es in dem KB Artikel von MS zu dem Problem eine Information über den Fehler und Lösungsmöglichkeiten.

    https://support.microsoft.com/en-us/topic/august-13-2024-kb5041578-os-build-17763-6189-522a6305-63d2-40e3-8084-2ab8f9589bc6#ID0ELBD=Windows_Update

    Alternativ hab ich folgendes von einem MS Engineer bekommen.
    1 – RDP issue:
    If you cannot access the VM for a couple of minutes to change the registry manually as advised above, use the PowerShell Script below (you can run it using Run Command direcly on the Azure Portal):
    Run scripts in a Windows VM in Azure using action Run Commands – Azure Virtual Machines | Microsoft Learn

    # Define the registry path and value name
    $registryPath = „HKCU:\Software\Microsoft\Terminal Server Client“
    $valueName = „RDGClientTransport

    # Set the value to 0
    Set-ItemProperty -Path $registryPath -Name $valueName -Value 0

    # Confirm the change
    Get-ItemProperty -Path $registryPath -Name $valueName

    2 – Performance issue:
    To fix the performance issue, you need to stop the CryptSvc service and delete the folder catroot2. You can do that running the commands below on PowerShell (and again if you cannot access the VM to perform it manually), you can run the command below from Run Command):

    Set-service CryptSvc -StartupType Disabled
    Stop-service Wuauserv -Force
    Stop-service cryptsvc -Force
    Stop-service bits -Force
    Remove-Item -Path C:\windows\system32\catroot2 -Recurse -Force
    Set-service CryptSvc -StartupType Automatic
    Start-service Wuauserv
    Start-service cryptsvc
    Start-service bits

  13. Jorge M. sagt:

    Achtung. In deinem Blogartikel ist ein Fehler!
    Zwischen C: und dem Pfad steht ein Leerzeichen, das da nicht hingehört! Es müsste heißen ohne Leerzeichen im Pfad!

    Ich denke, eine einfachere Lösung besteht darin, zu prüfen, ob der Ordner, der mit {C6B0F072- beginnt, existiert.

    Siehe: https://www.reddit.com/r/sysadmin/comments/1eqziiy/comment/lieofg4/

    Außerdem analysiert Ihre Blogging-Software Backslashes beim Bearbeiten von Kommentaren nicht richtig.

  14. Ralf sagt:

    Wir haben mehrere WS2019 aktualisiert und sehen keine Probleme. Es scheint somit kein generelles Problem zu sein.

  15. Jan sagt:

    hier mal ein Skript womit man seine Server durchgehen kann. Es prüft auf den besagten Ordner ob er vorhanden ist und somit Probleme mit dem Update entstehen können.

    # Basis-IP-Adresse definieren (ohne das letzte Oktett)
    $baseIP = „172.22.0“

    # Timeout für den Ping-Test in Millisekunden
    $pingTimeout = 200 # 200ms

    # Schleife, die das letzte Oktett von 1 bis 254 durchläuft
    for ($i = 1; $i -le 254; $i++) {
    $currentIP = „$baseIP.$i“

    # Prüfen, ob die IP-Adresse erreichbar ist (ping)
    $pingResult = Test-Connection -ComputerName $currentIP -Count 1 -Quiet

    if ($pingResult) {
    Write-Host „$currentIP ist erreichbar. Prüfe Ordner…“
    $remotePath = „\\$currentIP\C$\Windows\System32\catroot2“

    # Prüfen, ob der Ordner {C6B0F072-……} existiert
    if (Test-Path -Path „$remotePath\{C6B0F072-*}“) {
    Write-Host „!!!!!Ordner auf $currentIP gefunden!!!!!“
    }
    } else {
    Write-Host „$currentIP ist nicht erreichbar. Überspringe…“
    }
    }

  16. Thomas sagt:

    Hallo zusammen,

    mir ist noch was aufgefallen hat zwar nicht wirklich mit Performance-Probleme zu tun aber mit dem Update für Server 2019 und 2016 und dem dazugehörigen Net Framework

    Bei uns ist folgendes nach Installation der Updates aufgetreten:
    Wir setzen die Monitoring Lösung von paessler PRTG

    – WMI Sensoren können nicht mehr abgefragte werden (Nach Deinstallation des Server Updates geht das wieder)

    – IIS App Pools können per SNMP nicht mehr abgefragt oder neu hinzugefügt werden

    Ist das bei noch jemanden aufgetreten?

    MFG Thomas

  17. Milan sagt:

    Was auch sehr gut Hilft, in AntiVirus eine Ausnahme für die beide Ordner C:\Windows\System32\CatRoot und C:\Windows\System32\catroot2 definieren.

Schreibe einen Kommentar

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