Tipp: PowerShell-Workarounds für Juni-Bug der Windows-Ereignisanzeige im Detail

[English]Ich habe mich mal intensiver mit dem Bug in der Windows-Ereignisanzeige, der durch die Juni 2019-Patches verursacht wird, befasst. Speziell interessierte mich das von Microsoft ins Internet gekippte Power-Shell-Fragment. Der Beitrag ist ein Hands-on, der zeigt, wie man mit dem Workaround umgehen kann und bringt einen modifizierten Ansatz, um sowohl die Ereignisanzeige als auch 'Benutzerdefinierte Ansichten' auf einer Maschine nutzen zu können.


Anzeige

Rückblick: Darum geht es

Die Sicherheitsupdates für Windows zum Juni 2019 sollen ja zahlreiche Schwachstellen schließen, haben aber für Administratoren einen ziemlichen Pferdefuß im Gepäck. Sobald die Updates installiert wurden, klemmt die Ereignisanzeige. Sind dort unter 'Benutzerdefinierte Ansichten' eigene Einträge definiert, stürzt die Ereignisanzeige bei deren Anwahl ab.

Ereignisanzeige Fehler im Snap-In
(Zum Vergrößern klicken)

Sobald der Fehler einmalig aufgetreten ist, lässt sich die Ereignisanzeige grundsätzlich nicht mehr verwenden. Hintergrund ist, dass das betreffende Snap-In beim nächsten Start automatisch die letzte benutzerdefinierte Ansicht laden möchte.

Ich hatte mich mit dem Thema ausführlich im Blog-Beitrag Windows 7-10: Ereignisanzeige hängt nach Juni 2019-Update (KB4503293/KB4503327 etc.) auseinander gesetzt. Im Artikel wird erläutert, welche Windows-Versionen und Updates betroffen sind (faktisch alle). Und ich hatte einen Workaround skizziert, wie man zumindest den Absturz der Ereignisanzeige flicken kann.

Warum das Thema nochmals aufgreifen?

Problem bei meiner in obigem Artikel skizzierten Lösung war dabei: Mit dem Workaround kann man zwar die Ereignisanzeige wieder aufrufen und in den Ereignissen navigieren und auch suchen. Aber eigene Einträge im Zweig 'Benutzerdefinierte Ansichten' lassen sich nicht mehr definieren – dann kommt es sofort wieder zu einem Absturz. Das war von Nutzern in obigem Artikel auch in Kommentaren angemerkt worden.

Von Microsoft wurde ein Workaround veröffentlicht, mit dem sich benutzerdefinierte Ansichten per PowerShell auslesen lassen sollen. Problem bei diesem Ansatz: Der Support-Beitrag KB4508640 ist arg knapp. Die Jungs und Mädels aus Redmond haben nur das folgende Script-Fragment ins Internet gekippt:

function get-EventViewer {
                Write-Output "List of custom views on the machine"
                Write-Output ""
                Get-ChildItem "C:\ProgramData\Microsoft\Event Viewer\Views" -Filter *.xml | % { select-xml -Path $_.FullName -xpath "//Name" } | Select-Object -ExpandProperty Node | Select-Object -ExpandProperty InnerXml
 
                Write-Output ""
                $view_name = Read-Host "Enter the name of custom view to execute"
 
 
                # Get the file name of the view
                $ViewFile = Get-ChildItem "C:\ProgramData\Microsoft\Event Viewer\Views" -Filter *.xml | where-object { (Select-Xml -Path $_.FullName -xpath "//Name").Node.InnerXml -eq $view_name }
 
                Get-WinEvent -FilterXml ([xml]((Select-Xml -Path $ViewFile.FullName -XPath "//QueryList").node.OuterXml))
}

Dazu gab es dann noch die Kurzanleitung, wie man zu verfahren habe – für erfahrene Administratoren ein Kinderspiel:

