Filtering Trace Results
After you retrieve data in a Trace Session, import data through a Browse Session, or load data using the Quick Open or Recent Files features, you will typically analyze your trace results in one of the Message Analyzer data viewers, such as the default Analysis Grid. As part of analysis, it is likely that you will need to manipulate the trace results to expose specific information that you want to examine. In Message Analyzer, the primary method for isolating specific data during analysis is to apply a View Filter. A View Filter is a Filter Expression that you can specify in any of the following ways:
Select a predefined Filter Expression from the View Filter Library that is provided with your Message Analyzer installation.
Manually configure a Filter Expression in the View Filter group text box on the Ribbon of the Message Analyzer Home tab. To learn more about manually configuring Filter Expressions, see Writing Filter Expressions.
Right-click a column field in the Analysis Grid viewer to display a menu that enables you to add the corresponding field value as a Filter Expression. For example, you can right-click an address in the grid under the Destination column and then select the menu item Add “Destination” to filter to configure the destination address that you right-clicked as your Filter Expression.
After you specify a Filter Expression for the data in a particular session viewer tab and you click the Apply Filter button, the filter isolates the message data in the session viewer tab that meets the filtering criteria that you specified, such that only those messages are visible. However, a View Filter does not modify the original data set, as Message Analyzer persists the full data set such that you can redisplay it whenever you remove the specified View Filter. To undo the results of a View Filter that you applied to a set of messages displaying in a session viewer tab, click the Remove button in the View Filter group on the Ribbon. If you also want to remove the filter text itself from the View Filter textbox at the same time that you remove the filter results from the message set, click the down arrow to the right of the Remove button and select the Remove and Clear Text menu item. In addition, if you need to determine whether the current set of trace results had a View Filter applied, or if you want to replace the current text in the View Filter text box with the currently applied filter, click the drop-down arrow to the right of the Remove button in the View Filter group and select the Reset Text to Applied Filter menu item.
Note After you apply a View Filter, Message Analyzer indicates the number of messages that passed the filtering criteria by providing an indication next to the Available label in the lower-left corner of the UI.
Whenever you apply a predefined or manually configured View Filter, Message Analyzer conveniently persists the filter text that you specified for future use. You can access any filter that you previously applied by clicking the History button and selecting the filter from the drop-down menu that displays. In the History list, previously applied filters are displayed in chronological order, with the most recent applied filter as the first one in the list.
The central Filter Expression Library contains predefined filters that are provided with your Message Analyzer installation. In the Library, these Filter Expressions are contained in 10 different categories, in addition to an Examples category that contains an example filter that you can modify as required, so you can get started with developing Filter Expressions of your own. These categories and the filters they contain are described in the sections that follow.
This filtering category contains various transport layer filters that isolate TCP messages based on various criteria such as TCP ports, flags, window size, and options, as follows:
tcp.port == IANA.Port.HTTP — enables you to filter for HTTP over TCP traffic in either direction. You can also substitute a port number in this expression, for example, “tcp.port == 80”.
TCP.SourcePort in [
, 6609, 6610] — this filter passes all TCP messages that have a source port of 6608, 6609, or 6610. Note that the italic source port numbers in this expression are unassigned ports that serve as placeholders only.
— this filter passes TCP messages having a receive window size that is less than 1000. This Filter Expression does not take TCP Window Scaling into account, and therefore it is based on the default TCP window size value.
TCP Window Scaling increases the TCP receive window size above its default maximum value of 65,535 bytes for better throughput, for example, in cases where a receiver is overwhelmed with high message volumes such as a web server might be.
Note If you encounter a bottleneck, it might be caused by a small TCP receive window size that should be increased above the default setting by using a tool such as netsh. Windows 7, Windows 8, Windows 8.1, and Windows Server 2012 operating systems provide a Receive Window Auto-Tuning Level configuration that is set by default to “Normal”, which allows the TCP receive window size to grow automatically to accommodate most conditions. If TCP Auto-Tuning is disabled, the receive Window size is limited to the default size of 65,535 bytes (64 KB).
tcp.options — this filter passes only the TCP messages that have TCP options defined.
tcp.syn == true — this filter passes TCP messages that have their SYN bit set (0x02). If you want to pass all TCP messages that specify the SYN field, you can drop the Boolean evaluation and apply the Filter Expression as: “
Note Although there is a Segment message type and a Flags container in the upper hierarchy for the SYN flag, it is unnecessary to specify a fully qualified expression such as “
TCP.Segment.Flags.SYN”. In the Filtering Language, the dot notation is commonly used to traverse the message type-hierarchy, which is shown in the Column Manager. A dot (.) in a Filter Expression means the filter should find any entity at any depth in the hierarchy, hence in this example:
tcp.syn==true. However, to improve performance, you can create an explicit path that uses colons, as indicated in the text of the earlier Filter Expression
TCP::Flags:SYN == true.
Remove Noise Category
This filtering category contains filters that remove unwanted messages so that you can display a more streamlined message set.
WiFi.Type !=0 — removes Wi-Fi noise by filtering out beacons.
!(*Port in [3389, 1494, 1503]) — removes all remote desktop messages that traverse ports 3389, 1494, and 1503 in either direction, for various remote desktop communication protocols.
File Sharing Category
This filtering category contains several examples that you can use to filter trace results for SMB messages with a Filename field defined, SMB messages with diagnosis errors, or any file sharing traffic captured on TCP port 445:
*SMB.FileName ~= "" OR SMB2.FileName ~= "" — this filter passes only SMB and SMB2 messages that have a FileName field defined, in which the field value is not equal to an empty string. This Filter Expression is not the same as
SMB.FileName != "" OR SMB2.FileName != "", which returns non-SMB traffic as well. By using the tilde (~) character in this filter, you ensure that only SMB traffic is returned.
SMB#DiagnosisLevels — this filter passes all SMB messages that have parsing errors. This filter is equivalent to the expression
SMB && #DiagnosisLevels. You can also apply any of the enumeration values specified in Table 6 to this Filter Expression. For example, you could specify
SMB#DiagnosisLevels== Standard.DiagnosisLevel.Warningto return all SMB messages that contain a Warning diagnosis level.
*Port == IANA.Port.SMB — this filter passes messages from any protocol that has a top-level source or destination Port field equal to 445, including TCP and UDP. It also returns any top-level protocol that has a field or property named “Port”.
General Examples Category
This filtering category contains an example of how to AND two expressions together and an example of how to specify an explicit path to a field value in the TCP message hierarchy:
HTTP and !UDP — this filter passes all messages that do not have HTTP over UDP.
TCP::Flags:SYN == true — this filter uses an explicit path expression to pass TCP messages that have their SYN bit set (0x02). Note that the missing value between the double colons (::) is the Segment message-type specifier.
Tip You could also specify the equivalent of this Filter Expression as: “
TCP:Segment::SYN==true” or even “
TCP:::SYN==true”, to obtain an identical filtering result. At a minimum, an explicit path expression should specify a protocol or module as the first entity in the left-side expression and the field for which you are searching in a particular message hierarchy as the last entity in the expression, separated by an appropriate number of colons to delimit any skipped hierarchical entities. However, you should specify all entities in an explicit path for the best performance.
This filtering category contains filters that isolate HTTP messages with errors, specified address text, and a specific stack configuration.
HTTP.StatusCode >= 400 — returns HTTP client and server error messages that have a StatusCode that is greater than or equal to 400.
HTTP.Uri contains "msn" — isolates HTTP addresses that contain the text "msn". The filtering criteria are both case- and encoding-insensitive.
HTTP\TCP.Port == IANA.Port.HTTP — passes messages where HTTP is directly above TCP, as defined by the stack path specification “
HTTP\TCP.Port”. By using the stack path specifier “\”, you can increase the specificity of your Filter Expressions.
Address Filtering Category
This filtering category contains several filters that isolate data based on Ethernet, IPv4, or IPv6 addresses, as follows:
*Address==02-01-0A-01-01-64 — filters out all messages except those that are intended for a specified MAC address, such as that of an Ethernet adapter.
IPv4.Address in 10.1.0.0/16 — filters for a particular IPv4.Address in a subnetwork generated by a specified subnet mask, which in the example is indicated by 16 (=255.255.0.0).
or *Address ==
— filters out all messages except those that contain a Source or Destination address that matches either the specified IPv4 address or IPv6 address value. *Address could also specify an Ethernet address.
Note By using the expression “*Address”, you can mix IPv4 and IPv6 addresses in this Filter Expression.
— filters out all messages except those that contain a Source or Destination address that matches the specified IPv6 address value.
— filters out all messages except those that contain a Source or Destination address that matches the specified IPv4 address value.
Note Before applying any of these filters, you should substitute your actual search address for the italic values in these Filter Expressions. The same is true of any predefined Filter Expression that has placeholder values.
— filters out all IPv4 messages that contain a Source or Destination address that matches the specified IPv4 address value. Use of the tilde (~) character ensures that you will only return IPv4 traffic. Otherwise, other traffic would not be blocked.
For example, if you specified the Filter Expression as
IPv4.Address != 192.168.1.1or
!(IPv4.Address == 192.168.1.1), all protocol messages that do not meet this criteria are returned, which means you would get all messages that are not IPv4 messages in addition to the target IPv4 traffic. However, as an alternative, you could add “
&& IPv4” to either expression if you want to pass only IPv4 messages.
Note The Filter Expression
!(IPv4.Address == 192.168.1.1)is semantically equivalent to
IPv4.Address != 192.168.1.1. For more details about the use of the “!” operator, see Other Filtering Considerations.
This filtering category contains an LDAP filter that removes all traffic that transits the LDAP port.
!(*Port == IANA.Port.LDAP) — removes all LDAP port traffic, regardless of the protocol. Port represents either SourcePort or DestinationPort for UDP and TCP messages, or any protocol with a field or property named Port. The asterisk in the expression “*Port” indicates that the filter should look at any protocol that defines a field or property named “Port” and filter out any LDAP port traffic that might have been invoked by that protocol. This filter will also pass messages from any protocol where a Port field is nonexistent.
Contains Filters Category
This filtering category contains filters that you can use to search for various strings and values in your trace results. You can search for messages that contain specified text in case-sensitive and case-insensitive searches. You can also locate hexadecimal patterns with this type of filter:
] — this filter passes messages that contain the specified hexadecimal pattern, which in this example represents the ASCII characters for “SMB”.
*Summary contains “error” — this filter searches the Summary column for all messages in the Analysis Grid that contain the text "error".
contains "Microsoft" caseSensitive — this filter performs case-sensitive filtering that passes all messages containing the specified “Microsoft” search text. The default insensitive encoding will match ASCII, Unicode, or any other encoding type.
contains "Microsoft" encoding ASCII — this filter performs case-sensitive filtering that passes all messages containing the specified search text in the supplied query encoding. The query encoding value can be any of the following: ASCII, UTF7, UTF8, Unicode, UTF32, BigEndianUnicode, and Base64.
contains "Microsoft" — this filter performs case-insensitive filtering that passes all messages containing the specified search text.
This filtering category enables you to identify messages that have parsing errors. There are two types of filters in this category that reflect OPN parsing errors. These consist of DiagnosisTypes, which describe the source of errors that can occur during parsing, and DiagnosisLevels, which indicate parsing error severity level:
#DiagnosisTypes==2 — this filter passes any messages that contain validation type diagnosis errors that occurred during the OPN message ValidationCheck, as part of the parsing process. A validation error is a soft error, meaning that it is not severe enough to halt the parsing process. Validation errors typically occur when a message deviates from associated protocol specifications, which can include occurrences such as out-of-range values, invalid collection sizes, data element constraint violations, and so on.
DiagnosisTypes is described in the OPN language as a flag pattern, which is a special type of enum. The table that follows specifies the enumeration values of the DiagnosisTypes enum that you can use in a DiagnosisTypes filter. Friendly enumeration names are given along with their equivalent integer values. You can specify the enum values in either format as right-hand side values in this Filter Expression.
Table 5: Enum Values for DiagnosisType filters
Filter Expression with Friendly Enum Name Filter Expression with Integer Enum Value Description
#DiagnosisTypes == Standard.DiagnosisType.Application
Filters for messages that contain Application-type diagnosis errors.
#DiagnosisTypes == Standard.DiagnosisType.Validation
Filters for messages that contain Validation-type diagnosis errors. A Validation error is an indication that a message does not align with its protocol definition.
#DiagnosisTypes == Standard.DiagnosisType.InsufficientData
Filters for messages that contain InsufficientData-type diagnosis errors. An InsufficientData error is an indication that message data was lost, for example, when Message Analyzer is grouping messages as an operation or when performing data reassembly.
#DiagnosisTypes == Standard.DiagnosisType.Parsing
Filters for messages that contain Parsing-type diagnosis errors. A Parsing error is an indication that parsing failed when Message Analyzer attempted to decode invalid message data.
#DiagnosisLevels — this filter passes all messages that have a diagnosis-level error. This Filter Expression is semantically equivalent to
#DiagnosisLevels != nothing. If you want to be more specific, you can specify different enumeration values to filter for certain diagnosis levels. In the table that follows, friendly enumeration names are given along with their equivalent integer values that you can include as right-hand side values in this Filter Expression:
Table 6: Enum Values for DiagnosisLevel filters
Filter Expression with Friendly Enum Name Filter Expression with Integer Enum Value Description
Filters for messages that contain an Error-diagnosis level.
Filters for messages that contain a Warning-diagnosis level.
Filters for messages that contain an Information-diagnosis level.
Note In the Filtering Language, DiagnosisLevels is a global annotation, meaning that it is applicable to any OPN message. The character “#” provides access to an annotation, as differentiated from other filters that use a dot (.) operator to enable access to a field.
This category contains an example of filtering for USB transfer messages that contain errors:
Microsoft_Windows_USB_USBPORT.fid_URB_Hdr_Status ~= 0 — this filter passes all messages from the Microsoft-Windows-USB-USBPORT provider that contain the Fid_URB_Hdr_Status field with a value not equal to zero, indicating an error condition. Note that this Filter Expression is not the same as
Microsoft_Windows_USB_USBPORT.fid_URB_Hdr_Status != 0, which returns all messages captured by the provider, whether it had the specified field or not.
The Examples filtering category exists under My Items, where all View Filters that you create and save with the Edit Filter dialog are displayed. The Edit Filter dialog is accessible by clicking the New Filter item in the View Filter Library drop-down menu. The Examples category contains a single filter that you can modify as you like, so that you can get started with creating your own filters.
Note All Filter Expressions that you create become part of a centralized Library that is available in Browse Session configuration as the Selection Filter Library, in Trace Session configuration as the Trace Filter Library, and in an Analysis Session as the View Filter Library.
The Filter Expression that is included as a startup example is specified as follows:
HTTP — this filter will return all top-level HTTP operations and any other messages where HTTP exists in the stack.
You are encouraged to browse through the HTTP message hierarchy with the Column Chooser to review the types of fields that you can specify in an HTTP filter. You can also make use of the Filtering IntelliSense feature that kicks in and exposes the message hierarchy when you type a dot (.) after “HTTP” in the Filter Expression text box of the Edit Filter dialog. You can open this dialog by right-clicking the HTTP example and selecting the Edit item in the context menu that appears.
Sharing Filter Items
You can also share View Filters with other users, including any that you create, by exporting them as a Filter asset collection through the Message Analyzer Sharing Infrastructure. The features of the Sharing Infrastructure enable you to export and import Filter items to and from a designated user file share or other location, respectively, or to a user feed that you create from the Settings tab on the Message Analyzer StartPage. To learn how to manage View Filters from the Manage Filters dialog, see Applying and Managing View Filters.