Tips: Make Get-WinEvent cmdlet perform quicker

Although September was a busy month, I’d like to share a nice tips that makes Get-WinEvent cmdlet perform quicker.

First, start with the FilterHashTable parameter. It’s easier to write.

$HT = @{
 LogName = 'System';
 ProviderName = 'Service Control Manager' ;
 Id = 7040 ;
 Data = 'Windows Modules Installer' ;
 StartTime = (Get-Date).AddDays(-365) ;
Get-WinEvent -FilterHashtable $HT -MaxEvents 1

Now, capture the XML query from the Verbose stream.
To achieve that, I just add the Verbose switch to the previous command

Get-WinEvent -FilterHashtable $HT -Verbose -MaxEvents 1


I copy/paste the XML query into a here-string and use it as input for the FilterXml parameter like this:

Get-WinEvent -FilterXml @'
 <Query Id="0" Path="system">
  <Select Path="system">*
  [System/Provider[@Name='service control manager'] and
  (System/TimeCreated[@SystemTime&gt;='2014-09-06T10:20:22.000Z']) and 
  (EventData/Data='Windows Modules Installer') and
'@ -Verbose -MaxEvents 1

As you can see, when you use the FilterXml parameter, there isn’t any overhead where the hashtable is first converted to a XML query.

The result is that the FilterXml will perform faster than the FilterHashTable parameter


… and you don’t have to figure out how to write the XML query 😀

Max memory for remote shell

The other day I was investigating a “locked” workflow .

The network tab of procexp.exe revealed what remote computer was locking it.
It was actually a Windows 7 computer that had the following 2 events in its log.



To “unlock” the workflow, I just stopped the WinRM service on the remote computer, waited for the workflow to end correctly and finally restart the WinRM service on that remote machine.

c:\windows\system32\sc.exe \\RemoteComputerName stop WinRM

What happened on this remote computer that caused the workflow to stop and wait for it?

It appeared that the code running on the remote computer was the culprit.
The code was supposed to get the total count of a specific event. What makes this computer so special was that it had 45469 of these events and the remote shell on this Windows 7 computer just hit the default maximum memory assigned.

After fixing winrm.cmd to work in my environment, I was able to do:

C:\winrm.cmd get winrm/config/winrs -machine:RemoteComputerName -format:#text
c:\winrm.cmd set winrm/config/winrs @{MaxMemoryPerShellMB="512"} -machine:RemoteComputerName

I’ve increased the default Maximum Memory for a remote shell from 150MB to 512MB


BPUG / August 28, 2015 / meeting summary and presentation materials

I went to the Basel PowerShell User Group that my fellow PowerShell MVP, Stéphane Van Gulick (@Stephanevg) organised.

I gave a presentation about Nano Server 😀

The presentation was a quick introduction directly inspired by this 20 minutes talk from Jeffrey Snover with Jeremy Chapman at Ignite early May 2015:



I gave also a quick demo about installing a Nano Server into a virtual machine through WDS (Windows Deployment Services). It’s directly inspired from the following article published in PowerShell Magazine, except that the code was “adapted” to work with the recently published Windows Server 2016 TP3.

Amanda Debler (@texmandie) who gave a preview of her presentation about Skype for Business for the 2nd Summit in Europe, took a nice picture during my demo 😀


And when you provide the correct credentials and authenticate on the Nano box, you’ll see

Bonus: here are 4 essentials links about NanoServer you should bookmark:

And… here is the code on github: