Export (0) Print
Expand All

Using the Filtering Features

The procedures in this section encapsulate the main functionalities described in the Filtering Message Data section. For each procedure, background scenario information is provided to set the context for the problem that each procedure will help to resolve. The background information describes common high-level issues that you might encounter, while the procedures demonstrate how you can use Message Analyzer to isolate relevant data with the use of filters and simplify your data assessment and problem resolving process. The examples in this section assume that persons running the procedures are network administrators, or are at least familiar with networking concepts.

The procedures are presented in the following subsections:

Filtering Imported Data — provides examples of the following:

  • How to apply a Selection Filter to data imported from a saved trace file to isolate and analyze HTTP request messages that were sent to a poorly performing web server from a specified client IP address, to discover possible reasons for such performance.

  • How to apply a Time Filter to data imported from log files that consolidate several message sources, so that you can view data in specific windows of time in which problems are suspected to have occurred.

Filtering Live Data — provides examples of the following:

  • How to collect data from a specific network interface by selecting an Adapter from which to capture data, for example, in cases where network adapters are on different networks or load balanced on the same subnet where traffic spans multiple adapters.

  • How to specify a WFP Layer Set filter that captures either inbound or outbound IP traffic only, in order to limit the number of captured messages.

  • How to specify a Trace Filter that isolates TCP messages, in an attempt to correlate slow file transfers or sluggish web page loading performance with TCP retransmission issues.

  • How to specify a Fast Filter—based on a port or client IP address—for a Firewall trace on a busy server where the responses are slow, in order to reduce captured message volume and lower the impact on server performance while still capturing sufficient data for analysis. Demonstrates the efficiency and performance advantages of Fast Filters that enable you to capture the least amount of data possible to resolve a problem.

  • How to specify the Web Proxy provider Hostname and/or Port filters to reduce captured traffic and isolate client messages sent to a specified web server that is very busy and is causing users to experience connection issues. Applies the specified filters to gather sufficient data for the assessment of possible connection problems, without imposing a high-volume data capture on a client computer that is overwhelmed with traffic. Assesses possible causes by examining HTTP StatusCode indicators for connection issues and errors.

Filtering Trace Results — provides examples of the following:

  • How to apply an Address and Port View Filter to Local Link Layer trace results and thereby remove unwanted lower-layer traffic to streamline the detection of virus signatures.

  • How to apply an HTTP View Filter to Firewall trace results that isolates all top-level HTTP traffic from a particular client computer, including all the related traffic of the underlying stack where a problem might occur in supporting the HTTP operations. Demonstrates the superior capabilities of Message Analyzer compared to its predecessor Network Monitor, which returns only HTTP headers in a similar scenario.

  • How to apply TCP View Filters to Firewall trace results to help expose the causes of TCP connection and data transmission issues such as lost TCP segments, slow data transmission rates, or broken TCP three-way handshakes.

  • How to apply an HTTP filter to Web Proxy trace results so you can isolate HTTP request/response messages and analyze HTTP StatusCodes and Reason phrases for evidence of a poorly performing web server.

Filtering with Color Rules — how to apply Color Rules to Firewall trace results and expose TCP and SMB diagnostic messages in order to prompt further and optional analysis of faulty or erratic file share access.

Note  In the procedures of this section, placeholders within angle brackets (<>) refer to values that you enter that are specific to your system/s. However, do not include the angle brackets in your entries.


Filtering Imported Data

This section provides examples of possible ways to filter data that is imported from saved trace or log files. The examples include the use of an HTTP Selection Filter that is applied to a saved trace file and an adjustable Time Filter that is applied to one or more log files.

Applying a Selection Filter to Imported Trace Data
The hypothetical high-level issue in this example is that a Network Administrator has client browsers that send requests to a web server that is being constrained, possibly by high message volumes, connection problems, or other issues. The administrator imports data from one or more trace files containing messages that were originally captured on one or more client computers by using a Firewall trace that reduces lower-layer network noise. The example assumes that the trace ran over an adequate time period to reproduce the connection issues that clients are experiencing. The data import has a Selection Filter applied that isolates HTTP “GET” requests sent to a specified web server from a particular client IP address.

The purpose of the filter is to enable the administrator to isolate and analyze HTTP request and response messages that were interchanged between a specific web server and a specified client IP address, which resulted in possible transport errors, request timeouts, or faulty status indications. In this example, the administrator discovers possible reasons why the web server performed poorly by examining the HTTP StatusCode indicators and ReasonPhrases that were sent back to the client computer in HTTP response messages.

Note  A Selection Filter enables you to isolate specific messages and limit the amount of data in memory, which provides a performance advantage, but can be more expensive in terms of processing time. View Filters are somewhat more efficient and make it easier to work with your data after it displays in Message Analyzer. For example, View Filters can be applied and then removed because all of your original data is preserved in the Message Store, whereas with a Selection Filter, all messages that are not targeted to pass the filter are removed before data is displayed and can only be retrieved by performing another import without the filtering.

