Windows Defender-Update KB4052623 verursacht Secure Boot-Probleme (28.1.2019)

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

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.

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

Anzeige

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
Dieser Beitrag wurde unter Problemlösung, Virenschutz, Windows 10 abgelegt und mit , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

13 Antworten zu Windows Defender-Update KB4052623 verursacht Secure Boot-Probleme (28.1.2019)


  1. Anzeige
  2. Herr IngoW sagt:

    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

    • Schaetzer sagt:

      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.

      • Günter Born sagt:

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

  3. Gladi4 sagt:

    Der Pfad war bei mir falsch.
    Folgender Pfad funktionierte bei mir:
    “%programdata%\Microsoft\Windows Defender\Platform\4.18.1901.7-0\MpCmdRun.exe” -revertplatform

  4. Anzeige

  5. Gladi4 sagt:

    Aber vielen herzlichen Dank.
    Ich konnte mit dieser Lösung meinen PC wieder in Gang bringen ;)
    mfg Dieter

  6. Swedish Chef sagt:

    Herzlichen Glückwunsch zur Veröffentlichung auf Heise.de!

  7. jup sagt:

    lt. WSUS ist das Update zurückgezogen und wird durch das alte 4.18.1812.3 ersetzt

    mfg JE

  8. sccmadmin sagt:

    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.

    • Günter Born sagt:

      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.

      • sccmadmin sagt:

        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.

  9. Anzeige

  10. Roland Moser sagt:

    Und ein Normalverbraucher kann sich erschiessen oder sonstwie einen Abgang machen.

    • mike sagt:

      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.

Schreibe einen Kommentar zu sccmadmin Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht.