[English]Das Antimalware Plattform-Update KB4052623 des Windows Defender von Ende Januar 2019 führt dazu, dass Windows 10-Systeme mit Secure Boot nicht mehr starten können. Zudem blockiert ein aktivierter AppLocker die Downloads. Für beide Probleme gibt es aber Workarounds.
Anzeige
Erste Hinweise auf das Problem
Vor wenigen Stunden habe ich den Blog-Beitrag Windows Defender hat mal wieder Update-Schluckauf (30.1.) zu Update-Problemen beim Windows Defender veröffentlicht. Diese könnten aber mit Leistungsproblemen der betreffenden Update-Server zu tun haben. In diesem Beitrag berichtete ich aber am Rande, dass ein weitere Nutzer Probleme mit dem Update KB4052623 meldete.
Windows Defender update (KB4052623) psbly causing problem with Boot Manager/Boot Loader startup on Server 2019. Repro'd in two Hyper-V environments. Only occurs after Start > Restart. Start > Shut down or Hyper-V Shut Down button no problem @mikael_nystrom @jarwidmark @NerdPyle pic.twitter.com/IFGQt7bLbV
— Troy L. Martin (@TroyMartinNet) 22. Januar 2019
Das ist ein Update für die Windows Defender Antimalware-Plattform, welches wohl am 28.1.2019 freigegeben wurde. Der Nutzer stellte danach Probleme mit dem Boot-Manager in einer Hyper-V-Umgebung auf Windows Server 2019 fest.
Zweite Bestätigung durch einen Blog-Leser
Als Reaktion auf meinen englischsprachigen Blog-Beitrag meldete sich ein deutscher Nutzer mit dem Twitter-Namen @schätzer und teilte folgendes mit.
Anzeige
I believe I know the reason behind: https://t.co/bhx5N9mL6D We had approx. 100 clients that have not booted afterwards. #secureboot
— Schaetzer (@schaetzer) 30. Januar 2019
Bei diesem Nutzer sind um die 100 Clients durch das Update 'gestorben' und konnten danach nicht mehr starten, wenn Secure Boot aktiviert ist.
Microsoft bestätigt das Problem
Der Nutzer wies auf den KB-Artikel KB4052623 hin, der sich auf den Windows Defender unter Windows 10 und Windows Server 2016 bezieht und das Update für die Windows Defender Antimalware Plattform thematisiert. Das Update erfolgte am 28.1.2019 und steht für:
- Windows 10 (Enterprise, Pro, und Home)
- Windows Server 2016
zur Verfügung. Im KB-Artikel bestätigt Microsoft inzwischen für dieses Update ein 'know issue'. Sobald die Modul-Version 4.18.1901.7 installiert wurde, starten Windows 10 Clients nicht mehr bei aktiviertem Secure Boot. Microsoft arbeitet an der Behebung dieses Problems und will in Zukunft einen Fix freigeben.
Ein Workaround
Wer von diesem Problem getroffen wird, kann nur versuchen, die Windows 10-Maschinen mit folgenden Schritten wieder flott zu bekommen.
1. Beim Starten das BIOS/UEFI aufrufen, den Secure Boot deaktivieren und die Maschine neu booten lassen.
2. Sobald Windows 10 wieder erfolgreich gestartet wurde, in eine administrative Eingabeaufforderung wechseln und die Modulversion mit folgendem Befehl entfernen lassen:
%programdata%\Microsoft\Windows Defender\Platform\4.18.1901-7\MpCmdRun.exe" -revertplatform
Danach soll man eine Minute warten und dann die folgenden Anweisungen in der administrativen Eingabeaufforderung ausführen.
sc query windefend
sc qc windefend
Der erste Befehl stellt sicher, dass der Windows Defender-Dienst ausgeführt wird. Mit dem zweiten Befehl lässt sich prüfen, dass der Windows Defender nicht länger die Modulversion 4.18.1901.7 verwendet. Im Anschluss ist die Maschine neu zu booten und man kann im BIOS/UEFI den Secure Boot wieder aktivieren.
Neuer Pfad stört AppLocker
Microsoft hat den Pfad zum aktualisierten Windows Defender Modul geändert. Durch diesen geänderten Pfad werden bei aktiviertem AppLocker viele Downloads blockiert. Um dieses Problem zu beheben muss der Pfad für AppLocker angepasst werden. Microsoft schlägt vor, die entsprechende Gruppenrichtlinie zu öffnen. Dann ist die Einstellung der Richtlinien für den folgenden Pfad zuzulassen:
%OSDrive%\ProgramData\Microsoft\Windows Defender\Platform\*
Diese Informationen lassen sich dem KB-Artikel 4052623 entnehmen.
Dell beschreibt bereits 2018 ähnliche Probleme
An dieser Stelle noch eine kleine Ergänzung. Ich bin bei der Suche nach dem Update in diesem Dell-Dokument aus 2018 fündig geworden. Dell schreibt, dass ein solches Update mit der Modulversion 4.17.1 am 4. Januar 2018 freigegeben wurde. Auch dort wird ebenfalls auf Startprobleme bei aktivem Secure Boot wegen modifizierter Pfade hingewiesen. Das Problem ist also schon mal in ähnlicher Form vor einem Jahr aufgetreten.
Ähnliche Artikel:
Windows Defender: Keine Signatur-Updates mehr (8.11.2018)
Microsoft Security Essentials: Doppelte Definitionsupdates
Windows 10: Windows Defender bringt Fehlercode 0x80070578
Windows Defender liefert Update-Fehler 0x80070643
Windows 10 V1809: Defender Uhrzeitanzeige geht vor
Windows Defender hat mal wieder Update-Schluckauf (30.1.)
Anzeige
Das Update ist hier am 24.01.2019 installiert worden. Hab ich erst jetzt durch nachsehen bei den Updates mit bekommen.
""Update für Windows Defender Antivirus-Antischadsoftwareplattform-KB4052623 (Version 4.18.191.7) Ervorlgreich installiert am 24.01.2019""
Die PC's starten wie immer im "Secure Boot".
Systeminfo im Defender von Heute Morgen:
Antimalware-Clientversion: 4.18.1901.7
Modulversion: 1.1.15600.4
Antiviren-Version: 1.285.527.0
Antispyware-Version: 1.285.527.0
Das Problem betrifft nur Windows 10 1607, Windows 10 1703 sowie Windows 10 1709. Windows 10 1803 ist nicht betroffen. Zu Windows 10 1809 kann ich leider nichts sagen. Weiterhin ist der Windows Server 2016 potentiell davon betroffen.
Konntest Du das bei dir bei den Clients verifizieren – der KB-Artikel listet nur Windows 10 ohne Build auf – oder habe ich was übersehen.
Die Windows 10 V1809 hätte ich gerne auf einer Testmaschine überprüft – da hänge ich aber jetzt daran, dass keine Updates für den Defender gezogen werden (gestriges Problem – es kann keine Verbindung mit dem Microsoft Update Dienst hergestellt werden – die Kiste hat am 25.12.2018 die letzten Updates gezogen).
Der Pfad war bei mir falsch.
Folgender Pfad funktionierte bei mir:
"%programdata%\Microsoft\Windows Defender\Platform\4.18.1901.7-0\MpCmdRun.exe" -revertplatform
Danke – hatte in einem früheren Post schon gesehen, dass Microsoft gelegentlich so was wie '-0' an den Ordnernamen anhängt.
Aber vielen herzlichen Dank.
Ich konnte mit dieser Lösung meinen PC wieder in Gang bringen ;)
mfg Dieter
Herzlichen Glückwunsch zur Veröffentlichung auf Heise.de!
lt. WSUS ist das Update zurückgezogen und wird durch das alte 4.18.1812.3 ersetzt
mfg JE
Was zum Teufel soll ein Admin mit ein paar Tausend Clients aufgeteilt auf zu viele Standorte da machen ?
Secureboot kann man ja nur manuell deprovisionieren. Und jetzt auf allen Clients per commandline den Dreck entfernen ?
Da muss es doch noch eine andere Condition geben. In /r/sysadmin finde ich nichs dazu und auch Twitter war heute ruhig.
Dieser Gedanke schoss mir beim Schreiben des heise.de Artikels auch durch den Kopf. Da ich aber keine Lösung habe, wurden diesbezüglich 'die Füße still gehalten'. Der springende Punkt ist ja, dass die Maschine nicht mehr bootet. In Hyper-V kann man Secure Boot ja einfach deaktivieren. Aber auf Bare Metal muss man an die Hardware ran.
Absurd finde ich auch das es auch heute noch keine gute Lösung gibt Patches von seinen Systemen zurückzuziehen ohne auf die commandline zurückzugreifen. In dem Fall noch vertretbar, aber wenn ich da an Office Updates denke. Prost Mahlzeit.
Ich sortiere das mal unter, wird schon nichts passieren ein. Als Date released / revised hab ich den 16/23.01 (ich habe zwei Update Objekte in SCCM) und wenn bis jetzt noch nichts aufgeschlagen ist wird wohl auch nichts mehr kommen.
Wenn ich bedenke wie viel Zeit ich damit verschwende nach jedem patchday News Seiten abzugrasen was MS in diesem Monat
verpatcht hat, ob und in welchen Ausmaß es mich betreffen könnte. Und dann kommt so etwas daher. Unbootbare Systeme wegen Virenscanner
Defintionen.
Unpackbar.
Und ein Normalverbraucher kann sich erschiessen oder sonstwie einen Abgang machen.
So wie es aussieht sind nur die Builds vor v1803 betroffen, ein Normalverbraucher hat die aktuelle Build drauf da er gar nicht weiss was das ist.