To apply a Selection Filter to imported data for HTTP message analysis

  1. From the Start menu or taskbar of a client computer, click the Microsoft Message Analyzer icon to open Message Analyzer.

  2. Click the Message Analyzer File tab to display the Backstage and then click Browse to display the Browse Session configuration interface, from where you can load saved trace data into Message Analyzer.

  3. In the Import files pane of the Browse Session configuration, click Add Files to display the Open dialog and then navigate to the trace file/s containing the captured data you want to work with.

  4. In the Open dialog, select the file containing the data you want to import, and then click Open.

    The Import files list is populated with the file/s you selected for importing data.

  5. In the Import files list, ensure that there is a checkmark in the check box next to the file/s containing the data you want to import.

  6. In the text box of the Selection Filter pane of the Browse Session configuration, enter the following filter expression and substitute appropriate values for the placeholder italic values. In this expression, the value for the “Source” phrase is the client IP address:

    HTTP.Request.Method=="GET" && *HTTPHost == "www.hostname.com" && *Source == <192.168.1.1>

  7. Click the View With button to automatically select the default Analysis Grid viewer and start importing data.

    The imported data displays in the Analysis Grid viewer on the Message Analyzer Home tab.

  8. In the View Options pane on the Ribbon of the Message Analyzer Home tab, click the Choose Columns button to display the Column Chooser tool window.

  9. In Column Chooser, double-click the StatusCode and ReasonPhrase fields for Response messages in the HTTP message hierarchy to add StatusCode and ReasonPhrase columns to the Analysis Grid viewer column layout.

  10. Right-click the StatusCode column and select the Group menu item to isolate the status data into separate groups with identical codes for ease of analysis.

    Tip  You can right-click the StatusCode label and select the Expand All Groups menu item to expand all the nodes of grouped data.

  11. In the Analysis Grid viewer, examine the StatusCode and Reason Phrase values to determine any problem areas that might indicate a poorly performing web server, as indicated by the HTTP StatusCode table in the HTTP Addendum section of this documentation.

    Note  You can also review the default TimeElapsed column in the Analysis Grid viewer to verify the elapsed time for HTTP “GET” methods. You could also add a ResponseTime column (from the Global Annotation category in Column Chooser) to examine the server response times in HTTP operations.

  12. Expand the top-level HTTP operations nodes and child nodes in the Analysis Grid viewer to expose the message origins tree for HTTP messages to determine whether any TCP diagnosis errors are present. You can do this by clicking the Diagnostics icon in the DiagnosisTypes column in the Analysis Grid viewer for any message to display diagnosis error details inline. Alternatively, you can view diagnostic information more effectively by doing the following:

    • Open the Diagnostics tool window to display a summary of diagnosis messages for your data set. You can then select diagnosis messages in the tool window to drive interactive highlighting of corresponding messages in the Analysis Grid viewer.

    • Group on the Diagnosis column in the Analysis Grid viewer to isolate errors by type.

    • Click the Diagnosis column in the Analysis Grid viewer to sort and bubble up any diagnosis errors that might have occurred.

    Tip  For ease of analysis, you might also consider displaying all HTTP messages at top level by applying an HTTP Viewpoint from the Viewpoints drop-down, and then click Hide Operations so that all HTTP messages are listed chronologically rather than grouped in operations.

    Note  Errors that involve TCP retransmits and lost segments might be an indication of TCP performance issues related to TCP Window size and/or WindowsScaleFactor settings. For more information about how to view these settings, see Applying a Trace Filter to a Live Firewall Trace.

Applying a Time Filter to Imported Log Data
The hypothetical high-level issue in this example is that a network administrator has a large volume of data that was collected in one or more log files and he or she wants to view the data in a specific window of time where failures are suspected to have occurred. In this scenario, the administrator will consolidate one or more related log files into a Browse Session data import and will apply a Time Filter that defines the time window in which to view messages. By using the Message Analyzer Time Filter, the administrator will limit the amount of data being imported, reduce loading time, and as a result, realize better import performance. Optionally, the administrator can apply a Selection Filter to the data import to isolate messages to a specific client IP address, if the log file format supports IP addresses, thereby reducing message count and helping to streamline the message analysis process.

Note  Some log files, such as text-based log files in proprietary format, may require you to create an OPN configuration file so that the log messages can be parsed by Message Analyzer, as described in Importing Unsupported Data Formats.

To apply a Time Filter to imported logs and view data in a selected time window

  1. Click the Message Analyzer File tab to display the Backstage and then click Browse to display the Browse Session configuration interface from where you can load log file data into Message Analyzer.

  2. In the Import files pane of the Browse Session configuration, click Add Files to display the Open dialog and then navigate to the log files containing the data you want to work with.

  3. In the Open dialog, select the files containing the data you want to import, and then click Open.

  4. In the Import files list, ensure that there are checkmarks in the checkboxes next to each log file that contains the data you want to import.

    The Time Filter pane is populated with Start Time and End Time values that are derived from the log files, in addition to the count for Total Messages.

  5. Adjust the Time Filter slider controls to set the time window that contains the data you want to examine.

    The Start Time and End Time values track the position of the slider controls and the Filtered Messages count changes to indicate the number of messages that the current Time Filter settings will cause the import to retrieve from the selected log files.

    Note  If the Start Time and End Time values do not display in the Time Filter pane for your log, you can select the Use Start Filter and Use End Filter check boxes and specify starting and ending date-times in a format that is appropriate for your log file/s, to adjust the time window in which to retrieve data.

  6. Optionally, enter the following Filter Expression in the text box of the Selection Filter pane of the Browse Session configuration, while substituting appropriately for the value in italics so that you can isolate messages from a particular client IP address, providing that this action is appropriate for the log files you are working with as indicated earlier:

    *Source==<192.168.1.1>

  7. Click the View With button to automatically select the Message Analyzer default Analysis Grid viewer and start importing data.

    The imported and filtered data displays in the Analysis Grid viewer to enable you to examine the messages in the time window that you specified.

  8. Optionally, to import log data in different windows of time, click the Configuration icon in the Session group on the Ribbon of the Message Analyzer Home tab (or right-click a session node in Session Explorer and select the Configuration context menu item) to redisplay the Browse Session configuration and then set the Time Filter slider controls appropriately for a new time window.

    Note  If you change the original Browse Session configuration, for example by adding or modifying a Selection Filter, selecting additional files to import data from, or specifying a different time window, Message Analyzer alerts you that a data reload is required.

  9. After modifying your Browse Session, click the Apply Changes button to start importing data based on a new Time Filter or other session reconfiguration.

