You probably read in the documentation that Event Log Explorer provides 5 ways to filter events. In this article, I will try to explain when you should use one or the other way of filtering.
First, we can arrange filters on applying time:
- Pre-load filter. This filter applies to the event log before loading. Only the required events will be loaded.
- On-load filter. This filter applies to the event log at the loading stage. While loading, Event Log Explorer will check if an event fits the condition and filters event out.
- After-load. This filter applies to the event log after loading.
Pre-load filter is implemented as an XML structured query. Select View->XML Query from the main menu to set this filter. Like Windows Event Viewer you can use a full form of XML Query, but you can also use a short XPath expression. You can find more information about XML Queries at https://msdn.microsoft.com/en-us/library/windows/desktop/dd996910(v=vs.85).aspx
Pros: Works fast and relies on Windows Event Log service. Minimizes network traffic and memory consumption.
Cons: It’s easy to make mistakes when creating complex filters.
When to use: Use it mainly to create a base filter to filter inessential events out.
*[System[(Level=1 or Level=2 or Level=3)]]
This filter displays only Warning, Error and Critical events.
On-load filter is implemented as log loading options feature. Use View->Log Loading Options to access Log Loading Options dialog. Alternatively you can enable default log loading options in Preferences.
Pros: Works fast, minimizes memory consumption.
Cons: Doesn’t filter by descriptions.
When to use: Like XML filter, you can use On-load filter as a base filter. I would recommend use this filter events by age. If you need to display a number of the latest events, On-load filter is the only option for you.
This filter displays events with Event ID between 4680 and 4689 registered within the last 7 days.
After-load filters are implemented as a general filter, linked filter and quick filters.
Select View->Filter to set a general filter or Advanced->Linked Event Filter to set a linked filter. You should use linked filters only for events that has one common field in event description. You can read more about linked filter usages in this article.
When using after-load filters, Event Log Explorer loads event first and then applies the filter. This gives you ability to reapply or remove filters to the originally loaded list of events. E.g. if you loaded a list from another computer and then this computer goes offline, you can still work with the log and filter events.
Pros: You can filter by virtually any criteria, including event description. You can reuse filters and manage filter library.
Cons: It doesn’t work as fast as pre-load or on-load filters because it loads all events first and then filters them. Consumes more memory than On-load filter.
When to use: You should use this filter whenever you are unable to use other filters (e.g. when you filter by descriptions) or when you need to apply different filters to the same event log.
This filter displays events with ID=4689 (process termination) for process name=chrome.exe
Quick filter is a special kind of after-load filter to refine events by a single criterion you can see on the screen. Just click right mouse button on a cell in the list view and use this cell as a template. After applying quick filter, you can continue applying quick filters – they will be applying altogether.
Pros: Easy to use and quick to apply. Non-persistent.
Cons: You can create only simple filters. Non-persistent.
As you can see, I attributed “Non-persistent” to both pros and cons. After each refresh of event log view or applying general or linked filters, Event Log Explorer resets quick filters. Sometimes it’s good because quick filters are commonly used to display specific data just for a short time, but sometimes users may want to keep filtered data between refreshes or event between Event Log Explorer sessions.
When to use: We recommend using quick filters when you browse events, find an interesting event and you want to check the other occurrences of this event.
This filter displays events with EventID = 1001
All these filters work independently, so you can combine them. E.g. you can filter out informational events using XML query ( *[System[(Level != 0 and Level != 4) ]] ). Then you can set on-load filter by a specific event source, e.g. Microsoft Antimalware. Then using general filter you can filter by event description, specifying path to a file as a filter criterion. And finally, you apply quick filters using event date to view how many events of such a kind was recorded in the log.