Filters

Request Filtering

Similarly to any reasonably good event monitoring tool, IRPMon is capable of filtering out requests the user defines as uninteresting. Similarly to some Sysinternals tools, such as Process Monitor or DebugView, requests can be both filtered and/or highlighted.

Filter Characteristics

Each filter has the following characteristics:

• Name. Uniquely identifies the filter. Two filters with the same name are not allowed.
• Type. defines type of requests the filter applies to. Filters can apply to either one, or all request types.
• Column. Each request can be considered as one row within a table. In other words, it consists of multiple values assigned individually to columns. A filter can work only with one column.
• Constant. A filter "compares" this value to one defined by the Column characteristics to determine whether the given request matches the filter.
• Operator. Defines how the column and constant values should be "conbined" to determine whether the filter matches.
• Action. Determines what to do with a request on which the filter matches. It is possible to include the request in the list, exclude it from there, just higlight its row, or pass the request to another filter.
• Higlight color. If the filter makes the request included in the request list, or the filter action is set to Higlight, the higlight color defines its background. By default, this color is set to white, meanining no higlighting (since the background color of the request list is white).
• Ephemerality. Ephemeral filters are never saved on disk.

Each filter can be disabled which excludes it from the matching against requests. Also, result of its operator can be negated.

The pass to filter action may be used to connect multiple filters into a chain. Each filter can be member of at most one non-trivial chain (trivial chains have length of one). Disabling (or enabling) a filter within a chain leads to disabling (or enabling) of the whole chain. All filters in one chain are either enabled or disabled.

Filter Matching

All filters are stored in a list that is traversed from its top to its bottom. The match operation is performed for each incomming request and is driven by the following rules:

• disabled filter chains are skipped,
• if a filter chain matches the request, defined action is performed and the evaluation continues but all matching filter chains are ignored excepts those with ending action of Higlight.
• If a filter chain does not match, evaluation continues at the beginning of a filter chain that is next down the list.
• If none of the chain matches and all filter actions are either set to Include, Highlight, or Pass, the request is excluded,
• if none of the chain matches and all filter action are either Exclude, Highlight or Pass, the request is included.

From the logical point of view, the formula defined by the filter chains has a DNF form.

The Highlight action does not affect the overall decision whether to include or exclude the given request. It only changes background color of the row representing the request. Since filters with this action are evaluated whenever the overall decision had been made o not, they allow further distincions between requests with various characteristics. Since only included requests have their rows within the request list view, the highlight color has no meaning for excluded requests.

User Interface

In order to get to the form responsible for filter settings, press the Request -> Filter/Higlight item in the main menu. All changes made to filters take effect only if you close it via the Ok button. This icnludes storing the new settings to disk into the filter.ini file.

Figure 1: Filter definition window

To remove a filter, select it and press the Remove button. selected filters can be moved up or down the list using buttons with respective names. To add a new filter, define all its characteristics and press Add. If the user wants to change attributes of an already existing filter, she needs to select it and use the Apply button to make the change.

Filters can be enabled and disabled directly by clicking to checkboxes before their names. Double-clicking to a filter copies all its characteristics into form controls which may be useful when the user intends to create a new filter based on existing one.

Filters are uniquely identified by their names; two filters with the same name are not allowed. Names either can be specified explicitly by the user, or are automatically generated based on filter characteristics. Since the generated names are quite long, the user is advised to always use the former option.

Removing a filter that is part of a bigger chain does not break the chain, just the filter in question is removed.

Defining Filters from the Main Window

Figure 2: Popup menu for quick filtering the request list view

The popup menu associated with the request list view can be used to quickly define filters. It contains three sorts of menuitems allowing the user to include, exclude, or highlight requests based on the value of the selected request and its value for the column where the mouse pointer currently resides. The filters created this way are ephemeral and are applied immediately after pressing the respective menu item.

Including and excluding filters are placed to the front of the filter list, higlighting ones to its back. Depending on the selected menu item, type of the new filter either equals the type of the selected requests, or applies for all requests.