Note  After you apply a Time Filter to a data import, all messages that are outside the time window you specified are removed from displayed results. If you want to restore all messages from your log files, or a portion thereof, you will need to perform a reimport of all data. However, as an alternative to applying a Time Filter prior to the import process, you can simply import all log data as is and then apply a Quick Filter to the displayed results to isolate data to a specified time window. The action of a Quick Filter can be quickly undone, so you can conveniently return to the original data set to review all messages or apply different time window filtering as required, without having to reimport any data. However, there are some factors to consider when choosing to use a Time Filter versus a Quick Filter, as described in Applying Quick Filters.

Filtering Live Data

This section provides examples of possible ways to filter data as it is being collected from live traces that utilize the Local Link Layer, Firewall, and Web Proxy default Trace Scenarios. The types of filters that are applied consist of an Adapter filter, WFP Layer Set filter, Trace Filter, Fast Filter, and the HostnameFilter and PortFilter.

Selecting a Network Interface to Filter a Live Local Link Layer Trace
The hypothetical high-level issue in this example is that a network administrator has a computer that is acting as a firewall with two adapters on different networks, and he or she wants to look at traffic on one adapter only, possibly for evidence of packets dropped at the NDIS layers. Message Analyzer enables the administrator to specify a particular adapter on which to capture data in a Local Link Layer trace, by selecting it in the Microsoft-PEF-NDIS-PacketCapture Advanced Settings dialog for the PEF-NDIS provider configuration while deselecting all other adapters. A trace at the Link Layer level ensures that the administrator can capture relevant data for the selected adapter.

To filter data on a specific network interface in a live Local Link Layer trace

  1. On the firewall computer, click the Message Analyzer File tab to display the Backstage and then click Capture/Trace to display the Trace Session configuration interface.

  2. Under Network in the Trace Scenarios pane, click the Local Link Layer (Windows 8/Windows Server 2012 or earlier) scenario.

    The Microsoft-PEF-NDIS-PacketCapture provider and its Id are displayed in the provider list and the ETW Provider Core Configuration displays in the Trace Scenario Configuration pane.

    Note  If you want to use the Local Link Layer (Windows 8.1/Windows Server 2012 R2) scenario in this procedure, you will be working with the Microsoft-Windows-NDIS-PacketCapture provider and the Microsoft-Windows-NDIS-PacketCapture Advanced Settings dialog for configuration. You can still filter based on adapter selection, however, you should refer to the appropriate documentation for local configuration settings, as described in Using the Windows NDIS Provider Advanced Settings Dialog.

  3. In the Trace Scenario Configuration pane, click the Configure link next to the Microsoft-PEF-NDIS-PacketCapture provider Id to display the Microsoft-PEF-NDIS-PacketCapture Advanced Settings dialog.

  4. In the Advanced Settings dialog, deselect the In and Out check boxes for the Machine node in the System Network tree grid to deselect the In and Out check boxes for all adapters.

  5. In the System Network tree grid, select the adapter on which to capture data by selecting the In and Out check boxes for that adapter. Ensure that all other adapters are unselected.

    The PEF NDIS provider is now set to capture traffic in both directions on the network interface that you specified.

    Note  You have the option to select only the In or Out check boxes for any adapter in the System Network tree grid, so that you can monitor traffic in a specified direction only. However, in most cases, it is prudent to monitor traffic in both directions. You also have the option to specify a Fast Filter for the trace in the Microsoft-PEF-NDIS-PacketCapture Advanced Settings dialog.

  6. Click the Start With button in the Trace Session configuration interface to automatically select the Analysis Grid viewer and begin capturing data.

    The captured messages start to accumulate in the Message Analyzer Analysis Grid viewer.

  7. While Message Analyzer is capturing data, attempt to reproduce any issue that is related to the reason for capturing data on a particular adapter, for example, packets are being dropped by the NDIS filter driver on the network interface that you chose.

  8. At a suitable point, stop the trace by clicking the Stop button in the Session group on the Ribbon of the Message Analyzer Home tab.

  9. Examine the data you captured, as appropriate.

More Information
To learn more about configuring the PEF-NDIS provider from the Microsoft-PEF-NDIS-PacketCapture Advanced Settings dialog, including how to assign Fast Filter Groups to selected adapters, see Using the PEF-NDIS Provider Advanced Settings Dialog.

Applying a WFP Layer Set Filter to a Live Firewall Trace
The hypothetical high-level issue in this example is that a network administrator wants to run a trace to directionally isolate IP traffic on a client computer while at the same time reduce the amount of IP traffic that is captured. Message Analyzer enables the administrator to use the WFP Layer Set filter configuration of the PEF WFP provider to isolate inbound or outbound IPv4 or IPv6 traffic. However, in this example, the administrator sets the WFP Layer Set filter configuration to capture inbound IPv4 traffic only on a client computer, as a possible starting point for detecting network connectivity issues.

