Bekommen Windows 7-Nutzer ein SHA-2-Update Problem?

win7Besitzer 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.

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.


Anzeige

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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

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

27 Antworten zu Bekommen Windows 7-Nutzer ein SHA-2-Update Problem?

  1. Karl Wester-Ebbinghaus (@tweet_alqamar) sagt:

    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.

  2. ID sagt:

    Heute ab 19 Uhr wird sich zeigen ;-)

  3. Hans Thölen sagt:

    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 ?

  4. Robert sagt:

    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?

  5. Volko sagt:

    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.

    • Bernard sagt:

      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.

      • Volko sagt:

        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.

      • Robert sagt:

        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.

        • Volko sagt:

          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.

  6. Sebastian sagt:

    Hallo,

    also bei uns in der Firma alles normal
    x86 und x64 Windows 7 SP1 Pro

    Schönen Patchday noch!

  7. Sebastian sagt:

    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

  8. Andi sagt:

    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.

  9. Andi sagt:

    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.

  10. Stefan sagt:

    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

  11. Stefan sagt:

    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

    • Roland sagt:

      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ß

  12. viebrix sagt:

    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.

  13. Sand sagt:

    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.

  14. Junior sagt:

    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…

  15. Saller sagt:

    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

Schreibe einen Kommentar zu Günter Born 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.