Besitzer von 32-Bit-Windows 7-Systemen laufen möglicherweise in das Problem, dass sie bald (d.h. vor Ablauf des Support-Zeitraums) keine Updates mehr bekommen. Hintergrund ist, dass das für SHA-2-signierte Updates erforderliche Paket KB4474419 nicht installiert werden kann.
Anzeige
Wir haben heute Juni-Patchday, wo Microsoft Sicherheitsupdates verteilt. Daher möchte ich das Problem thematisieren, um herauszufinden, ob eine größere Anzahl an Nutzern von 32-Bit-Windows 7-Systemen betroffen ist.
Hintergrund: Die Nachrüstung für SHA-2-Updates
Zuerst ein kurzer Ausblick auf den Hintergrund. Microsoft hatte 2018 angekündigt, ab Mitte 2019 seine Windows-Updates nur noch mit SHA-2-Signaturen (statt mit SHA-1 und SHA-2) zu versehen – die Signierung mit SHA-1 entfällt dann aus Sicherheitsgründen. Ich hatte im Artikel Windows 7: Ab April 2019 wird ein 'SHA-2-Update' benötigt darüber berichtet.
Benutzer von Windows 7 SP1 (sowie der Server Pendants) und WSUS benötigen daher ab April 2019 ein spezielles Update, welches die Maschine für SHA2-Codesignaturen ertüchtigt. Für eine Übergangszeit werden aber noch Updates mit beiden Signaturen ausgeliefert.
Microsoft hat zum 12. März 2019 den Support-Beitrag 4472027 (2019 SHA-2 Code Signing Support requirement for Windows and WSUS) dahingehend erweitert, als das die für Windows 7 Service Pack 1, Windows Server 2008 R2 Service Pack 1 und Windows Server 2008 Service Pack 2 erforderlichen SHA-2-Updates genannt werden.
Anzeige
Update KB4474419 (SHA-2 code signing support update for Windows Server 2008 R2 and Windows 7: March 12, 2019) rüstet die Unterstützung für die SHA-2-Signaturauswertung für die genannten Betriebssysteme nach. Ich hatte im Blog-Beitrag Windows 7: Updates rüsten SHA-2-Support nach darauf hingewiesen.
Am 18. Juni 2019 muss in Umgebungen mit WSUS 3.0 SP1 das Update KB4484071 installiert sein, um noch Updates zu erhalten. Für Windows 7 SP1 und Windows Server 2008 SP2 ist der SHA-2-Support ab dem 13. August 2019 verpflichtend. Ab September 2019 gibt es keine Updates mehr, wenn die Vorbereitungsupdates für den SHA-2-Support fehlen (siehe diesen Microsoft-KB-Artikel).
Installationsprobleme mit Updates KB4474419
Ich hatte im Blog-Beitrag Windows 7: Updates rüsten SHA-2-Support nach bereits auf Installationsprobleme mit diesem Update hingewiesen. Manche Nutzern haben bei Windows 7 in der 32-Bit-Version echte Probleme. Microsoft hat zwar am 12. März 2019 das Update KB4474419 für die Unterstützung der SHA-2-Codesignierung für Windows Server 2008 R2, Windows 7 und Windows Server 2008 herausgebracht. Dessen Installation endet aber bei manchen Nutzern in einer Neustart-Schleife, wie man in diesen Kommentaren nachlesen kann.
Bei Dr. Windows gibt es diesen Thread zum Problem. Michael ILOFF hat es auch im englischsprachigen Blog-Beitrag in diesem Kommentar auf den Punkt gebracht: Ohne Installation des SHA-2-Updates werden Betroffene nach August 2019 keine neueren Updates mehr verarbeiten können. In Microsofts KB-Artikeln wie hier habe ich bisher keinen Hinweis auf diese Probleme gefunden.
Fehlerursachen für die Neustartschleife
Die Ursache für das Installationsproblem mit der anschließenden Neustartschleife scheinen fremde Bootlader oder verbogene Partitionsstrukturen zu sein.
Ein KB-Artikel KB3033929 aus 2015
Von Microsoft gibt es einen alten KB-Artikel KB3033929 (Microsoft-Sicherheitsempfehlung: Verfügbarkeit der SHA-2-Codesignaturunterstützung für Windows 7 und Windows Server 2008 R2) vom 10. März 2015. Dort geht es genau um eine Unterstützung für die SHA-2-Codesignatur, die sich nicht installieren lässt. Dort heißt es, dass das Update nicht installierbar sei, wenn folgende Bedingungen gelten:
Einige Benutzer können dieses Sicherheitsupdate nicht installieren, wenn ihre Computer die folgenden Bedingungen erfüllen:
- Sie verfügen über eine Multiboot-Konfiguration von Windows und verschiedene Linux-Distributionen
- Sie verwenden keinen Windows-Bootloader
- Windows- und Linux sind auf verschiedenen Laufwerken installiert
Wir konnten gesichert feststellen, dass Systeme, bei denen der Windows-Bootloader als primärer Loader aktiviert ist, dieses Update erfolgreich installieren können, und dass Systeme, auf denen ein anderer Bootloader als primärer Bootloader angegeben ist, das Update selbst dann nicht installieren können, wenn der Benutzer mit diesem Loader Windows auswählt.
Microsoft schlägt folgenden Workaround vor: Um dieses Problem zu umgehen, können Sie entweder Windows als Standardbootloader verwenden oder die BIOS-Einstellungen so ändern, dass der Windows-Bootloader direkt aktiviert wird, wenn Sie dieses Update installieren. Heise hat im Jahr 2015 den Artikel Bootschleife nach SHA-2-Update für Windows 7 auf Basis der obigen Informationen veröffentlicht, der noch praktische Ansätze liefert. Interessant sind auch die Kommentare zu diesem Artikel, die diverse Konstellationen als Fehlerursache samt Lösungsansätzen benennen.
Das hilft möglicherweise bei Update KB4474419
Behält man die obige Information im Hinterkopf, kommt man möglicherweise auch bei Update KB4474419 der Lösung näher. Nachfolgend habe ich mal einige Fundstellen aufgeführt, die das bestätigen:
- In diesen Thread auf Dr. Windows zum Problem kommt die klare Aussage: Ich habe das Problem gestern bei mir lösen können! Das update läuft nicht durch wenn ein "alternativer bootloader" benutzt wird! Der Nutzer verweist auf meinen SHA-2-Artikel bei heise (siehe folgender Punkt).
- Im heise-Beitrag hatte ich geschrieben: Inzwischen hat sich in einem englischen Microsoft-Forenthread eine mögliche Ursache herauskristallisiert. Die Update-Installation scheitert, wenn ein fremder Bootlader (etwa Linux GRUB2, der auf eine Linux-Partition zeigt) vorhanden ist. Nach Entfernen des Bootladers oder 'abklemmen' des Linux-Laufwerks lässt sich das Update dann erfolgreich installieren.
- Auch in diesem Kommentar auf meinen heise-Artikel gibt es einen Hinweis: Es reicht die Windowsplatte als erstes Bootmedium im Bios zu setzen. Danach lief bei mir das Update durch.
Aus dem weiter oben zitierten heise-Beitrag aus 2015 möchte ich zudem auf diesem Kommentar verweisen. Die Aussage: Es muss für die Windows Boot Partition das 'boot'-Flag gesetzt sein, damit es funktioniert. Das lässt sich mit Partitionierungswerkzeugen bewerkstelligen.
Weitere Ursachen für die Bootschleife kann auch installierte Software sein, die den Bootlader von Windows 7 manipuliert. Aus dem hohlen Bauch fallen mir das Acronis sowie das frühere TrueCrypt (heute VeraCryt) ein – ob es zutrifft, weiß ich nicht. Hier wird Syslinux als Bootlader genannt. Abschließende Frage: Ist überhaupt noch jemand von diesem Problem betroffen?
Ähnliche Artikel
SHA-2-Patch für Windows 7 kommt wohl im März 2019
Knipst der Wechsel zu SHA-2 "das Web" aus?
Windows 7: Ab April 2019 wird ein 'SHA-2-Update' benötigt
Windows 7: Updates rüsten SHA-2-Support nach
Microsoft Security Update Releases/Revisionen Mai 2019
Anzeige
Hallo Günter, Acronis Trueimage verändert die Bootreihenfolge nur dann, wenn die recht selten genutzte Try and Decide Funktion genutzt wird, die sich eigene Partitionen anlegt.
Heute ab 19 Uhr wird sich zeigen ;-)
Windows 7 Home Premium Service Pack 1 32 Bit.
Bei mir sind die Updates KB4474419 und KB4490628 in der Liste " Installierte
Updates " vorhanden. Bekomme ich trotzdem Probleme mit neuen Updates ?
Nein, in diesem Fall nicht – jedenfalls nicht, in Bezug auf die obige Themenstellung.
Hier laufen mehrere Maschinen mit Windows 7 64BIT im Double Boot mit Linux Mint. Allerdings ist der bevorzugte Bootloader der von Windows. Grub kommt erst an 2. Stelle. Installiert sind auch die SHA-2 Updates KB4474419 und KB4490628. Ich hatte bisher keinerlei Probleme. Sollte ich trotzdem noch auf was achten oder bin ich da auf der sicheren Seite?
Im Artikel war definitiv die Rede von 32-Bit-Systemen.
Asche auf mein Haupt…
Betrifft 64-Bit Dual-Boot Systeme genauso … kann ich aus eigener Erfahrung bestätigen: Linux Mint 19 64-Bit und Windows 7 Prof. 64-Bit auf jeweils eigener SSD; primäres Bootdevice mit Bootmanager GRUB ist die Linux SSD … Erfolgreiche Installation des vorgenannten Updates erfordert die temporäre Festlegung der Windows SSD als primäres Bootdevice im BIOS.
In so einem Fall ist GRUB doch völlig überflüssig.
Einfach beim Systemstart über einen BIOS-Befehl (F9, F12 oder ESC) die zu startende Festplatte auswählen.
Da ist jeder Software-Boot-Manager überflüssig. Das UEFI-BIOS regelt das.
Kann man natürlich auch so machen … persönlich bevorzuge ich aber die Lösung mit Grub, weil ich es einfach komfortabler finde.
Ist schlicht eine reine Geschmacksfrage und daher nicht als Gegenstand einer kontroversen Diskussion geeignet.
Du hast für jedes OS eine eigene SSD. Ich habe leider nur jeweils 1 SSD mit 2 Partitionen. Hab die 2 Betriebssysteme auf der einen Platte und habe nicht die Möglichkeit im BIOS zu wählen welche ich nehmen soll so wie Du sagst.
So wie es scheint, besteht das Problem nicht wenn Linux und Windows wie bei Dir auf demselben Datenträger in eigenen Partitionen liegen … andernfalls wäre die Installation der besagten Updates bei Dir nicht erfolgreich durchgelaufen … dementsprechend bist Du auf der sicheren Seite.
Hallo,
also bei uns in der Firma alles normal
x86 und x64 Windows 7 SP1 Pro
Schönen Patchday noch!
Hallo zusammen,
wir haben nun einen alten PC "ausgegraben" der schon seit August 18 nicht mehr im Netz war.
Um Updates zu bekommen, müsste ich nun folgende Updates manuell vorher installieren wenn ich richtig liege?
1. kb4490628 SSU
2. kb4489878 Rollup März 2017
3. kb4474419 SHA2 Patch
Stimmt das so oder muss ich was anders machen?
Besten Dank
Leider haben wir bei diversen 32-Bit Systemen genau dieses Problem. Es ist uns nicht möglich KB4474419 sowie aktuelle "Security Monthly Quality Rollups" (z.B. KB4503292) zu installieren. Ich gehe davon aus das in den "Security Monthly Quality Rollups" auch KB4474419 enthalten ist. Da wir weder fremde Bootloader nocht Dual-Boot Systeme haben, wird es wohl an einer verbogene Partitionsstrukturen liegen.
Auch die Windows 7 Boot-Partition ist eine Fehlerquelle wenn sie zuwenig freien Speicherplatz enthält. Entweder aufräumen, irgendwo hat jemand geschrieben dass er Logdateien gelöscht hat, oder sonst die Boot-Partition vergrössern.
Weiteres hier:
https://www.borncity.com/blog/2019/03/13/windows-7-updates-rsten-sha-2-support-nach/
https://answers.microsoft.com/en-us/windows/forum/all/kb4474419-will-not-install/658900bc-3103-4a0e-a9ed-08c5c2d31e76
Hi Mike,
Danke für Deine Antwort. Das habe ich auch schon gemacht, leider ohne Erfolg :-(
Momentan weiss auch ich nicht mehr weiter…
Hallo zusammen,
ich konnte das Problem mittlerweile beheben. Schuld waren folgende zwei Treiber die für einen USB-Dongle benötigt werden:
– HASP-Kernelgerätetreiber (Haspnt.sys) und
– Hardlock-Schlüsseltreiber (hardlock.sys)
nach entfernen der Treiber konnte ich das Update erfolgreich installieren. Diese problematischen Treiber werden auch im KB4088878 (https://support.microsoft.com/de-ch/help/4088878) explizit erwähnt, jedoch in den darauf folgenden nicht mehr. Daher habe ich dies leider übersehen. Ein System benötigen diesen Treiber nicht mehr, daher kann ich diese auch ohne Probleme entfernen. Leider sind immer noch einige Systeme im Einsatz, die aktiv diese Treiber nutzen. Hier kann ich nur auf den Hersteller hoffen, dass dieser ein Update zur Verfügung stellt.
Hallo,
bin gestern bei 2 Win7 N x64 SP1 mit den 13.08.19 Updates auf die Nase gefallen, nach der Installation der Updates konnten beide Laptops nicht mehr booten. Hab dann manuell das alles wieder behoben ( echt mühsam ).
Lösung hab ich noch keine, nur die automatischen Updates unterbunden.
viele Grüße
Hallo,
Nachtrag, konnte das Problem beheben, indem ich die 3 Updates vom 13.08.19 einzeln und hintereinander installiert hab.
KB4507437, dann KB4474419, dann KB4512506
Viele Grüße
Installieren des KB4474419 als allererstes behob bei mir (Windows 7 SP1 x64) auch das Problem! Ab da ließen sich alle noch ausstehenden Updaten wieder problemlos installieren.
Dass das Problem nur in 32 Bit Umgebungen auftaucht, ist wohl wirklich nur ein Gerücht.
Einen schönen Gruß
Habe Windows7 SP1 32bit und eine Linux Mint 9.1 Partition auf einer zweiten Platte. Beim Boot startet das Linux Menü welches automatisch Linux Mint starten würde. (gehe daher von einem Linux Boot Loader aus) Windows muss ich manuell selektieren und bestätigen.
Ich habe unter Windows den Updateprozess gestartet – eingespielt und nach dem herunterfahren startete ich in Windows 7 neu und da wurden die updates üblicherweise eingespielt/eingerichtet – ohne Loginmaske wurde dann jedoch nochmals neu gestartet und dann nochmals Windows 7 gestartet – diesmal mit Login Maske – Fehler wurde keiner gemeldet, daher gehe ich davon aus, dass die Updates oben sind. Müsste aber nochmal schauen, da ich dann gleich wider herunter gefahren bin und in Linux gestartet habe.
Kann daher das Problem mit genau der beschriebenen Konfiguration nicht nachvollziehen. Allerdings habe ich Linux Mint erst seit etwa Mai. D.h. wenn notwendige SHA2 Updates schon davor kamen, dann könnte es eine Erklärung sein.
Habe gestern mein Win7 SP1 64bit mit Installation der August-Patches versorgt und hänge nun ebenfalls in einer Endlosbootschleife. Reparaturfunktion nicht erfolgreich – komischerweise kein Wiederherstellungspunkt mehr da. Wüsste nicht, dass ich diese Funktion bewusst mal deaktiviert habe, oder vielleicht doch wegen SSD?
Ich habe z.B. kein Linux etc. parallel installiert. Trotzdem wird kein Bootmedium gefunden. Es gibt eine 100 MB EFI-Partition mit boot-Flag, eine Basic Data Partition mit 230 GB und NTFS und irgendwas mit 26 GB unbekannt und Kennzeichen HFS. Die ist aber schon immer da und hat bisher nie gestört.
Versuche nun verzweifelt irgendwie das Windows wieder zum Fliegen zu bekommen.
Danke Microsoft. Ich habe extra eine Woche gewartet und da ich keine Hinweise auf Fehler gefunden habe, gestern auf den Knopf gedrückt.
Update am 16.8 kein boot.
KB4474419 und KB4512506 wurden gleichzeitig installiert. Beide verblieben in Pending.
Win-Bootloader wurde aber aktuakisiert. Folge SHA2 Boot image konnte nicht mehr verifiziert werden.
Konfiguration:
Win64, 2 Installationen auf verschiedenen Partitionen (Raid). 2. Raid Daten. Acronis Backup 11.5. HP mit versteckter System-Rep-Partition.
Kein Linux oder andere Bootloader.
Lösung.
Komplettsicherung Acronis-CD.
Boot mit 2. Win. Mit dism pending updates entfernt. Reboot altes Windows. Alle update deaktiviert.
Bemerkung: Ein halbes Jahr vor Updateende so ein sch…
Schau dir zur Sicherheit meine folgenden Blog-Beiträge an:
Windows 7 SP1: Update KB4512506 erzeugt Error 0x800F0816
Windows 7 SP1: Update KB4512506 erzeugt Error 0xc0000225
Windows 7 Neuinstallation und der Boot-Fehler 0xc0000428
Problem ist oder war das bereits 4474419 fehlgeschlagen ist aber trotzdem 4512506 installiet wird.
EventLog:
Installationsfehler: Die Installation des folgenden Updates ist mit Fehler 0x800f0845 fehlgeschlagen: 2019-08 Security Update for Windows 7 for x64-based Systems (KB4474419)
Ein fehlschlagender Boot ist die automatische Folge. Mit 4512506 wird ein Bootimage mit SHA2 installiert, das aber nicht mehr verifiziert werden kann. Entweder feht hier die Definition einer Abhängigkeit oder so etwas geht nicht (kann ich mir nicht vorstellen)
Lösung war dism (boot in parallelem System, ggf könnte auch Rettungskonsole helfen wenn die HD mit der Systempartiotion noch zurgreifbar ist -> offline repair). Auf C war die fehlerhafte aktualisierte Win-Version.
dism.exe /image:C:\ /cleanup-image /revertpendingactions
Fehlermeldung ignoiert.
Reboot alte installation.
Automatischer Uninstall beim Boot.
Neustart alte Installation.
Update deaktiviert.
Bei mir lag es an einem temporären wsus Account, in dem ich immer noch eingeloggt war. Dieser wurde von dem Chip Update Pack angelegt.
Wenn ich unter diesem Account das KB4474419 Update manuell starte, dann bricht es nach Neustart wie bekannt ab.
Habe diesen wsus Account gelöscht und mich wieder mit meinem normalen Account angemeldet und es lief einfach durch. Warum? Keine Ahnung, hatten beide admin Rechte.
Win 7 pro 64bit