To apply WFP Layer Set filtering to a live Firewall trace and isolate IP traffic

  1. On the client computer, click the Message Analyzer File tab to display the Backstage and then click Capture/Trace to display the Trace Session configuration interface.

  2. Under Network in the Trace Scenarios pane, click Firewall.

    The Trace Scenario Configuration pane is populated with configuration settings for the PEF WFP provider and the ETW Provider Core Configuration.

  3. In the Trace Scenario Configuration pane, expand the WFP Layer Set node to display the inbound and outbound transport filters.

  4. Expand the OUTBOUND_TRANSPORT_V4 node and then select the Not Selected item in the drop-down menu to the right of the Capture property.

    Note  By default, the WFP Layer Set filter configuration is set to capture messages for all inbound and outbound transports.

  5. Repeat step 4 for the INBOUND_TRANSPORT_V6 and OUTBOUND_TRANSPORT_V6 nodes.

    The WFP Layer Set configuration is now set to capture inbound IPv4 messages only in this Firewall trace. Note that you might also add an IPv4Address Fast Filter to further reduce the amount of traffic being captured, as described in PEF-WFP Fast Filters.

  6. Click the Start With button to automatically select the Analysis Grid viewer and begin capturing data.

    The captured messages start to accumulate in the Message Analyzer Analysis Grid viewer.

  7. While Message Analyzer is capturing data, attempt to reproduce the conditions that result in network connectivity issues being experienced by the client.

  8. At a suitable point, stop the trace by clicking the Stop button in the Session group on the Ribbon of the Message Analyzer Home tab.

  9. Examine the IPv4 inbound traffic that you captured for signs of connection issues, as appropriate.

Applying a Trace Filter to a Live Firewall Trace
The hypothetical high-level issue in this example is that a network administrator has a client that is experiencing slow file transfer activity or slowly loading web pages. A high number of TCP retransmits could be responsible for the delays. This could be symptomatic of inappropriate TCP Window size and WindowsScaleFactor settings.

Note  Retransmits can also be the result of the memory capacity of a router that cannot keep up with the traffic.

In this example, the administrator runs a trace on the client computer for a significant period to gather data, while using the Firewall Trace Scenario to reduce lower-layer traffic and a Trace Filter to capture TCP messages only. When the trace is complete, the administrator then adds Window, Options, and TCPDiagnosis columns to the Analysis Grid viewer column layout and runs a diagnostic View Filter to isolate and review any Warning level Retransmitted diagnosis messages. The administrator also uses the Group feature in the Analysis Grid viewer to gather the data into a convenient format that quickly consolidates and exposes related data of interest in groups.

If there are a significant number of TCP retransmits occurring, the administrator can do the following:

  • Review the TCP Window sizes of TCP segments in the Windows column of the Analysis Grid and observe whether the values vary significantly. To examine messages for the client IP address only, the administrator applies the following filter:

    *SourceAddress==<192.168.1.1>

  • Review TCP Options to ensure that the WindowsScaleFactor and Window size are set to reasonable values, for example, WindowsScaleFactor=2 and Window size=64k.

To apply a Trace Filter to a live Firewall trace and isolate TCP messages

  1. On the client computer, click the Message Analyzer File tab to display the Backstage and then click Capture/Trace to display the Trace Session configuration interface.

  2. Under Network in the Trace Scenarios pane, click Firewall.

    The Trace Scenario Configuration pane is populated with configuration settings for the PEF WFP provider.

  3. In the Trace Filter section of the Trace Scenario Configuration pane, enter the following Trace Filter in the text box to capture top-level TCP messages only:

    \TCP

    Note  By using a Firewall trace and applying the specified Trace Filter, the collected message count on the client computer is reduced.

  4. Click the Start With button to automatically select the Analysis Grid viewer and begin capturing data.

    The captured messages start to accumulate in the Message Analyzer Analysis Grid viewer.

  5. While Message Analyzer is capturing data, attempt to reproduce the conditions that cause the client to experience the indicated issues.

  6. At a suitable point, stop the trace by clicking the Stop button in the Session group on the Ribbon of the Message Analyzer Home tab.

  7. With Column Chooser, add TCP Window, TCP Options, and TCPDiagnosis columns to the Analysis Grid viewer column layout.

  8. Filter out all TCP messages that do not have a diagnosis error by entering the following Filter Expression in the View Filter text box and clicking the Apply Filter button in the View Filter group on the Ribbon:

    TCP#DiagnosisLevels

  9. Optionally, add the client IP address to the diagnosis filter as follows, to isolate diagnostic messages to the client IP address only. In the Filter Expression, substitute appropriately for the italic address value:

    TCP#DiagnosisLevels && *Source == <192.168.1.1>

  10. Right-click the TCPDiagnosis column in the Analysis Grid viewer and select the Group command to group the different diagnostic error types.

  11. Scroll down through the groups until you find one or more groups labeled Retransmitted.

    If there are a high number of Warning level “Retransmitted” diagnosis messages, you should then determine whether the TCP Window size and the WindowsScaleFactor of incoming TCP messages are set to appropriate values on the client, in the steps that follow.

  12. Remove the TCP#DiagnosisLevels filter and then apply the following View Filter to filter out all TCP messages that do not contain TCP Options:

    TCP.Options ~= nothing

    Note  The above filter will return only TCP messages that contain TCP Options and all other messages will be filtered out of the display. Alternatively, if you want to view all TCP messages, including those that have TCP Options, you can use Column Chooser to add a Network column (message hierarchy path==IPv4.Datagram.Network) and a Transport column (message hierarchy path==TCP.Segment.Transport) to the Analysis Grid viewer. You can then use the Group feature on each of these columns to organize your data display for viewing TCP Options, as further described by the procedure in Applying TCP View Filters to Firewall Trace Results.

  13. Highlight TCP messages containing TCP Options as necessary and review the WindowsScaleFactor option settings, especially for messages that have a low Window size value, to determine that they are set to reasonable values. The TCP messages of interest should be those that comprised the SYN request and SYN/ACK response messages of three-way handshakes, as this is where the option settings are negotiated.

