Экспорт (0) Печать
Развернуть все
EN
Данное содержимое не доступно на вашем языке, используйте версию на английском языке.

Filtering Live Trace Session Results

After you capture data in a Live Trace Session, load data through a Data Retrieval 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 viewer. 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, a primary method for isolating specific data during trace results 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 centralized user Library, which is accessible from the toolbar of the View Filter Tool Window.

  • Manually configure a Filter Expression in the text box of the View Filter window. 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 context menu that enables Message Analyzer to automatically configure a View Filter with the corresponding field value. For example, you could right-click an address value 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 in a Filter Expression, which might look similar to the following: WFPCapture.Destination == 192.168.1.1.

Applying and Removing a View Filter
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 window. If you want to also remove the filter text itself from the View Filter text box at the same time that you remove the filter results from the message set, click the down arrow on the Remove button and select the Remove and Clear Text 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. This enables you to access up to the last ten applied filters by clicking the History button and selecting the filter from the drop-down list 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.

Assessing Predefined Filter Expressions
The central Filter Expression Library contains predefined filters that are provided with every 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. You are advised to assess these filters prior to applying them so that you will be able to more clearly recognize their effects upon trace results.

File Sharing Category

This filtering category contains several examples that you can use to filter trace results for SMB messages with diagnosis errors, SMB messages with a Filename field defined, or any file sharing traffic captured on TCP port 445:

  • 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 7 to this Filter Expression. For example, you could specify SMB#DiagnosisLevels== Standard.DiagnosisLevel.Warning to return all SMB messages that contain a Warning diagnosis level.

  • *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.

  • *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.

USB Category

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.

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:

  • *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.

  • contains $[ 534d42 ] — this filter passes messages that contain the specified hexadecimal pattern, which in this example represents the ASCII characters for “SMB”.

Diagnosis Category

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 DiagnosisLevels, which indicate parsing error severity level; and DiagnosisTypes, which describe the source of errors that can occur during parsing:

  • #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 7: Enum Values for DiagnosisLevel filters

    Filter Expression with Friendly Enum Name Filter Expression with Integer Enum Value Description

    #DiagnosisLevels==Standard.DiagnosisLevel.Error

    #DiagnosisLevels==1

    Filters for messages that contain an Error-diagnosis level.

    #DiagnosisLevels==Standard.DiagnosisLevel.Warning

    #DiagnosisLevels==2

    Filters for messages that contain a Warning-diagnosis level.

    #DiagnosisLevels==Standard.DiagnosisLevel.Information

    #DiagnosisLevels==4

    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.

  • #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 8: Enum Values for DiagnosisType filters

    Filter Expression with Friendly Enum Name Filter Expression with Integer Enum Value Description

    #DiagnosisTypes == Standard.DiagnosisType.Application

    #DiagnosisTypes==1

    Filters for messages that contain Application-type diagnosis errors, for example, an application-related or network communication issue.

    #DiagnosisTypes == Standard.DiagnosisType.Validation

    #DiagnosisTypes==2

    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

    #DiagnosisTypes==4

    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 attempting to group messages into an operation or when performing data reassembly.

    #DiagnosisTypes == Standard.DiagnosisType.Parsing

    #DiagnosisTypes==8

    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.

HTTP Category

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, for troubleshooting purposes.

  • 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).

  • IPv4.Address == 192.168.1.1 — 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.

  • IPv4.Address ~= 192.168.1.1 — 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.1 or !(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.

  • IPv6.Address == 2001:4898:0:FFF:200:5EFE:4135:4A7 — filters out all messages except those that contain a Source or Destination address that matches the specified IPv6 address value.

  • *Address == 192.168.1.1 or *Address == 2001:4898:0:FFF:200:5EFE:4135:4A7 — 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.

Remove Noise Category

This filtering category contains filters that remove unwanted messages so that you can display a more streamlined message set.

  • WiFi.FrameControl.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.

RegEx

Message Analyzer provides several regular expressions (RegEx) that you can use as View Filters, as follows:

  • regex "(?!000)([0-6]\\d{2}|7([0-6]\\d|7[012]))([ -]?)(?!00)\\d\\d\\3(?!0000)\\d{4}" — enables you to find a phone number pattern.

  • regex @"^([\w\.\-]+)@([\w\-]+)((\.(\w){2,3})+)$"— enables you to find an email address pattern.

  • regex @"^\d{3}-\d{2}-\d{4}$" — enables you to find a social security number.

  • regex @"\bthis\W+(?:\w+\W+){1,6}?that\b" — enables you to find the string “this” near the string “that”.

TCP Category

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 [ 6608 , 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.

  • 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: “tcp.syn”.

    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 Chooser. 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.

  • tcp.windowscaled < 1000 — this filter passes TCP messages having a receive window size that is less than 1000.

    Note that 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.

LDAP Category

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.

Examples Category

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 list. 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  Any Filter Expression that you create becomes part of a centralized Library and is available to you as Session Filter whenever you are configuring a Data Retrieval Session or Live Trace Session. Such a Filter Expression is also available to you as a View Filter whenever you are analyzing trace results in an Analysis Session. In addition, note that Filter Expressions that you create can contain an Alias or a Union, as appropriate.

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 items from your centralized filter Library 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 Start Page. To learn how to manage View Filters from the Manage Filters dialog, see Applying and Managing View Filters.


More Information
To learn more about using Aliases in Filter Expressions, see Performing Message Analyzer Operations with Aliases.
To learn more about using Unions in Filter Expressions, see Performing Message Analyzer Operations with Unions.

See Also

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв
Корпорация Майкрософт проводит интернет-опрос, чтобы выяснить ваше мнение о веб-сайте MSDN. Если вы желаете принять участие в этом интернет-опросе, он будет отображен при закрытии веб-сайта MSDN.

Вы хотите принять участие?
Показ:
© 2014 Microsoft