Filtering events by description is one of the most asked questions to us. Some time ago I wrote an article devoted to this problem.
Recently we had to check all events in the security log linked with a certain file (let’s say, it’s winword.exe, C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE). The easiest solution was to use Filter command and type file name in the “Text in description” line.
Commonly this works fine, but it scans all records in the log, forms event description for each event and looks for this phrase in the description. Forming event descriptions may require loading extra modules from the target computer (or a computer you designated as a description server) to load the description template. And although Event Log Explorer caches and reuses description templates, such filtering may take long time on large logs.
As a rule, security log stores file names, process names and other details in separate XML elements under EventData and all these elements are named “Data”.
So, we can make an XPath query to a log which compares each Data element with our search string. This query will look like:
*[EventData[Data="C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE"]]
To apply this filter, open Security event log, select View->XML Query, type your XPath expression and click OK.
It executes swiftly and doesn’t load network when connecting a remote computer.
But what about the other logs? Many Windows events doesn’t have EventData element, but have UserData (some events have DebugData, BinaryEventData, or ProcessingErrorData instead). UserData commonly has an extra level of XML elements, so to query event by UserData, we should use the following XPath request:
*[UserData[*[*="C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE"]]]
And what if you want to check for the same file name in several logs, e.g. in Security, System and Application logs? It can be also done with one XML query:
<QueryList>
<Query Id="0">
<Select Path="Security">*[EventData[Data=
"C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE"]] or
*[UserData[*[*=
"C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE"]]]
</Select>
<Select Path="System">*[EventData[Data=
"C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE"]] or
*[UserData[*[*=
"C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE"]]]
</Select>
<Select Path="Application">*[EventData[Data=
"C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE"]] or
*[UserData[*[*=
"C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE"]]]
</Select>
</Query>
</QueryList>
Here is the result of this query on my machine:
Advantages of this method
Such XML query provides great performance and works not only with Event Log Explorer, but with Windows Event Viewer or other event log programs which support XML queries.
Some applications and services logs don’t display all the information about event in the description, but still store their details under UserData or EventData elements (I described one of such logs in this article). So, filtering by description won’t work for such events, but the XPath queries will.
Limitations
Although this approach lets you filter quickly by description details, it is limited by XPath 1.0 implementation for event logs. E.g. you can use only 3 functions: “position”, “Band” (binary and) and “timediff”. Function “contains” is not supported, so it’s impossible to filter just by filename (winword.exe). If you need to filter just by file name, you should use general filter by description.
Can we do something to bypass these limitations? I think so. Filtering by description parameters during log loading stage (and without forming descriptions) should work faster than general filter by description and it will be more flexible than Xpath. But it would be really great if Microsoft extends XPath functionality for event logs.
. If you hover mouse over this icon, you will see log names in the merged view.