More Information
To learn more about filtering for TCP diagnostic messages, see the procedure Applying TCP View Filters to Firewall Trace Results.

Applying Fast Filters to a Live Firewall Trace
The hypothetical high-level issue in this example is that a network administrator has a busy server where the responses are slow, but he or she doesn’t want to impact the server with a high-volume trace when troubleshooting issues. Message Analyzer enables the administrator to accommodate this situation and determine why the server is behaving this way, by using a Fast Filter based on a Port to narrow down the traffic captured on the server. If the problem seems to be related to a particular user, the administrator can use a Fast Filter based on a specified client IP address. The intent of this scenario is to demonstrate the efficiency and performance advantages that can be achieved when applying Fast Filters, which enable the administrator to capture the least amount of data possible to resolve a problem.

To apply Fast Filters to a live Firewall trace and isolate specific messages to reduce data volume

  1. On the server computer, click the Message Analyzer File tab to display the Backstage and then click Capture/Trace to display the Trace Session configuration interface.

  2. Under Network in the Trace Scenarios pane, click Firewall.

    The Trace Scenario Configuration pane is populated with configuration settings for the PEF WFP provider.

  3. In the Trace Scenario Configuration pane, click the Fast Filter 1 node in the PEF WFP Settings to expand it.

  4. Select the TCPPort item from the drop-down menu next to the FilterType property under the expanded Fast Filter 1 node.

  5. In the text box to the right of the Filter property, specify a port number such as <80>.

  6. Alternatively, if you also want to isolate the data to a specific client IP address, expand the Fast Filter 2 node and select the IPv4Address item from the drop-down menu next to the FilterType property.

  7. In the text box to the right of the Filter property under the expanded Fast Filter 2 node, specify a client IPv4 address in a format similar to the following: <192.168.1.1>.

  8. Click the Start With button to begin capturing data.

  9. The captured messages start to accumulate in the Analysis Grid View.

  10. While Message Analyzer is capturing data, attempt to reproduce the conditions that cause the server to experience the indicated issues.

  11. At a suitable point, stop the trace by clicking the Stop button in the Session group on the Ribbon of the Message Analyzer Home tab.

  12. Examine the captured data to determine possible causes of slow server responses, as appropriate.

Applying Hostname and Port Filters to a Live Web Proxy Trace
The hypothetical high-level issue in this example is that a network administrator is dealing with a client browser that has difficulty connecting with one or more web sites. The client is already overwhelmed with network traffic, so the administrator wants to determine what might be causing the connection problems without imposing a high-volume data capture on the overwhelmed client computer.

In this example, the administrator uses the Web Proxy provider HostnameFilter to isolate messages sent to and from a particular web site, and the PortFilter to isolate messages on a particular port, such as 80. This scenario is useful for achieving better performance than using a comparable Trace Filter that specifies a particular destination IP address and port number. The HostnameFilter and PortFilter act similarly to the way Fast Filters do in that they allow for minimal parsing, cause less data to be collected, and therefore have less impact on the computer where the trace is run. In this scenario, the administrator analyzes HTTP StatusCode and ReasonPhrase indicators that can reflect connection issues, request timeouts, elapsed time/delays, or other errors that occur when a client is attempting to connect to a specified HTTP web server that might also be very busy.

To apply HTTP filters to a live Web Proxy trace and expose status indications

  1. On the client computer, click the Message Analyzer File tab to display the Backstage and then click Capture/Trace to display the Trace Session configuration interface.

  2. Under Network in the Trace Scenarios pane, click Web Proxy.

    The Trace Scenario Configuration pane is populated with configuration settings for the Web Proxy provider.

  3. In the Trace Scenario Configuration pane under the Web Proxy provider configuration, enter an HTTP HostnameFilter value in a format similar to the following:

    www.bing.com

  4. In the Trace Scenario Configuration pane under the Web Proxy provider configuration, enter an HTTP PortFilter number in a format similar to the following:

    80

  5. Click the Start With button to begin capturing data.

  6. While Message Analyzer is running, attempt to reproduce the conditions that cause the connection issues that the client is experiencing.

    The captured HTTP messages start to accumulate in the Analysis Grid View.

  7. At a suitable point, stop the trace by clicking the Stop button in the Session group on the Ribbon of the Message Analyzer Home tab.

  8. In the View Options group on the Ribbon of the Message Analyzer Home tab, click the Choose Columns button to open the Column Chooser tool window.

  9. In the Column Chooser, scroll down to the HTTP protocol, click its expansion node, and then expand the Response node.

  10. Under the Response node, double-click the StatusCode and ReasonPhrase fields to add them as new columns in the Analysis Grid viewer column layout.

    The StatusCode and ReasonPhrase fields are populated with data values from the trace.

  11. Examine the StatusCode and ReasonPhrase values of the captured data to determine possible causes of connection issues.

More Information
To learn more about common HTTP StatusCode and ReasonPhrase definitions, see the HTTP Status Code table in the HTTP Addendum section of this documentation.

Filtering Trace Results