To work around this issue, copy and paste the following function into a PowerShell window and run it.  You can now use the command get-EventViewer at the PowerShell prompt to view your Custom Views. You will need to re-enter the function each time you open a new PowerShell window. Note The get-EventViewer function will only allow you to view previously defined Custom Views.  To create new Custom Views, see Creating Get-WinEvent queries with FilterHashtable.

Nun gut, ich bin jetzt kein erfahrener Administrator, sondern habe mich vor 6 oder 7 Jahren zuletzt mit der PowerShell auseinander gesetzt. Und die Kollegen von der Schreibenden Zunft sind da offenbar auch nicht besser aufgestellt. Ich habe mal schnell geschaut – standardmäßig findest Du den Satz: 'Ach ja, es gibt von Microsoft einen Workaround für die PowerShell – das war es.


Anzeige

Das müsste doch klappen …

Als ich gestern abend einen Artikel für heise zum Bug verfasst habe, zuckte der Gedanke 'schau doch mal, wie der Workaround funktioniert' durch den Hinterkopf. Gesagt, getan, auf einer Windows 10-Maschine den Browser und die PowerShell-Konsole geöffnet, das obige Code-Fragment aus dem Browser per Copy&Paste in das Konsolenfenster kopiert und die Eingabetaste gedrückt. Dann sah ich nur noch rot – nix mit einer Fool-Proof-Lösung. Hatte schon diesen Teil meines Artikeltexts gelöscht, der sich mit einigen Ideen befasste, als mich der Ehrgeiz gepackt hat. Das muss Du doch zum Laufen kriegen!

Und wäre es nicht cool, wenn beides ginge: Benutzerdefinierte Ansichten abrufen, aber gleichzeitig mit der Ereignisanzeige arbeiten und dort in deren restlichen Zweigen nach Ereignissen schauen oder filtern können? Ach ja, cool wäre es, wenn das Ganze noch als anklickbare PowerShell-Module in Form von .ps1-Dateien vorliegt – und ein paar Erläuterungen für Dummies wären auch nicht schlecht.

Eine halbe Stunde später stand meine Lösung – und weil ich nicht an drei Stellen flicken möchte, habe ich das Prinzip der Single Source realisiert. Das Know-How, die PowerShell-Scripte und die Beschreibungen finden sich in diesem Blog-Beitrag (da kann ich ggf. ändern und ergänzen) – aus meinem obigen Beitrag und dem heise-Artikel wird hierhin verlinkt. Und ich kann eine zip-Datei mit einer readme.txt sowie zwei fertigen PowerShell-Lösungen zum Download bereitstellen. Das Ganze soll die Zeit, bis ein Bug-Fix von Microsoft (avisiert für Ende Juni 2019) zur Verfügung steht, überbrücken. Quasi die Hilfskrücke für genervte Administratoren und Unternehmensumgebungen. Keine Ahnung, ob das jemand braucht.

Was der Microsoft-Workaround leistet

Zuerst einige Worte zum Microsoft-Workaround – ist erfahrenen Administratoren wohl intuitiv klar – aber ich musste erst einmal den Script-Code anschauen und etwas sortieren. Das Script kann man um den Funktionsaufruf erweitern und in eine .ps1-Dateien speichern. Das Ganze sieht so aus:

