8
Microsoft Patchday Juni 2018 - BSOD, obwohl noch kein Patch freigegeben
Hallo zusammen,
wir hatten hier letzte Woche ein massives Problem. Alles begann damit, dass ein Mitarbeiter kurz vor Feierabend anrief (wie immer), dass seine Maschine nicht hochfuhr aufgrund eines BlueScreens "KMODE_EXCEPTION_NOT_HANDLED". Wir dachten erst an defekte Hardware oder ein OS-Fehler und wollten die Maschine neu installieren, als der nächste Kollege anrief und das gleiche Problem schilderte.
Innerhalb von 30 Minuten waren wir mit einer wahren Epidemie konfrontiert. Der Fehler betraf nur die Kollegen, die ihren PC schon heruntergefahren/neu gestartet haben, also instruierten wir alle verbliebenen Kollegen, ihren PC eingeschaltet zu lassen und sich nur abzumelden.
Erste Reparaturversuche gelangen, indem ich einen Wiederherstellungspunkt auf allen betroffenen Systemen von zwei Tagen vorher aktivierte. Dann fuhren die PCs ganz normal wieder hoch. Allerdings gab es auch PCs, bei welchen die Systemwiederherstellung deaktiviert war und ich keinen Wiederherstellungspunkt zur Verfügung hatte. Diese Systeme galt es nun zu sezieren, wieso sie nicht mehr hochfuhren.
Da es schon zu später Stunde war und keine unmittelbare Gefahr bestand, dass weitere Systeme betroffen waren, ging es erstmal nach Hause und ab ins Bett. Natürlich war an Schlaf aber nicht zu denken, also mühte ich das Internet, um mögliche Ursachen für den Fehler zu finden. Am nächsten Tag ging es erstmal wieder darum, weitere Rechner wieder lauffähig zu bekommen, die an diesem Tag neu gestartet wurden. Von 140 Rechnern waren insgesamt nur 35 oder 40 Stück betroffen, von daher war der Aufwand vertretbar.
Abends konnte ich wieder nicht schlafen und habe wieder Tante Google bemüht. Nach stundenlanger Suche bin ich auf einen Registry-Eintrag bei Microsoft gestoßen.
Mit dem Juni 2018 Patchday wurde ja eine der "neuen" Spectre-NG-Lücken bearbeitet (Speculative Store Bypass). Wenn das Update installiert ist, muss der Schutz händisch in der Registry aktiviert sein. Müde wie ich dann war, bin ich doch ins Bett, aber wollte mir das dann am nächsten Tag nochmal näher anschauen.
Ich nahm also am nächsten Tag einen der Rechner, die keinen Restore-Point hatten und öffnete per WinPE die Registry des Systems. Tatsächlich waren die Registry-Werte vorhanden, obwohl sie bei uns weder per Skript noch GPO oder sonst wie verteilt werden und bei uns bis heute die Patches für Juni 2018 noch nicht freigegeben und auf den betroffenen Maschinen auch nicht so installiert wurden. Ich entfernte beide Werte und siehe da, der Rechner fuhr wieder hoch. Zuerst glaubte ich noch an einen dummen Zufall, aber nachdem ich vier weitere PCs auf die gleiche Art und Weise wieder zum Leben erwecken konnte, war der Fall klar. Etwas hat die Registry-Einträge bei uns gesetzt. Ich habe die GPO angepasst, dass die Einträge entfernt werden.
Falls jemand das gleiche Phänomen hat, sollte er das mal überprüfen, ob er den gleichen Fehler hat.
Viele Grüße
Stephan
wir hatten hier letzte Woche ein massives Problem. Alles begann damit, dass ein Mitarbeiter kurz vor Feierabend anrief (wie immer), dass seine Maschine nicht hochfuhr aufgrund eines BlueScreens "KMODE_EXCEPTION_NOT_HANDLED". Wir dachten erst an defekte Hardware oder ein OS-Fehler und wollten die Maschine neu installieren, als der nächste Kollege anrief und das gleiche Problem schilderte.
Innerhalb von 30 Minuten waren wir mit einer wahren Epidemie konfrontiert. Der Fehler betraf nur die Kollegen, die ihren PC schon heruntergefahren/neu gestartet haben, also instruierten wir alle verbliebenen Kollegen, ihren PC eingeschaltet zu lassen und sich nur abzumelden.
Erste Reparaturversuche gelangen, indem ich einen Wiederherstellungspunkt auf allen betroffenen Systemen von zwei Tagen vorher aktivierte. Dann fuhren die PCs ganz normal wieder hoch. Allerdings gab es auch PCs, bei welchen die Systemwiederherstellung deaktiviert war und ich keinen Wiederherstellungspunkt zur Verfügung hatte. Diese Systeme galt es nun zu sezieren, wieso sie nicht mehr hochfuhren.
Da es schon zu später Stunde war und keine unmittelbare Gefahr bestand, dass weitere Systeme betroffen waren, ging es erstmal nach Hause und ab ins Bett. Natürlich war an Schlaf aber nicht zu denken, also mühte ich das Internet, um mögliche Ursachen für den Fehler zu finden. Am nächsten Tag ging es erstmal wieder darum, weitere Rechner wieder lauffähig zu bekommen, die an diesem Tag neu gestartet wurden. Von 140 Rechnern waren insgesamt nur 35 oder 40 Stück betroffen, von daher war der Aufwand vertretbar.
Abends konnte ich wieder nicht schlafen und habe wieder Tante Google bemüht. Nach stundenlanger Suche bin ich auf einen Registry-Eintrag bei Microsoft gestoßen.
Mit dem Juni 2018 Patchday wurde ja eine der "neuen" Spectre-NG-Lücken bearbeitet (Speculative Store Bypass). Wenn das Update installiert ist, muss der Schutz händisch in der Registry aktiviert sein. Müde wie ich dann war, bin ich doch ins Bett, aber wollte mir das dann am nächsten Tag nochmal näher anschauen.
Ich nahm also am nächsten Tag einen der Rechner, die keinen Restore-Point hatten und öffnete per WinPE die Registry des Systems. Tatsächlich waren die Registry-Werte vorhanden, obwohl sie bei uns weder per Skript noch GPO oder sonst wie verteilt werden und bei uns bis heute die Patches für Juni 2018 noch nicht freigegeben und auf den betroffenen Maschinen auch nicht so installiert wurden. Ich entfernte beide Werte und siehe da, der Rechner fuhr wieder hoch. Zuerst glaubte ich noch an einen dummen Zufall, aber nachdem ich vier weitere PCs auf die gleiche Art und Weise wieder zum Leben erwecken konnte, war der Fall klar. Etwas hat die Registry-Einträge bei uns gesetzt. Ich habe die GPO angepasst, dass die Einträge entfernt werden.
Falls jemand das gleiche Phänomen hat, sollte er das mal überprüfen, ob er den gleichen Fehler hat.
Viele Grüße
Stephan
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 377382
Url: https://administrator.de/contentid/377382
Ausgedruckt am: 24.11.2024 um 23:11 Uhr
8 Kommentare
Neuester Kommentar
Hi,
na prima, das hört sich ja super an
Welches OS haben die Rechner denn?
VG,
Deepsys
na prima, das hört sich ja super an
Welches OS haben die Rechner denn?
VG,
Deepsys
Windows 10 Pro 1607, 1703 und 1709 x64.
Wir können halt nicht nachvollziehen, was die Einträge deployed hat. In dem Link bei Microsoft steht ja auch explizit drin, dass die Einstellungen manuell gesetzt werden müssen. Ich habe bei mir zuhause mal alle Maschinen geprüft, dort ist der Eintrag bis heute nicht gesetzt und ich musste ihn manuell setzen. Die Update-Installation war schon letzten Dienstag Abend erfolgt.
Wir können halt nicht nachvollziehen, was die Einträge deployed hat. In dem Link bei Microsoft steht ja auch explizit drin, dass die Einstellungen manuell gesetzt werden müssen. Ich habe bei mir zuhause mal alle Maschinen geprüft, dort ist der Eintrag bis heute nicht gesetzt und ich musste ihn manuell setzen. Die Update-Installation war schon letzten Dienstag Abend erfolgt.
Hi
Welchen Virenschutz setzt ihr ein??
Das der vielleicht ...
Mit freundlichen Grüßen Nemesis
Welchen Virenschutz setzt ihr ein??
Das der vielleicht ...
Mit freundlichen Grüßen Nemesis
Trend Micro OfficeScan. Haben wir aber auch schon geprüft, Trend Micro weiß da von nichts.
Der Fehler war von der Sorte "Braucht kein Mensch". Man hat ihn, findet vielleicht noch den Fehler, aber kann nicht nachvollziehen, wie der Fehler zustande kam.
Der Fehler war von der Sorte "Braucht kein Mensch". Man hat ihn, findet vielleicht noch den Fehler, aber kann nicht nachvollziehen, wie der Fehler zustande kam.
Ich hatte deinen Beitrag gesehen - und wegen des KMODE_EXCEPTION_NOT_HANDLED das Thema im Blog eingestellt.
Rückmeldung: Das Update KB4078130 setzt in der Registry die Schlüssel FeatureSettingsOverride und FeatureSettingsOverrideMask, um Spectre V2 abzuschalten. Habe dann in meinem Blog nach dem Beitrag für das Update gesucht und bin auf eine eigene Bemerkung gestoßen, dass das Tool InSpectre auch eine Option bietet, um Spectre V2 abzuschalten. Kann da was bei euren Systemen passiert sein?
Rückmeldung: Das Update KB4078130 setzt in der Registry die Schlüssel FeatureSettingsOverride und FeatureSettingsOverrideMask, um Spectre V2 abzuschalten. Habe dann in meinem Blog nach dem Beitrag für das Update gesucht und bin auf eine eigene Bemerkung gestoßen, dass das Tool InSpectre auch eine Option bietet, um Spectre V2 abzuschalten. Kann da was bei euren Systemen passiert sein?
Nein, wir setzen das Tool nicht ein, das Update KB4078130 haben wir auch nicht installiert.
Ich habe nach weitere interner Analyse auch nähere Informationen zum Fehler:
Der Fehler taucht nur dann auf, wenn der Wert FeatureSettingsOverride auf 00000008 (Hex) steht, wie von Microsoft für SpectreV2 und SpectreV4 vorgesehen und das Juni 2018 Update NICHT installiert ist. Steht der Wert auf 00000003 (Hex), dann fährt der Rechner einwandfrei hoch, es ist aber nur der SpectreV2-Schutz aktiv. Ich konnte das auf einem Testsystem mit Windows 10 1703 nachstellen, gehe aber auch davon aus, dass wie bei uns im Unternehmen 1607 und 1709 ebenfalls betroffen sind. Wenn das Juni 2018 Update installiert ist, kann man den Wert auf 00000008 setzen und alles läuft schick.
Der BlueScreen sieht wie folgt aus:
Er taucht auf, sobald Windows gestartet wird. Man sieht nicht mal mehr den obligatorischen Punktekreis beim Start oder sonst irgendwelche Vorgänge. Windows startet und sofort fährt er vor die Pumpe.
Ich glaube, ich werde nie rauskriegen, wer oder was die Werte in der Registry gesetzt hat. Dass es ein Windows-Update war, halte ich für äußerst unwahrscheinlich, weil im Verlauf nichts drinsteht und die Eventlogs der Maschine nichts dergleichen anzeigen, dass an dem betroffenen Tag überhaupt ein Update installiert wurde.
Nachtrag: Was ich noch vergessen habe. Der Fehler tritt ja beim Start des PCs auf. Es gibt keinen Dump, keine Eventlogs oder sonstige Aufzeichnungen, aus denen man überhaupt etwas auslesen könnte. Man sucht also wirklich die Nadel im Heuhaufen.
Ich habe nach weitere interner Analyse auch nähere Informationen zum Fehler:
Der Fehler taucht nur dann auf, wenn der Wert FeatureSettingsOverride auf 00000008 (Hex) steht, wie von Microsoft für SpectreV2 und SpectreV4 vorgesehen und das Juni 2018 Update NICHT installiert ist. Steht der Wert auf 00000003 (Hex), dann fährt der Rechner einwandfrei hoch, es ist aber nur der SpectreV2-Schutz aktiv. Ich konnte das auf einem Testsystem mit Windows 10 1703 nachstellen, gehe aber auch davon aus, dass wie bei uns im Unternehmen 1607 und 1709 ebenfalls betroffen sind. Wenn das Juni 2018 Update installiert ist, kann man den Wert auf 00000008 setzen und alles läuft schick.
Der BlueScreen sieht wie folgt aus:
Er taucht auf, sobald Windows gestartet wird. Man sieht nicht mal mehr den obligatorischen Punktekreis beim Start oder sonst irgendwelche Vorgänge. Windows startet und sofort fährt er vor die Pumpe.
Ich glaube, ich werde nie rauskriegen, wer oder was die Werte in der Registry gesetzt hat. Dass es ein Windows-Update war, halte ich für äußerst unwahrscheinlich, weil im Verlauf nichts drinsteht und die Eventlogs der Maschine nichts dergleichen anzeigen, dass an dem betroffenen Tag überhaupt ein Update installiert wurde.
Nachtrag: Was ich noch vergessen habe. Der Fehler tritt ja beim Start des PCs auf. Es gibt keinen Dump, keine Eventlogs oder sonstige Aufzeichnungen, aus denen man überhaupt etwas auslesen könnte. Man sucht also wirklich die Nadel im Heuhaufen.
Übrigens eine kleine Anmerkung zum Blog-Eintrag: Der Fehler tritt nicht beim Herunterfahren, sondern beim Boot der PCs auf.
Ok, danke für deine obigen Nachträge - ich habe es im Blog ergänzt. Ist natürlich übelst, wenn der BSOD auftritt, bevor das System soweit hochgefahren ist, dass ein Mini-Dump erzeugt werden kann.