This section provides examples of possible ways to filter displayed data that was collected from live traces that utilized the Local Link Layer, Firewall, and Web Proxy default Trace Scenarios. The types of filters that are applied consist of Address, Port, HTTP, and TCP View Filters.

Applying a View Filter to Link Layer Trace Results
The hypothetical high-level issue in this example is that a network administrator is trying to discover the signature of virus traffic that has been infecting client computers. The administrator takes a Local Link Layer trace for an adequate time period to ensure enough data is collected on a client computer that is potentially being infected. When viewing trace results, the administrator realizes that it contains significant lower-layer noise that should be filtered out. For example, there is a lot of traffic on the client coming from a busy SQL server that is of no interest to the administrator, so he or she decides to remove it with a View Filter based on the SQL server IP address. There is also considerable traffic coming from the Remote Desktop Protocol (RDP) that is servicing the client’s connection to a remote computer, which the administrator decides to remove with a View Filter based on a TCP port. In this example, the administrator can rule out SQL server and RDP messages when searching for virus signatures because these services are normally considered cleaned by antivirus software.

To apply a View Filter to Link Layer trace results that removes unwanted traffic

  1. On the client computer, click the Message Analyzer File tab to display the Backstage and then click Capture/Trace to display the Trace Session configuration interface.

  2. Under Network in the Trace Scenarios pane, click a Local Link Layer scenario that is appropriate for your computer operating system.

    Depending on the scenario you selected, either the Microsoft-PEF-NDIS-PacketCapture provider or the Microsoft-Windows-NDIS-PacketCapture provider and its Id are displayed in the provider list and the ETW Provider Core Configuration displays in the Trace Scenario Configuration pane for the NDIS provider.

  3. Click the Start With button to begin capturing data.

    The captured messages start to accumulate in the Analysis Grid View.

  4. While Message Analyzer is capturing data, attempt to reproduce any conditions that might be causing client vulnerability to virus infection, if possible.

  5. At a suitable point, stop the trace by clicking the Stop button in the Session group on the Ribbon of the Message Analyzer Home tab.

  6. In the View Filter group on the Ribbon of the Message Analyzer Home tab, enter the following Filter Expression to remove unwanted SQL and RDP traffic, while substituting the SQL server IP address for the italic value:

    *Address != 192.168.1.1 && TCP.Port != 3389

  7. In the View Filter group on the Ribbon, click the Apply Filter button to remove all bidirectional SQL and RDP traffic.

  8. Examine the remaining data in the Analysis Grid viewer by performing established procedures for isolating and detecting virus signatures.

Applying an HTTP View Filter to Firewall Trace Results
The hypothetical high-level issue in this example is that a network administrator needs to ensure that he or she can isolate all HTTP messages interchanged between a client computer and a web server. In this example, the administrator runs a Firewall trace to ensure that all HTTP data is collected with a minimum of lower level noise, and then applies an HTTP View Filter to the trace results. To address this issue, the administrator uses a Firewall trace to ensure capture of all HTTP traffic, whereas a Web Proxy trace only captures browser traffic. Therefore, the administrator can be confident that he or she has isolated all the HTTP traffic necessary to analyze whatever issues are occurring. In addition, Message Analyzer provides better functionality in these circumstances than Netmon, which returns only the HTTP headers rather than all message fragments as Message Analyzer does.

To apply an HTTP View Filter to Firewall trace results and examine all HTTP-related messages

  1. On the client computer, click the Message Analyzer File tab to display the Backstage and then click Capture/Trace to display the Trace Session configuration interface.

  2. Under Network in the Trace Scenarios pane, click Firewall.

    The Trace Scenario Configuration pane is populated with configuration settings for the PEF WFP provider.

  3. Click the Start With button to begin capturing data.

    The captured messages start to accumulate in the Analysis Grid View.

  4. While Message Analyzer is capturing data, attempt to reproduce any conditions that cause the client or web server to experience the indicated issues.

  5. At a suitable point, stop the trace by clicking the Stop button in the Session group on the Ribbon of the Message Analyzer Home tab.

  6. In the View Filter group on the Ribbon of the Message Analyzer Home tab, enter the following atomic Filter Expression:

    HTTP

  7. In the View Filter group on the Ribbon, click the Apply Filter button to isolate all HTTP operations and other messages that contain HTTP in the call stack.

    Note  Alternatively, apply an HTTP Viewpoint to isolate all HTTP messages at top-level to show trace results from the HTTP perspective; you can also Hide Operations to break out all HTPP operations (request and response messages) into chronological order for enhanced analysis.

  8. In the Analysis Grid viewer, click the message expansion nodes to expose the HTTP message origins tree for HTTP messages of interest.

    Alternatively, add StatusCode and ReasonPhrase columns with the Column Chooser and execute the Group command on the StatusCode column to create groups of identical HTTP status codes, for ease of analysis.

  9. Examine the filtered data to determine possible causes of any issues experienced by the client or web server, as appropriate. See the HTTP Addendum for HTTP status code information.

Applying TCP View Filters to Firewall Trace Results
The hypothetical high-level issue in this example is that a network administrator has one or more client computers that are believed to be experiencing TCP connection and/or data transmission problems such as the following:

  • Dropped packets or lost TCP segments.

  • Slow data transmission rates related to TCP window size and scaling.

  • Incomplete connection request handshakes.

In this scenario, the administrator identifies common TCP connection and data transmission issues by writing and applying various Filter Expressions to expose data that can reveal the potential causes of such problems. The procedure that follows provides examples of Filter Expressions that the administrator applies to isolate the values of various TCP fields, to determine whether any problems exist in these areas.

