Programm bricht Installation in der Mitte ab

Nope - diese Logik kann ich überhaupt nicht nachvollziehen. @HerrmanByckling Du hast ein System mit Windows 7 Home. Da sei die Frage gestattet, ob da überhaupt ein Kaby Lake drin steckt (7. Generation, also mit einer 7 vorne in der CPU-Typ-Nummer). Sofern Du den nicht selbst gebaut und ein vorhandenes Win 7 drauf installiert hast, dürfte es ziemlich unwahrscheinlich sein, käuflich an so eine Kombination gekommen zu sein. Einmal mehr wäre es nützlich gewesen, wenn alle Systeminformationen benannt würden, denn alles kann relevant sein.

Ferner geht aus dem Blog von G.Born doch eigentlich deutlich hervor, dass der blockierende Patch erst im April kam. Im Februar hat da noch nichts ge- oder verhindert.

Außerdem kann 0x80240037 auch ganz andere Ursachen haben. Den Fehlercode gibts schon ewig und das muss ganz und gar nicht zwingend im Zusammenhang mit Kaby Lake CPUs stehen.

Immerhin unter Windows 7 kann man noch “einfach” in das c:\windows\WindowsUpdate.log schauen.

@Cookievore - steht doch oben, dass der OP einen AMD Ryzen 5 hat und Ryzen ist in dem Blog auch erwähnt. Und in dem Blog ist von 2017 (!!!) die Rede, wenn ich das richtig sehe.

Sorry, ja, siehst Du beides richtig. Hatte nach der Hardware-Spec gesucht und anscheinend immer darüber hinweg gelesen. Jo, dann ist das so. Selbst zusammengestelltes System und vorhandenes Win 7 drauf gepackt. Habe noch mal meinen betreuten Bestand durchforstet, aber da findet sich unter ~40 Systemen von 2017 bis heute keine Kombination mit einem Kaby Lake+ oder Ryzen und Windows 7. Bis Skylake gab es die Systeme noch mit Win 7 Downgrade-Lizenz, ab da aus diesem Grund nicht mehr. Mir ist das Problem in den letzten Jahren nicht praktisch untergekommen. Ansonsten hätte ich hier gerne aus der Praxis berichtet, dass das Win Upd auch nach KB4012218 / KB4012219 durchaus noch läuft.

Aber, auch wenn der Blog-Beitrag von 2017 ist, gilt, dass 0x80240037 schon wesentlich länger in allen möglichen Zusammenhängen auftritt. Ich kann nur noch mal anregen, in c:\windows\WindowsUpdate.log nachzuschauen. Wenn ein nützlicher Hinweis vorhanden ist, dann da.

Klassisches Problem von Microsoft Windows: erstell ein Unterordner: Microsoft findet den “Basisordner” (also C:; D:; etc.) also böse wenn etwas installiert werden soll (oder kopieren), selbst wenn es virtualisierte Ordner sind (also “c:\ehemals_d” auf d:\ gemappt mit dem Befehl subst; wie bei mir)

Die Fehlermeldungen von Microsoft sind leider hier überhaupt nicht sinnvoll!

Einfach nach E:\LibreOffice installieren lassen und schon geht es…

EDIT:
Danke @anon73440385, hab mir nun auch mal den Log genauer angeschaut. Die Microsoft KB-Artikel Vorschläge und Ursachen wurden ja schon genannt…

Mit was für ein Benutzer probierst du denn das Programm zu installieren?
Giga.de verweißt darauf, einmal mit Rechtsklick “Als Administrator ausführen” die Installation zu starten.

So richtig hab ich aber auch nicht mehr eine Lösung… vielleicht auch mal testweise die Benutzerkontensteuerung ausschalten (nach “UAC” im Startmenü suchen)

Diese Antwort verstehe ich jetzt aus zweierlei Gründen nicht ganz:

  • OP schreibt, dass auch die Installation ganz normal (ohne Angabe eines Installationsordner - also nach C:\Programme.... bei ihm nicht funktioniert und aus dem Log lese ich ebenfalls den Fehler 1603 + die in meinen Kommentaren (nur sichtbar, wenn man “Mehr Kommentare” aufklappt) gemachten Anmerkungen - insbesondere die Anmerkung zum Exit von wusa.exe.
  • Soweit ich das sehe, steht im Logfile zur Installation der Pfad: E:\Programme\L_Office und insofern hat der OP die in der gegebenen Antwort gemachten Bedingungen ja eigentlich eingehalten.

Das Problem lag bei mir einfach daran, daß ich erst die Installationsroutine “Typisch” gewählt hatte. Als ich “Angepasst” wählte, wurde sichtbar, daß ein Ordner mit Namen “Program Files/LibreOffice” vorgegeben ist. Diesen gibt es bei mir gar nicht, also Pfad anpassen, voilá. Schon installiert sich das…