Werbung
Fette Prozente: Die aktuellen Gaming-Deals


Kolumne: KB5034441 oder wie Microsoft sich mal wieder zum Deppen macht

Meldung von doelf, Montag der 22.01.2024, 19:04:51 Uhr

logo

Kleinstweich zeigt sich mal wieder von seiner unprofessionellen Seite: Seit das Windows-Update KB5034441 am 9. Januar 2024 auf die Nutzer losgelassen wurde, sehen sich viele Windows-10-Anweder mit Fehlermeldungen konfrontiert. Dass die Fehlermeldung die falsche ist, passt irgendwie zur aktuellen FAIL-Parade aus Redmond, bei der nach wie vor kein Ende abzusehen ist. Inzwischen rät man den Nutzern, die Fehlermeldungen einfach zu ignorieren.

Was ist passiert?
Microsoft hat sich bemüht, eine wichtige Sicherheitsanfälligkeit in seiner Geräteverschlüsselung BitLocker (CVE-2024-20666) zu beseitigen und musste dafür die Windows-Wiederherstellungsumgebung (WinRE) aktualisieren. Das Windows-Update versucht diesen Flicken auch dann anzuwenden, wenn man BitLocker gar nicht verwendet. Während dies noch einen Sinn ergibt, da man Bitlocker ja zu einem späteren Zeitpunkt aktivieren könnte, erschließt sich uns ein zweites Szenario gar nicht: Selbst wenn es keine Wiederherstellungsumgebung gibt, wird vergeblich versucht, diese zu aktualisieren. Aber auch wenn Windows 10 standardmäßig aufgesetzt wurde, kann die Installation des Patches scheitern. Und da Windows Update sehr hartnäckig ist, scheitert des Update immer wieder. Seit dem 18. Januar 2024 führt Microsoft das störrische Update für Windows 10 Version 22H2 und Windows 10 Version 21H2 unter den bekannten Problemen (Known issues) auf.

Die angebliche Ursache
Laut Microsoft ist die Größe von WinRE das Problem und somit sollte das Update im Fehlerfall CBS_E_INSUFFICIENT_DISK_SPACE melden. Das tut es natürlich nicht, denn es gibt wohl schon länger einen Fehler in der Fehlercode-Behandlungsroutine und somit wird den Benutzern ein wenig aufschlussreiches 0x80070643 – ERROR_INSTALL_FAILURE präsentiert. Das Problem mit dieser Erklärung: Auf einigen unserer Testsysteme, die allesamt mit Windows 10 Pro Version 22HE 64 Bit laufen, reichte eine 300 MiB große WinRE-Partition aus, auf anderen waren 500 MiB zu wenig. Selbst eine Erweiterung auf 750 MiB brachte auf einem System keine Abhilfe, während bei einem anderen PC das Löschen der 500 MiB großen WinRE-Partition und das erneute Erstellen derselben in unveränderter Größe das Problem beseitigen konnte. Auf einem weiteren System scheiterte das Update sechs Tage lang, doch am siebten lief es durch, ohne dass es dazwischen irgendwelche Reparaturversuche gegeben hatte.

Die Würgarounds #1: Sinnloses Herumspielen mit Diskpart
Wie üblich bestand Microsofts erste Reaktion nach dem ungläubigen Staunen in halbgaren Notlösungen. Die Anleitung zum manuellen Ändern der Partitionsgröße um 250 MB machte zunächst nur im englischen Original ein wenig Sinn, da die automatische Übersetzung einige Befehle zerhackstückelt hatte. Die Idee bei diesem Ansatz besteht darin, der Systempartition 250 MiB abzuzwacken und diese der WinRE-Partition zuzuweisen. Dies funktioniert aber nur, wenn die WinRE-Partition direkt hinter der Systempartition liegt. Bei all unseren Systemen, die wir zwischen 2019 und 2021 mit Windows-10-Installationssticks standardmäßig aufgesetzt hatten, befindet sich WinRE jedoch an erster Stelle. Es folgt die EFI-Partition und dann das eigentliche Betriebssystem. Wenn wir hier dem Betriebssystem 250 MiB klauen, dann die WinRE-Partition löschen und anschließend neu anlegen, erhalten wir eine unverändert große WinRE-Partition und behalten nicht zugewiesene 250 MiB am Ende der Festplatte.

Die Würgarounds #2: Spaß mit PowerShell
Im zweiten Anlauf sollten zwei zwei PowerShell-Skripte das Vorgehen vereinfachen. Viele Nutzer dürften bereits beim Kopieren der Skripte in einen Texteditor gescheitert sein und ein Großteil verirrte sich dann auf der Suche nach dem richtigen Updatepaket, denn dieses muss man für die PowerShell-Skripte lokal bereitstellen. Der klägliche Rest sah sich dann mit einer neuen Fehlermeldung konfrontiert, denn standardmäßig ist das Ausführen solch unsicherer PowerShell-Skripte aus dubioser Quelle deaktiviert! Wer diese Hürde im jugendliche Leichtsinn per Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine nahm, konnte das Skript dann tatsächlich ausführen und sah zuweilen auch eine Erfolgsmeldung. Blöderweise bedeutet diese keinesfalls, dass der Spuk damit behoben ist. Bei uns verbleiben zwei Systeme, auf denen das Update trotz Jubelmeldungen seitens PowerShell scheitert. Und auf einem dritten bleiben beide Skripte hängen.

Und nun?
Abwarten und Tee trinken. Idealerweise Tee mit reichlich Rum. Oder einfach nur Rum. Man kann auch rumheulen oder Linux installieren, doch das hilft alles nichts, wenn man auf eine Windows-Umgebung angewiesen ist. Damit sind wir zurück beim Abwarten (und/oder Rumtrinken). Eventuell bekommen die in Redmond das ja wieder hin. Oder sie melden, dass sie Windows 10 jetzt endgültig kaputt bekommen haben und man auf Windows 11 umsteigen soll. Was vermutlich daran scheitern wird, dass nicht alle notwendigen Updates installiert sind. Vermutlich wird das Windows-11-Update jedoch melden, dass die Maus klemmt oder ein Molch den Internetzugang verstopft, denn es gibt ja noch diesen Fehler in der Fehlercode-Behandlungsroutine. Vorerst schließen wir uns jenen Nutzern an, die gar keine Wiederherstellungspartition besitzen. Denen schreibt Microsoft nämlich, dass der Fehler problemlos ignoriert werden kann. Es kann aber auch sein, dass es sich bei dieser Aussage um eine KI-generierte Bankrotterklärung handelt.

Diese Werbefläche wurde deaktiviert. Damit geht Au-Ja.de eine wichtige Einnahmequelle verloren.

Werbung erlauben ]