Note  When troubleshooting TCP connection issues, Message Analyzer users should learn the meaning of all the TCP analysis flags so they can write filters to isolate and analyze the information they provide.

To apply TCP View Filters to Firewall trace results and expose TCP diagnostics

  1. On the client computer, click the Message Analyzer File tab to display the Backstage and then click Capture/Trace to display the Trace Session configuration interface.

  2. Under Network in the Trace Scenarios pane, click Firewall.

    The Trace Scenario Configuration pane is populated with configuration settings for the Microsoft-PEF-WFP-MessageProvider.

  3. Click the Start With button to begin capturing data.

    The captured messages start to accumulate in the Analysis Grid viewer.

  4. While Message Analyzer is capturing data, attempt to reproduce the conditions that result in TCP connection issues that client computers might be experiencing.

  5. At a suitable point, stop the trace by clicking the Stop button in the Session group on the Ribbon of the Message Analyzer Home tab.

  6. On the Message Analyzer Home tab, click the Choose Columns icon in the View Options group on the Ribbon to display the Column Chooser tool window.

  7. In Column Chooser, scroll to the TCP protocol and click its expansion node to expose the TCP message hierarchy.

  8. In the TCP message hierarchy, expand the Segment node and then double-click the TCPDiagnosis, SYN flag, ACK flag, Window, and Options fields to add them as new data columns in the Analysis Grid viewer column layout.

    Note  Adding these fields to the column layout enables you to view the corresponding values of these fields as you apply the filters throughout this procedure.

  9. In the text box of the View Filter group on the Ribbon, enter the following Filter Expression:

    TCP#DiagnosisLevels

  10. In the View Filter group on the Ribbon, click the Apply Filter button to filter the Firewall trace results and verify whether you have any TCP-related errors.

  11. If the filter in the previous step exposes TCP errors in the TCPDiagnosis column of the Analysis Grid viewer, you can isolate and view this data in several ways, as described in the steps that follow.

  12. To isolate lost or out-of-order TCP segments, enter the following Filter Expression in the text box of the View Filter group on the Ribbon and then click Apply Filter to start the filtering process for the trace:

    *TCPDiagnosis == "Segment-Lost/Out-of-order"

    If you want to look at top-level TCP messages only and use a quicker performing filter, apply the following filter expression to the trace:

    \TCP::TCPDiagnosis == "Segment-Lost/Out-of-order"

  13. To focus on TCP message Window size, which can reduce the data transmission rate when too small (see TCP Category), apply the following filter to the trace, while adjusting the italic Window size value in the filter as appropriate:

    TCP::Window < 1000

  14. To verify whether WindowsScaleFactor is operative or whether other TCP Options are correctly set for optimal performance, apply the following filter to return only TCP messages that have Options set:

    TCP::Options ~= nothing

    Note  Alternatively, you can add an IP Network column and a TCP Transport column to the Analysis Grid viewer column layout and use the right-click Group function on these columns to quickly view the captured TCP messages that have TCP Options set. If you use this method, make sure to right-click the Network and Transport group labels and select the Expand All Groups menu command to expose all the data. This method also enables you to view the TCP ports through which the messages transited and the IP addresses of the computer nodes that participated in the TCP connection operations.

    When you are viewing the TCP Option configuration, you might want to do the following:

    • Ensure that Selective Acknowledgement (SACK) is enabled.

    • Verify that the Maximum Segment Size (MSS) is set to a reasonable value to reduce fragmentation.

    • Ensure that the WindowsScaleFactor function is operative and set to a reasonable value for the Window size setting, to enable automatic resize of the receive TCP Window as necessary.

  15. To search for incomplete three-way handshake patterns in a trace along with surrounding messages potentially related to a failure, click the Find button in the View Filter group on the Ribbon and apply one or more of the following filters in any suitable sequence:

    TCP::TCPDiagnosis == "Segment-Lost/Out-of-order"

    TCP::AcknowledgementNumber==0

    TCP::Flags.Syn==true && TCP::Flags.Ack==true

    Note  Alternatively, you can use the method described in the Note immediately above to find TCP messages that participated in three-way handshake operations, by locating the TCP messages that contain TCP Options and the signature pattern of SYN, ACK, SequenceNumber, and AcknowledgementNumber field values.

    The following pattern of SYN and ACK field values, with the relative SequenceNumber and AcknowledgementNumber value representations, exposes the signature of a three-way handshake pattern that successfully opened a TCP connection:

    Table 15. Three-way handshake signature

    Computer Node Message Sent SYN Flag Value ACK Flag Value SequenceNumber AcknowledgementNumber TCP Options

    Sending

    Connection request

    True

    False

    x

    0

    Yes

    Receiving

    Request acknowledgement

    True

    True

    y

    x+1

    Yes

    Sending

    Sync acknowledgement

    False

    True

    x+1

    y+1

    No


    Tip   Keep in mind that incomplete handshakes can appear in a trace if the capture time frame did not synchronize with a TCP transmission or if the network dropped packets.


    More Information
    To learn more about three-way handshake sequence expressions, see Matching Message Sequences.

Applying a View Filter to Web Proxy Trace Results
The hypothetical high-level issue in this example is that a network administrator of a site has web clients that complain about slow responses when attempting to connect with and retrieve data from one or more web servers. With the use of the Message Analyzer Web Proxy Trace Scenario running on a client computer that is having the most issues, the administrator can quickly determine which servers are having connection or performance problems. In the procedure that follows, the administrator applies HTTP View Filters against data that is displaying in the Analysis Grid viewer, to obtain a clear picture of which servers are experiencing performance issues. To this end, View Filters help the administrator accomplish the following:

  • Isolate HTTP “GET” method messages to streamline the review of time elapsed during HTTP requests.

  • Isolate HTTP StatusCode values that were received, along with accompanying ReasonPhrases, to pinpoint any client or server errors that occurred during HTTP message exchanges.