function get-EventViewer { Write-Output "List of custom views on the machine" Write-Output "" Get-ChildItem "C:\ProgramData\Microsoft\Event Viewer\Views" -Filter *.xml | % { select-xml -Path $_.FullName -xpath "//Name" } | Select-Object -ExpandProperty Node | Select-Object -ExpandProperty InnerXml Write-Output "" $view_name = Read-Host "Enter the name of custom view to execute" # Get the file name of the view $ViewFile = Get-ChildItem "C:\ProgramData\Microsoft\Event Viewer\Views" -Filter *.xml | where-object { (Select-Xml -Path $_.FullName -xpath "//Name").Node.InnerXml -eq $view_name } Get-WinEvent -FilterXml ([xml]((Select-Xml -Path $ViewFile.FullName -XPath "//QueryList").node.OuterXml)) }

get-EventViewer


Erst mit der letzten Anweisung wird das Code-Fragment mit der PowerShell-Funktion get-EventViewer bei der Script-Ausführung auch aufgerufen.

Das setzt das PowerShell-Script voraus

Dieses PowerShell-Script setzt voraus, dass global für alle Benutzerkonten der Maschine 'Benutzerdefinierte Ansichten' definiert sind (die sind dann in ProgramData gespeichert).

Diese Bedingung war bei meiner Testmaschine mit Windows 10 nicht gegeben, so dass das PowerShell-Script wenig genutzt hätte. Definiert man aber benutzerdefinierte Ansichten global, lässt sich die Ereignisanzeige wegen des Bugs nicht mehr aufrufen. Man muss also komplett mittels der PowerShell arbeiten.

So wird das Script eingesetzt

Das PowerShell-Script muss mit administrativen Rechten (Als Administrator ausführen) in der PowerShell-Konsole oder in der PowerShell ISE ausgeführt werden. Dann sollte es auch keine Fehlermeldungen geben.

PowerShell-Script für benutzerdefinierte Ansichten der Ereignisanzeige
(Zum Vergrößern klicken)

Das Script listet die gefundenen globalen benutzerdefinierte Ansichten auf und fragt dann nach dem Namen der Ansicht, die anzuzeigen ist. Tippt man den Namen ein, werden die Ergebnisse aufgelistet. Obiges Bild zeigt den Ansatz in der PowerShell ISE – wobei ich dort bereits das modifizierte Script aus dem nachfolgenden Ansatz verwendet habe.

Nutze Event-Viewer und 'Benutzerdefinierte Ansichten'

An dieser Stelle entstand bei mir die Idee, ob es nicht die Möglichkeit gibt, beides, die Ereignisanzeige zu verwenden und trotzdem auch Ereignisse über benutzerdefinierte Ansichten auszulesen. Die grobe Idee war:

Dabei liegt folgende Idee zugrunde: Rufe ich unter dem Standard-Benutzerkonto die Ereignisanzeige über Als Administrator ausführen auf, läuft das Snap-In im Kontext des Administratorkontos. Sind dort keine globalen oder lokalen Einträge in 'Benutzerdefinierte Ansichten' abgelegt, funktioniert das Snap-in der Ereignisanzeige. Ich kann also in Ereignissen suchen, darf nur keine benutzerdefinierten Ereignisse anlegen.

Und zur Anzeige lokaler benutzerdefinierter Ereignisse verwendet man unter dem Standard-Benutzerkonto das PowerShell-Script. Sollte ein halbwegs komfortables Arbeiten ermöglichen – ich habe es hier kurz getestet, das funktionierte, soweit ich gesehen habe.

Lokale benutzerdefinierte Ansichten erstellen und verwenden

Um neue Einträge unter 'Benutzerdefinierte Ansichten' in der Ereignisanzeige zu verwenden, muss diese mit Standard-Benutzerrechten aufgerufen werden. Oder bei Ausführung über Als Administrator ausführen muss beim Speichern die Markierung des Kontrollkästchens Alle Benutzer im Dialogfeld Filter in benutzerdefinierte Ansicht speichern unten rechts gelöscht werden.

Benutzerdefinierte Ansicht speichern

Ich hatte das im Blog-Beitrag Windows 7-10: Ereignisanzeige hängt nach Juni 2019-Update (KB4503293/KB4503327 etc.) bereits erläutert. Die Microsoft Management Console MMC.exe speichert dann die Daten des Ereignisanzeigen-Snap-Ins in AppData des lokalen Profilordners. Damit haben die benutzerdefinierten Ansichten nur Einfluss auf das lokale Konto (und führen auch nur dort zum Absturz des Event Viewers).

Tipp: Man könnte auch die globalen XML-Dateien wie Views_0.xml etc. in den lokalen Profilordner kopieren. Dann hat man sofort die alten Definitionen – und in der Ereignisanzeige lässt sich ja maximal ein benutzerdefinierter Eintrag anlegen, da es sofort danach zum Absturz kommt. Die Pfade der Ordner habe ich ja im oben verlinkten Blog-Beitrag beschrieben.

Modifiziertes PowserShell-Script für lokale benutzerdefinierte Ansichten

Um unter diesem Benutzerkonto auf (die lokal gespeicherten) benutzerdefinierten Ansichten zuzugreifen, verwendet man ein PowerShell-Modul. Leider klappt das mit dem obigen Microsoft PowerShell-Fragment nicht. Aber das ist kein Problem, man braucht nur die Pfade zu den Views-XML-Dateien entsprechend anzupassen.

function get-EventViewer {   $account = "MSKonto"
                Write-Output "List of custom views on the machine for: $account"
                Write-Output ""
                Get-ChildItem "C:\Users$account\appdata\local\Microsoft\Event Viewer\Views" -Filter *.xml | % { select-xml -Path $_.FullName -xpath "//Name" } | Select-Object -ExpandProperty Node | Select-Object -ExpandProperty InnerXml
 
                Write-Output ""
                $view_name = Read-Host "Enter the name of custom view to execute"
 
 
                # Get the file name of the view
                $ViewFile = Get-ChildItem "C:\Users$account\appdata\local\Microsoft\Event Viewer\Views" -Filter *.xml | where-object { (Select-Xml -Path $_.FullName -xpath "//Name").Node.InnerXml -eq $view_name }
 
                Get-WinEvent -FilterXml ([xml]((Select-Xml -Path $ViewFile.FullName -XPath "//QueryList").node.OuterXml))
}
 get-EventViewer

In obiger Box ist der modifizierte PowerShell-Script-Code, um Views des lokalen Benutzerkontos auszulesen, zu finden. Ich habe eine Variable $account definiert, der ich den Namen des Benutzerprofils auf meiner Testmaschine (hier MSKonto) zugewiesen habe. Die Idee dahinter: So kann ich ein festes Konto angeben, welches die Custom Views der Ereignisanzeige enthält, d.h. das PowerShell-Script funktioniert von diversen Benutzerkonten.

Wichtig: Der Wert der Variablen (der Teil in " ") muss an den Profilnamen des eigenen Rechners, unter dem die benutzerdefinierten Ansichten angelegt wurden, angepasst werden, damit das Script funktioniert. Es handelt sich um die Datei LocalEventView.ps1.

Bei der Ausführung der Funktion greift diese dann auf AppData im Benutzerprofil zu und liest die lokal definierten 'Custom Views'. Diese werden aufgelistet und der Benutzer kann dann einen View-Namen eintippen, um die benutzerdefinierte Ansicht abzurufen (siehe nachfolgendes Bild).

Anzeige benutzerdefinierter Events in PowerShell ISE
(Zum Vergrößern klicken)

Ich habe dort die PowerShell ISE über Als Administrator ausführen gestartet (mit Standardrechten kommt es zu Fehlern) und dann das .ps1-Script geladen. Dann reicht es, auf die Script ausführen-Schaltfläche der Symbolleiste zu klicken oder die Funktionstaste F5 zu drücken. Die Ein-/Ausgaben werden im unteren Konsolenfenster angezeigt. Durch die absoluten Pfadangaben im Script funktioniert dieses auch, wenn es mit administrativen Rechten läuft – es wird der richtige Profilordner gefunden.

Die beiden PowerShell-Varianten samt einer kleinen Readme.txt findet ihr als PowerShell-EventViewer.zip zum Download (ich habe das Zeugs für einen heise-Artikel erstellt).

Vielleicht hilft es dem einen oder anderen Administrator weiter. Falls was übersehen wurde, könnt ihr ja Kommentare hinterlassen oder Ergänzungen vornehmen.

PS: Der Artikel Juni-Sicherheitsupdates sabotieren Ereignisanzeige in allen Windows-Versionen ist jetzt bei heise im Newsticker erschienen. Gab dort diesen Kommentar, bei dem ich mir die Frage stelle, ob das so bei den Admins gehandhabt wird?

Ähnliche Artikel:
Windows 7-10: Ereignisanzeige hängt nach Juni 2019-Update (KB4503293/KB4503327 etc.)


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Problemlösung, Tipps, Windows 10, Windows 7, Windows 8.1, Windows Server abgelegt und mit , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

14 Antworten zu Tipp: PowerShell-Workarounds für Juni-Bug der Windows-Ereignisanzeige im Detail

  1. Jörn Walter sagt:

    Wer seinen Event Viewer schnell wieder flott bekommen möchte, der benennt den Ordner Views einfach um:

    C:\ProgramData\Microsoft\Event Viewer\Views_old

    Event Viewer wieder starten und der Ordner Views wird neu (Default) angelegt.

  2. Dalai sagt:

    Um sich die Definition und nötige Anpassung der Variablen $account zu sparen, kann man auch die in der PowerShell vorhandenen Funktionen nutzen, um direkt auf das Profil des Nutzers zuzugreifen:
    Get-ChildItem "$env:LocalAppData\Microsoft\Event Viewer\Views" ….

    (Diese Änderung müsste natürlich an beiden Stellen im Skript erfolgen.)

    Siehe auch z.B. https://stackoverflow.com/questions/10132883/getting-the-path-of-appdata-in-powershell

    Ja, beide Methoden haben ihre Vor- und Nachteile. Mit $account lassen sich die Ansichten fremder Konten auslesen/benutzen.

    Grüße

    • Günter Born sagt:

      Hatte es nicht im Text geschrieben – es gab bei mir zwei Gründe, warum ich mit der Variablen gearbeitet habe: a) quick & dirthy und b) mit dem fest verdrahteten Pfad funktioniert das Script aus diversen Benutzerkonten, solange das angegebene Zielkonto die Custom Views enthält. Wertet man die Umgebungsvariable für das aktuelle Benutzerkonto aus, muss sichergestellt sein, dass dort auch die 'Benutzerdefinierte Ansichten'-Einträge abgelegt sind. Ist letztlich eine Design-Entscheidung.

  3. 1ST1 sagt:

    Sehr nützliches Script. Wollte mich eigentlich kommende Woche hinsetzen und selbst mit dem MS-Fragment rumspielen. Das hier sieht besser aus. Danke dafür. Aber ich habe da noch eine Idee, schön wäre es, wenn man über dieses Script auch die Events auf anderen Rechnern im Netz auslesen könnte, so wie es mit der Computerverwaltung auch geht…

  4. Joe_Gerhard sagt:

    Chapeau! Das ist weit vorne, lieber Herr Born, danke sehr für die Mühen!

  5. Sansor sagt:

    Was für Admins auch als Workaround hinhalten könnte:
    Alle Geräte bis auf eines Patchen bzw. Anzahl benötigter "Arbeitsgeräte" für Eventviewer. Von diesem per Remote-Konsole auf die gepatchen zugreifen. Da funktionieren die Benutzerdefinierten-Ansichten auch weiterhin.

  6. RST sagt:

    Hinweis: PowerShell Set-ExecutionPolicy Unrestricted oder Signatur nötig, um PS1-Dateien zu starten.

  7. Dekre sagt:

    Positive Nachricht – nach einer Woche funktioniert diese wieder!

    Gestern Nacht kam Preview KB4503277. Habe es heute installiert und die Ereignisanzeige funktioniert wieder. Das bei Win7 pro 64bit.

    Ergo – Alle Spielereien können beendet werden.

Schreibe einen Kommentar

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.