Tip: PowerShell workarounds for June bug in Windows Event Viewer

[German]I've gone into the bug in the Windows Event Viewer caused by the June 2019 patches. This article shows how to handle workarounds to using both the Event Viewer and 'Custom Views' on a machine via PowerShell.

Some Background about the issue

Windows security updates released from Microsoft in June 2019 are closing numerous vulnerabilities, but also causing headache for administrators. As soon as the updates have been installed, the Event Viewer crashes, if custom views are selected..

(Click to zoom)

As soon as the error has occurred once, the event viewer can no longer be used. The reason for this is that the Event viewer snap-in automatically tried to load the last custom view selected during the next start.

I've discussed that issue in detail within my German blog post Windows 7-10: Ereignisanzeige hängt nach Juni 2019-Update (KB4503293/KB4503327 etc.) – a shorter English version is Windows 10: Updates KB4503293/KB4503327 kills event viewer. The article explains which Windows versions and updates are affected (virtually all). And I had sketched a workaround how to fix the Event Viewer at least (but no custom views can be used afterward).

Why pick up the subject again?

The problem with the solution I outlined in the above articles was: With the workaround you can used the event viewer again and navigate and search in the events. But you can no longer define your own entries in the Custom views' branch – because this will immediately lead to a crash again.

Microsoft has published a workaround which is intended to read custom views using PowerShell. My problem with this approach: The support article KB4508640 is very tight.

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

Microsoft posted the above PowerShell fragment and a few hints how to use this function:

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.

Well, I dealt with PowerShell last time 6 or 7 years ago. And the colleagues from the writing guild are obviously not better positioned. I took a quick search and found some articles dealing about the event viewer bug – but the articles contains the sentence: 'Oh yes, there's a Microsoft workaround for PowerShell' – that's all.

That should work …

When I wrote an article about the Event Viewer bug for German IT magazine heise two nights ago, I thought 'let's see how the workaround works'. I opened a browser and the PowerShell console on a Windows 10 machine, copied the above code fragment from Microsoft's support article into the console window using Copy&Paste and pressed Enter. Then I only saw red – something went terrible wrong – and Microsoft's workaround wasn't a Fool-Proof solution. So I decided to get that workaround to work!

And wouldn't it be cool if you could do both: get custom views, but at the same time work with the Event Viewer and be able to look or filter for events? And it would be cool, if the workaround will be available as a clickable PowerShell module in a .ps1 file. Also a few explanations for dummies wouldn't be bad either.

Half an hour later, my solution was ready. The solution should bridge the time until a bug fix from Microsoft (announced for the end of June 2019) is available. It's a kind of helper crutch for annoyed administrators and corporate environments. I don't know if anyone needs it.

What the Microsoft Workaround Can Do

First a few words about the Microsoft workaround – probably intuitively clear to experienced administrators – but I first had to look at the script code and sort something. You can add the function call to the script and save it in a .ps1 file. The whole coded looks like this:

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

Only with the last statement is the PowerShell code working and executing the function get-EventViewer.

What the PowerShell script requires

This PowerShell script assumes that 'Custom Views' are defined globally for all user accounts on the machine (which are then stored in ProgramData).

This condition was not met on my test machine with Windows 10, so the PowerShell script would have made little sense. But if you define custom views globally, the event viewer crashes because of the bug. So you have to work completely with PowerShell.

How to use the script

The PowerShell script must be run with administrative privileges (Run as administrator) in the PowerShell console or in the PowerShell ISE. Then there should be no error messages.

(Click to zoom)

The script lists the global custom views it finds and then asks for the name of the custom view to display. If you type the name, the results are listed. The picture above shows the approach in PowerShell ISE – where I already used the modified script from the following approach.

Use Event Viewer and Custom Views

At this point I came up with the idea of whether it would not be possible to use both the Event Viewer and still read events via user-defined custom views. The rough idea was:

• Fixing the Event Viewer with the workaround described in the blog post Windows 10: Updates KB4503293/KB4503327 kills event viewer for global custom views (removing the custom view XML files).
• Then create local custom views under a default user account (copy the Views-XML files accordingly if necessary) – or use the approaches described in the Microsoft article Creating Get-WinEvent queries with FilterHashtable (I haven't tried).

The idea is as follows: If we launch the Event Viewer from a default user account via using Run as administrator, the snap-in runs in the context of the administrator account. If there are no global or local entries in 'Custom Views', the Event Viewer snap-in works. So a user can search in events, but isn't able to create user-defined custom views.

To display local custom views with events, use the PowerShell script under the default user account. Should allow a halfway comfortable working – I tested it here briefly, that worked as far as I saw.

Create and use local custom views

To use new entries under 'Custom Views' in the Event Viewer, it must be defined for the local default account. If you launch Event Viewer from a default account, the xml files of a new custom view is stored local within the user's profile. If the Event Viewer has been launched with Run as Administrator, the All Users check box at the bottom right ithin the Custom View dialog box must be unchecked when closing the dialog box.

I had already explained this in the blog post Windows 7-10: Ereignisanzeige hängt nach Juni 2019-Update (KB4503293/KB4503327 etc.). The Microsoft Management Console MMC.exe then stores the Event Viewer snap-in data in AppData sub directory of the local profile folder. Thus, the user-defined views only affect the local account (and only cause the Event Viewer to crash there).

Tip: You could also copy the global XML files such as Views_0.xml etc. into the local profile folder. Then you immediately have the old definitions. Within the Event Viewer you can create a maximum of one user-defined entry, because it crashes immediately afterwards. I have described the paths of the folders in the blog post linked above.

Modified PowserShell script for local user-defined views

You need a PowerShell module to access (the locally stored) custom views under this user account. Unfortunately, this does not work with the above Microsoft PowerShell fragment. But that's not a problem, you just have to adjust the paths to the Views-XML files accordingly.

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

The PowerShell script code above has been modified for reading views of the local user account. I have defined a $account variable to which I assigned the name of the user profile on my test machine (here MSKonto). The idea behind it: I'm able to specify a fixed account name, that contains the custom views of the Event Viewer, i.e. the PowerShell script works from various user accounts.

Important: The value of the variable (the part in " ") must be adapted to the profile name of the own computer under which the user-defined custom views were created in order for the script (LocalEventView.ps1) to work.

When the function is executed, it then accesses AppData in the user profile and reads the locally defined 'Custom Views'. These are listed and the user can then type in a view name to retrieve the custom view (see image below).

(Click to zoom)

I've launched the PowerShell ISE by Run as Administrator (with default permissions an errors occur) and then loaded the .ps1 script. Then it is enough to click on the Run Script button of the toolbar or press the function key F5. The inputs/outputs are displayed in the lower console window (see screenshot above). Due to the absolute path specifications in the script, this also works if it runs with administrative rights – the correct profile folder is found.

The two PowerShell variants together with a small Readme.txt (German and English) can be downloaded as PowerShell-EventViewer.zip. Just unzip the archive and read the readme.txt file.

Maybe it helps some administrators. If I've overlooked something, you can leave a comment.

Similar articles:
Windows 10: Updates KB4503293/KB4503327 kills event viewer
Tip: PowerShell workarounds for June bug in Windows Event Viewer
Fixes for Windows event viewer bug (June 2019)
Windows 7-10: Ereignisanzeige hängt nach Juni 2019-Update (KB4503293/KB4503327 etc.)