To apply an HTTP View Filter to Web Proxy trace results and expose HTTP status codes

  1. On the client computer, click the Message Analyzer File tab to display the Backstage and then click Capture/Trace to display the Trace Session configuration interface.

  2. Under Network in the Trace Scenarios pane, click Web Proxy.

    The Trace Scenario Configuration pane is populated with configuration settings for the Web Proxy provider.

  3. Click the Start With button to begin capturing data.

  4. While Message Analyzer is running, perform some HTTP requests from client computers that are experiencing slow connection or data retrieval problems with one or more web servers that are suspected of being overburdened and performing poorly.

    The captured HTTP messages start to accumulate in the Analysis Grid View.

  5. At a suitable point, stop the trace by clicking the Stop button in the Session group on the Ribbon of the Message Analyzer Home tab.

  6. On the Message Analyzer Home tab, click the Choose Columns icon in the View Options group on the Ribbon to display the Column Chooser tool window.

  7. In Column Chooser, scroll to the HTTP protocol and click its expansion node to expose the HTTP message hierarchy.

  8. In the HTTP message hierarchy, locate the following fields and double-click each one to add it as a new column in the Analysis Grid viewer column layout: Method, StatusCode, and ReasonPhrase.

  9. In the text box of the View Filter group on the Ribbon, enter the following Filter Expression:

    HTTP.Request.Method=="GET"

  10. In the View Filter group on the Ribbon, click the Apply Filter button to filter the Web Proxy trace results for all HTTP “GET” requests.

  11. Click the Show Column Filter Row icon in the upper-left corner of the Analysis Grid viewer to display the amber-colored Column Filter text box row.

  12. Isolate specific HTTP StatusCodes in the trace by typing “10”, “20”, “30”, “40”, or “50” into the Column Filter text box above the StatusCode column, as appropriate, or enter a specific StatusCode for which you are looking, for example “408”.

    The column is filtered according to the value you specified.

  13. Examine the different StatusCodes and ReasonPhrases to determine any problem areas that might indicate a poorly performing web server. To review the definitions of StatusCodes and ReasonPhrases, refer to the HTTP Addendum section of this documentation.

  14. Analyze the TimeElapsed column values in the Analysis Grid to verify whether the HTTP “GET” methods are taking a long time.

    For example, you could type “1.”, “2.”, “3.”, and so on, into the Column Filter text box to filter for messages that have an elapsed time of 1 second or greater.

    Alternatively, you can add the ResponseTime field from the Global Annotations category in Column Chooser so that you can review server response times for excessive values.

  15. Apply the following View Filter to isolate messages for any secure connections that were established during the trace and perform similar operations that are outlined in steps 11 through 14:

    HTTP.Request.Method== “CONNECT”

Filtering with Color Rules

The hypothetical high-level issue in this example is that a network administrator needs to be aware of faulty or erratic client connections or file request failures that occur during file server access, by highlighting errors representing common TCP connection issues and SMB status. In the example that follows, the administrator performs a Firewall trace with a Trace Filter that specifies an SMB port in order to isolate SMB traffic. The administrator then does the following:

  • Creates a new color rule to highlight TCP diagnostic information.

  • Creates a new color rule to highlight SMB error status.

  • Optionally adds an SMB Header.Status column to examine SMB error values that appear in the trace.

Applying Color Rules to Firewall Trace Results

  1. On the client computer, click the Message Analyzer File tab to display the Backstage and then click Capture/Trace to display the Trace Session configuration interface.

  2. Under Network in the Trace Scenarios pane, click Firewall.

    The Trace Scenario Configuration pane is populated with configuration settings for the PEF WFP provider.

  3. In the Trace Filter text box of the Trace Scenario Configuration pane, enter the following Filter Expression:

    TCP.Port == IANA.Port.SMB

  4. Click the Start With button to begin capturing data.

  5. While Message Analyzer is capturing data, perform some file share access from the client computer to a file server or other location where access problems are known to be occurring.

    The messages captured on the SMB port start to accumulate in the Analysis Grid View.

  6. At a suitable point, stop the trace by clicking the Stop button in the Session group on the Ribbon of the Message Analyzer Home tab.

  7. Create a new Color Rule with the following filter, to highlight any TCP messages where Application-type error events might have occurred, such as lost or incomplete segments, missing three-way handshakes, duplicate ACKs, sequence number retransmits, and so on, to expose any possible TCP connection issues:

    TCP#DiagnosisLevels

    For information about creating and saving Color Rules, see Using and Managing Color Rules.

  8. Create a new Color Rule with the following filter, to highlight SMB Status errors that might occur during file share access.

    SMB2.Header.Status != 0

  9. Optionally, use Column Chooser to add an SMB Header.Status column to the Analysis Grid viewer column layout so you can examine any SMB errors that might have occurred.

    For example, you can find the Status column in the Header field under the ReqMessage of the SMB2 protocol in Column Chooser.

Note  You can leave the Color Rules in the applied state so that any messages with TCP diagnostics and SMB errors are automatically displayed whenever you run a trace. Unless you specifically disable Color Rules, they remain enabled for all Message Analyzer Trace Scenarios.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft