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

Using the Data Filtering Features

The procedures in this section encapsulate the main filtering 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.

Important  As the person running the procedures in the examples of this section, it is assumed that you are a Network Administrator, or that you are at least familiar with networking concepts.

The procedures are presented in the following subsections:

Filtering a Data Retrieval Session — provides examples of the following:

  • How to apply a Session Filter to data that is loaded into Message Analyzer through a Data Retrieval Session that targets a saved trace file as input, so you can isolate and analyze HTTP request messages sent from a specified client IP address to a poorly performing web server along with the response messages that were issued back to the client. Some HTTP analysis techniques are also provided in the procedure to help you discover possible reasons for the poor web server performance.

  • How to apply a Time Filter to data that is loaded into Message Analyzer through a Data Retrieval Session that targets input log files which 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 Trace Session Data — provides examples of the following:

  • How to collect data from a specific network interface in a Live Trace Session that uses the Local Network Interfaces Trace Scenario, by selecting an Adapter from which to capture data. This can be useful to isolate data on a specific adapter when 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 in a Live Trace Session that uses the Network Tunnel Traffic and Unencrypted IPSEC Trace Scenario to capture inbound TCP traffic only, in order to limit the number of captured messages while focusing on TCP ACK traffic for troubleshooting purposes.

  • How to specify a Session Filter in a Live Trace Session that uses the Loopback and Unencrypted IPSEC Trace Scenario to isolate TCP messages, in an attempt to correlate slow file transfers or sluggish web page loading performance with TCP retransmit issues.

  • How to specify a Fast Filter that filters messages at the provider level based on a port or client IP address. The filtering is applied to a busy server where the responses are slow, in a Live Trace Session that uses the Loopback and Unencrypted IPSEC Trace Scenario, 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 a Hostname and/or Port filter in a Live Trace Session that uses the Unencrypted HTTPS Trace Scenario to reduce captured traffic volume 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 Live Trace Session Results — provides examples of the following:

  • How to apply an Address and Port View Filter to the results of a Live Trace Session that used the Local Network Interfaces Trace Scenario, and to thereby remove unwanted lower-layer traffic and streamline the detection of virus signatures.

  • How to apply an HTTP View Filter to the results of a Live Trace Session that used the Loopback and Unencrypted IPSEC Trace Scenario, to isolate all HTTP traffic from a particular client computer, including all the origins messages in the underlying stack where a problem might occur in supporting the HTTP operations. Alternatively uses the HTTP Viewpoint to present data from the perspective of the HTTP protocol. 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 the results of a Live Trace Session that used the Loopback and Unencrypted IPSEC Trace Scenario 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 the results of a Live Trace Session that used the Unencrypted HTTPS Trace Scenario, so you can isolate specific 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 the results of a Live Trace Session that used the Network Tunnel Traffic and Unencrypted IPSEC Trace Scenario with a Session Filter to expose TCP and SMB diagnostic messages, in order to prompt further 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.

Important  If you have not logged off Windows after the first installation of Message Analyzer, please log off and then log back on before performing these procedures. This action ensures that in all subsequent logons following installation, your security token will be updated with the required security credentials from the Message Capture Users Group (MCUG). Otherwise, you will be unable to capture network traffic in Trace Scenarios that use the Microsoft-PEF-NDIS-PacketCapture provider, Microsoft-Windows-NDIS-PacketCapture provider, or the Microsoft-PEF-WFP-MessageProvider, unless you start Message Analyzer with the right-click Run as administrator option.

Filtering a Data Retrieval Session

This section provides examples of possible ways to filter data that is loaded into Message Analyzer from saved trace or log files. The examples include the use of an HTTP Session 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 Session Filter to Saved 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 loads data from one or more saved trace files containing messages that were originally captured on one or more client computers by using the Loopback and Unencrypted IPSEC Trace Scenario, which reduces most network noise at the Data Link Layer. The example assumes that the trace ran over an adequate time period to reproduce the connection issues that clients are experiencing. Messages are loaded into Message Analyzer through a Data Retrieval Session with a Session Filter applied that isolates HTTP “GET” requests (displayed under HTTP operation nodes in the Analysis Grid viewer) that were sent to a specified web server from a particular client IP address.

The purpose of the Session Filter in this case is to enable the administrator to isolate HTTP operations and facilitate analysis of the HTTP request and response messages that were interchanged between a specified 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 Session Filter enables you to isolate specific messages and limit the amount of data stored 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 Session Filter, all messages that are not targeted to pass the filter are removed before any data is displayed and can only be retrieved by re-running the Data Retrieval Session with the Session Filter removed. If you want to do this, click the Edit button in the Session group on the Ribbon of the Message Analyzer Home tab to display the Edit Session dialog, from where you can reconfigure the session and run it again, as described in Editing Existing Sessions.

To apply a Session Filter to loaded data for HTTP message analysis

  1. From the Start menu, Start page, or task bar of your computer, click the Microsoft Message Analyzer icon to launch Message Analyzer. If you have not logged off and back on after first installing Message Analyzer, then start Message Analyzer with the right-click Run as Administrator option.

  2. Click File to open the Message Analyzer File menu, click New Session, and then select Blank Session in the New Session submenu to display the New Session dialog.

  3. Under Add Data Source in the New Session dialog, click the Files button to display the Files tab along with the associated session configuration features that it contains in the New Session dialog.

  4. On the toolbar of the Files tab in the New Session dialog, click Add Files to display the Open dialog and then navigate to the trace file/s containing the saved trace data you want to work with.

  5. In the Open dialog, select the file/s containing the data you want to load into Message Analyzer, and then click Open.

    The files list is populated with the file/s you selected.

  6. In the files list, ensure that there is a check mark in the check box next to the file/s containing the data you want to load into Message Analyzer.

  7. In the text box of the Session Filter pane of the New Session dialog, enter the following Filter Expression and substitute appropriate values for the placeholder italic values. In this expression, note that the value for the “Source” phrase is the client IP address:

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

  8. Verify that the Analysis Grid viewer is selected in the Start With drop-down list in the New Session dialog. If it is not, then select it.

  9. Click the Start button in the New Session dialog to begin loading data into Message Analyzer from the specified file/s.

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

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

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

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

  13. 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 described in the status code table in the Addendum 1: HTTP Status Codes 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, or for entire HTTP operations to complete. High values for elapsed time in the latter “operations” case may be an indication of network latency or TCP retransmit issues due to dropped packets. You could also add a ResponseTime column (from the Global Annotation category in Column Chooser) to examine the server response times to request messages. This can provide an indication of whether or not a server is performing slowly, as it measures the time difference between the last time-stamped message in the request stack and the Timestamp of the first response message that is sent back to the requesting node.

  14. Expand the top-level HTTP operations nodes and child nodes in the Analysis Grid viewer to expose the 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 any of the following:

    • Open the Diagnostics Tool Window by selecting it in the Tool Windows drop-down list on the Ribbon of the Message Analyzer Home tab, to display a summary of diagnosis messages for your data set. You can then select diagnosis messages in the Diagnostics window to drive interactive highlighting of corresponding messages in the Analysis Grid viewer for further examination of diagnosis errors in those messages.

    • Perform the Group command on the Diagnosis column in the Analysis Grid viewer to isolate errors by type, by right-clicking the Diagnosis column and selecting the Group command.

    • 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 only HTTP messages encapsulated in top-level operations with no layers above, by applying an HTTP Viewpoint from the Viewpoints drop-down on the Ribbon of the Message Analyzer Home tab.

    Note  Diagnosis messages that specify lost TCP segments and retransmits might be an indication of packets being dropped by the network, or could indicate TCP performance issues related to TCP Window size and/or WindowsScaleFactor settings. For more information about how to view these settings, see Applying a Session Filter to a Live Loopback and Unencrypted IPSEC Trace.

Applying a Time Filter to Loaded 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 as input to a Data Retrieval Session and will apply a Time Filter that defines a time window in which to view messages. By using the Message Analyzer Time Filter, the administrator will limit the amount of data being loaded, reduce the loading time, and as a result, realize better performance. Optionally, the administrator can apply a Session Filter to the input data 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 Working With Other Input Data Requirements. However, note that you can select from a number of predefined Text Log Configuration files on the toolbar of the Files tab in the New Session dialog, during Data Retrieval Session configuration. If your log file cannot be parsed by one of the predefined configuration files, you will need to create one.

To apply a Time Filter to input log file data and view results in a selected time window

  1. From the Start menu, Start page, or task bar of your computer, click the Microsoft Message Analyzer icon to launch Message Analyzer. If you have not logged off and back on after first installing Message Analyzer, then start Message Analyzer with the right-click Run as Administrator option.

  2. Click File to open the Message Analyzer File menu, click New Session, and then select Blank Session in the New Session submenu to display the New Session dialog.

  3. Under Add Data Source in the New Session dialog, click the Files button to display the Files tab along with the associated session configuration features that it contains in the New Session dialog.

  4. On the toolbar of the Files tab in the New Session dialog, click Add Files to display the Open dialog and then navigate to the trace file/s containing the saved trace data you want to work with.

  5. In the Open dialog, select the file/s containing the data you want to load into Message Analyzer, and then click Open.

    The files list is populated with the file/s you selected.

  6. In the files list, ensure that there is a check mark in the check box next to the file/s containing the data you want to load into Message Analyzer.

    After you select the files to include in the Data Retrieval Session, the Time Filter pane will be populated with Start Time and End Time values that are derived from the log file/s, in addition to the Total Messages count. Note that the time values that initially display create a window that is inclusive of the earliest and latest time values that Message Analyzer detects from the currently selected files in the input files list.

  7. Select the Use Start Filter and Use End Filter check boxes in the Time Filter pane and then 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 Data Retrieval Session will load from the selected log files, based on the current Time Filter settings.

    Note  If the Start Time and End Time values do not display in the Time Filter pane for your log, you can manually specify starting and ending date-times in a format that is appropriate for your log file/s. Thereafter, time window adjustments should track in accordance with the format that you specified.

  8. Optionally, enter the following Filter Expression in the Session Filter text box of the Data Retrieval 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>

  9. Verify that the Analysis Grid viewer is selected in the Start With drop-down list in the New Session dialog. If it is not, then select it.

  10. Click the Start button to begin loading data from the specified input log file/s.

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

  11. To optionally load log data in different windows of time, click the Edit icon in the Session group on the Ribbon of the Message Analyzer Home tab to open the Edit Session dialog, from where you can readjust the slider controls to configure a different Time Filter window. Note that you will need to enter the Full Edit mode in the Edit Session dialog to enable the controls.

    Note  If you alter the original Data Retrieval Session configuration after entering the Full Edit mode, by making changes other than adding or removing files, Message Analyzer will perform a required reload of all data.

  12. When reconfiguration of the time window in your Data Retrieval Session is complete, click the Apply button to start loading data based on the new Time Filter or other session reconfiguration.

Note  After you apply a Time Filter to an input data files configuration, 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, you will need to reload all data with the Time Filter removed.

However, as an alternative to applying a Time Filter prior to loading data from saved files, you can simply load all input 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 reload 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. For example, when loading data from large log files without a Time Filter, performance may diminish.

Filtering Live Trace Session Data

This section provides examples of possible ways to filter data as it is being collected from several Live Trace Sessions that separately utilize one of the following default Trace Scenarios:

  • Local Network Interfaces

  • Network Tunnel Traffic and Unencrypted IPSEC

  • Loopback and Unencrypted IPSEC

  • Unencrypted HTTPS

The types of filters that are applied in these scenarios consist of an Adapter filter, WFP Layer Set filter, Session Filter, Fast Filter, and the HostnameFilter and PortFilter.

Selecting a Network Adapter to Filter a Local Network Interfaces 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 Network Interfaces Trace Scenario, by selecting the adapter in the Advanced Settings - Microsoft-PEF-NDIS-PacketCapture dialog that is accessible from the New Session dialog during session configuration, while deselecting all other adapters. A trace at the Data Link Layer ensures that the administrator can capture relevant data for the selected adapter.

Note  If you are running the Local Network Interfaces scenario on a computer with the Windows 7, Windows 8, or Windows Server 2012 operating system, you will be working with the Microsoft-PEF-NDIS-PacketCapture provider. However, if you are running this scenario on a computer with the Windows 8.1, Windows Server 2012 R2, or later operating system, you will be working with the Microsoft-Windows-NDIS-PacketCapture provider. Please note that the Advanced Settings dialogs for these two providers are very different and contain unique filtering configuration capabilities. The procedure that follows focuses on the Microsoft-PEF-NDIS-PacketCapture provider and its configuration capabilities. However, to configure adapter selection with the Microsoft-Windows-NDIS-PacketCapture provider, you should refer to the appropriate documentation for local trace configuration settings, as described in Using the Advanced Settings - Microsoft-Windows-NDIS-PacketCapture Dialog.

To filter data on a specific network interface in a Local Network Interfaces trace

  1. From the Start menu, Start page, or task bar of the target computer, click the Microsoft Message Analyzer icon to launch Message Analyzer. If you have not logged off and back on after first installing Message Analyzer, then start Message Analyzer with the right-click Run as Administrator option.

  2. Click File to open the Message Analyzer File menu, click New Session, and then select Blank Session in the New Session submenu to display the New Session dialog.

  3. Under Add Data Source in the New Session dialog, click the Live Trace button to display the Live Trace tab along with the associated session configuration features that it contains in the New Session dialog.

  4. From the Select a trace scenario drop-down list on the Live Trace tab of the New Session dialog, select the Local Network Interfaces Trace Scenario.

    The ETW Providers list is populated with the Name and Id (GUID) of the Microsoft-PEF-NDIS-PacketCapture provider, along with the Configure link, which provides access to the provider Advanced Settings dialog.

  5. In the ETW Providers list on the Live Trace tab, click the Configure link next to the Microsoft-PEF-NDIS-PacketCapture provider Id to display the Advanced Settings - Microsoft-PEF-NDIS-PacketCapture dialog.

  6. In the Advanced Settings dialog, click the Provider tab and then 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.

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

    The Microsoft-PEF-NDIS-PacketCapture 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. Note that you also have the option to specify a Fast Filter for this Live Trace Session in the Advanced Settings - Microsoft-PEF-NDIS-PacketCapture dialog, to focus on specific results and improve performance.

  8. Verify that the Analysis Grid is selected in the Start With drop-down list in the New Session dialog. If it is not, then select it.

  9. Click the Start button in the New Session dialog to begin capturing data.

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

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

  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 data you captured, as appropriate.

    Tip  When using the Microsoft-Windows-NDIS-PacketCapture provider in the Local Network Interfaces scenario, you can configure filtering that can help determine whether an NDIS layer is dropping packets.

    For example, by selecting the All Layers check box in the Advanced Settings – Microsoft-Windows-NDIS-PacketCapture dialog, you can specify that packets are intercepted on all layers of the NDIS stack. In addition, by selecting both the Ingress and Egress check boxes in the dialog, you can specify the traversal path (direction up and down the stack) in which packets are intercepted. By specifying all layers and both traversal paths for an adapter that is dropping packets, you make certain that dropped packet events will be generated for any layer. If packets are being dropped, you should be able to expose them in Message Analyzer as ETW events that have certain characteristics, as described in step 24 of the procedure Capturing Traffic on a Remote Host.

More Information
To learn more about configuring the Microsoft-PEF-NDIS-PacketCapture provider from the Advanced Settings - Microsoft-PEF-NDIS-PacketCapture dialog, including how to assign Fast Filter Groups to selected adapters, see Using the Advanced Settings - Microsoft-PEF-NDIS-PacketCapture Dialog.
To learn more about the unique filtering configurations and other advanced capabilities that are available for the Microsoft-Windows-NDIS-PacketCapture provider, including remote tracing, see Using the Advanced Settings - Microsoft-Windows-NDIS-PacketCapture Dialog.

Applying a WFP Layer Set Filter to a Network Tunnel Traffic and Unencrypted IPSEC Trace
The hypothetical high-level issue in this example is that a Network Administrator wants to run a Live Trace Session that directionally isolates TCP traffic on a client computer to detect connectivity issues while at the same time reduce the amount of TCP traffic that is captured to streamline performance. Message Analyzer enables the administrator to use the WFP Layer Set filter configuration of the Microsoft-PEF-WFP-MessageProvider in the Network Tunnel Traffic and Unencrypted IPSEC Trace Scenario to isolate inbound V4 traffic at the Transport Layer as a possible starting point for detecting network connectivity issues. Note that the WFP Layer Set filter configuration also enables capture of outbound V4 traffic at the Transport Layer in addition to inbound and outbound V6 traffic, in any combination.

To apply WFP Layer Set filtering to a Network Tunnel Traffic and Unencrypted IPSEC trace and isolate IP traffic

  1. On the client computer, perform steps 1 through 3 of the previous procedure: To filter data on a specific network interface in a Local Network Interfaces trace.

  2. From the Select a trace scenario drop-down list on the Live Trace tab of the New Session dialog, select the Network Tunnel Traffic and Unencrypted IPSEC Trace Scenario.

    The ETW Providers list is populated with the Name and Id (GUID) of the Microsoft-PEF-WFP-MessageProvider, along with the Configure link, which provides access to the provider Advanced Settings dialog.

  3. In the ETW Providers list on the Live Trace tab, click the Configure link next to the Id of the Microsoft-PEF-WFP-MessageProvider to display the Advanced Settings - Microsoft-PEF-WFP-MessageProvider dialog.

  4. In the Advanced Settings dialog, click the Provider tab to display the WFP Layer Set inbound and outbound transport filters.

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

  5. In the WFP Layer Set pane on the Provider tab, deselect the Outbound Transport V4, Inbound Transport V6, and Outbound Transport V6 check boxes; then ensure that the Inbound Transport V4 check box is selected.

    With this WFP Layer Set configuration, the TCP messages that this Live Trace Session captures will be inbound TCP packets only.

  6. Verify that the Analysis Grid is selected in the Start With drop-down list in the New Session dialog. If it is not, then select it.

  7. Click the Start button to begin capturing data.

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

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

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

  10. From the Viewpoints drop-down list in the Viewpoints group on the Message Analyzer Ribbon, select the TCP item to filter all TCP traffic to top-level so you can more easily examine the TCP inbound traffic that you captured for signs of connection or transmission issues.

    For example, with the Inbound Transport V4 filter, you could focus only on TCP acknowledgement traffic to see whether you have a large number of duplicate ACK messages. You could add the TCPDiagnosis column to the Analysis Grid to see diagnosis message summaries that provide that indication. To further expose such messages, apply the following View Filter:  *TCPDiagnosis contains "dup-ack". You might also go back into the WFP Layer Set and select the Outbound Transport V4 filter only, and thereafter in the trace results, apply the following View Filter so you can focus on outbound TCP synchronization traffic from the client:  tcp.syn==true.

    In either case, you can look at diagnosis error messages in the DiagnosisTypes column of the Analysis Grid to see what TCP issues you might have. The goal in creating these WFP Layer Set filtering configurations is to capture the least amount of traffic to resolve TCP connectivity and/or transmission problems.

Applying a Session Filter to a Loopback and Unencrypted IPSEC Trace
The hypothetical high-level issue in this example is that a Network Administrator has a client computer 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, or possibly packets are being dropped by the network or client firewall.

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 Microsoft-PEF-WFP-MessageProvider in a Loopback and Unencrypted IPSEC Trace Scenario to minimize low-level traffic at the Data Link Layer and a Session Filter to capture only top-level TCP messages or messages containing TCP in the stack. When the trace is complete, the administrator then adds Window, Options, and TCPDiagnosis columns to the Analysis Grid viewer column layout and also applies 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:

  • Ensure that loopback traffic is being filtered out by applying IPv4 and IPv6 Fast Filters such as !127.0.0.1 and !::1, respectively, or filter out the IP address that a local application is using, if applicable. Otherwise, there can be duplication of TCP retransmit messages.

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

  • Verify whether the network is dropping packets, for example, a router with excessive memory utilization might be unable to keep pace with packet traffic.

  • Following the initial trace results, verify whether client computer Firewall rules are causing TCP packets to be dropped, or whether the PEF-WFP-MessageProvider is causing it; see Checking for Dropped Packets.

To apply a Session Filter to a Loopback and Unencrypted IPSEC trace and evaluate TCP diagnostics

  1. On the client computer, perform steps 1 through 3 of the previous procedure: To filter data on a specific network interface in a Local Network Interfaces trace.

  2. From the Select a trace scenario drop-down list on the Live Trace tab of the New Session dialog, select the Loopback and Unencrypted IPSEC Trace Scenario.

    The ETW Providers list is populated with the Name and Id (GUID) of the Microsoft-PEF-WFP-MessageProvider, along with the Configure link, which provides access to the provider Advanced Settings dialog.

  3. In the Session Filter text box of the New Session dialog, enter the following Session Filter to capture top-level TCP messages only:

    \TCP

    Note  By using the Loopback and Unencrypted IPSEC Trace Scenario with the Microsoft-PEF-WFP-MessageProvider and applying the specified Session Filter, the collected message count on the client computer will be reduced.

  4. Verify that the Analysis Grid is selected in the Start With drop-down list in the New Session dialog. If it is not, then select it.

  5. Click the Start button in the New Session dialog to begin capturing data.

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

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

  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. From the Column Chooser Tool Window, add TCP Window, TCP Options, and TCPDiagnosis columns to the Analysis Grid viewer column layout.

  9. Filter out all TCP messages that do not have a diagnosis error by entering the following Filter Expression in the text box of the View Filter Tool Window and clicking the Apply button on the toolbar of the window:

    TCP#DiagnosisLevels

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

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

  12. 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, then notwithstanding dropped packets, you should 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.

  13. 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 in relation to IP conversations, including those that have TCP Options, you can use the Column Chooser window to add a Network column (message hierarchy path is IPv4.Datagram.Network) and a Transport column (message hierarchy path is TCP.Segment.Transport) to the Analysis Grid viewer. You can then use the Group feature on each of these columns to pivot the data into differently organized data displays that provide alternate contexts for viewing TCP Options, as further described by the procedure in Applying TCP View Filters to Loopback and Unencrypted IPSEC Trace Results.

  14. 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. You might also consider applying the TCP Three-Way Handshake Sequence Expression to see the context in which these messages occur.

Checking for Dropped Packets  If you want to perform additional checks to determine whether dropped packets are causing TCP retransmits, perform the following steps:

  1. In the current Analysis Session, click the Edit button in the Session group on the Ribbon of the Message Analyzer Home tab to open the Edit Session dialog.

  2. In the ETW Providers list, click the Configure link for the Microsoft-PEF-WFP-MessageProvider to open the Advanced Settings - Microsoft-PEF-WFP-MessageProvider dialog.

  3. On the ETW Core tab of the dialog, click the Keywords(Any) ellipsis and select the ut:Dropped event keyword option in the ETW Keyword Filter Property dialog.

  4. On the Providers tab of the dialog, select the Select Discarded Packet Events option.

  5. Click OK to exit the dialog and then click the Apply button in the Edit Session dialog to apply the changes you specified.

  6. Restart the session by clicking the Restart button in the Session group on the Ribbon of the Message Analyzer Home tab.

  7. At a suitable point, stop the Live Trace Session by clicking the Stop button in the Session group.

  8. Check whether the Firewall is blocking packets:

    • Click the Show Column Filter Row icon in the upper left corner of the Analysis Grid viewer to display the Column Filter text boxes.

    • Enter the term “Discard” in the Column Filter text box beneath the Summary column header in the Analysis Grid to expose any messages that might indicate the Firewall was involved in blocking traffic.

  9. Check whether the Microsoft-PEF-WFP-MessageProvider is dropping packets:

    • In the trace results, select the ETW Viewpoint from the Viewpoints drop-down list on the Message Analyzer Ribbon to display only ETW messages in the Analysis Grid viewer.

    • Apply the following View Filter to the results to verify whether the ut:Dropped event is present in one or more ETW messages:
      ETW.EtwProviderMsg.EventRecord.Header.Descriptor.Keywords==0x0000010000000000
      You can also look for the KW_DROPPED flag value in the Details Tool Window after selecting any ETW message.

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

Applying Fast Filters to a Loopback and Unencrypted IPSEC 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 does not 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 Loopback and Unencrypted IPSEC trace and isolate specific messages to reduce data volume

  1. On the server computer, perform steps 1 through 3 of the previous procedure: To filter data on a specific network interface in a Local Network Interfaces trace.

  2. From the Select a trace scenario drop-down list on the Live Trace tab of the New Session dialog, select the Loopback and Unencrypted IPSEC Trace Scenario.

    The ETW Providers list is populated with the Name and Id (GUID) of the Microsoft-PEF-WFP-MessageProvider, along with the Configure link, which provides access to the provider Advanced Settings dialog.

  3. In the ETW Providers list on the Live Trace tab, click the Configure link next to the Id of the Microsoft-PEF-WFP-MessageProvider to display the Advanced Settings - Microsoft-PEF-WFP-MessageProvider dialog.

  4. In the Advanced Settings dialog, click the Provider tab to display the Fast Filters configuration.

    By default, there are no Fast Filters set.

  5. In the Fast Filters pane, click the Fast Filter 1 drop-down list and select the TCP port item.

  6. In the text box to the right of the Fast Filter 1 drop-down list, specify a port number such as <80>.

  7. Alternatively, to isolate the data to a specific client IP address, click the Fast Filter 2 drop-down list and select the IPv4 item.

  8. In the text box to the right of the Fast Filter 2 drop-down list, specify a client IPv4 address in a format similar to the following: <192.168.1.1>.

  9. Click the OK button to exit the Advanced Settings dialog.

  10. Verify that the Analysis Grid is selected in the Start With drop-down list in the New Session dialog. If it is not, then select it.

  11. Click the Start button in the New Session dialog to begin capturing data.

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

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

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

  14. Examine the captured data to confirm that slow server responses is an issue.

    For example, if you are working with message data from a protocol that uses request/response pairs (viewed as operation nodes in the Analysis Grid) such as HTTP, SMB, or DNS; ports 80, 445, and 53, respectively; you can add a ResponseTime column to the Analysis Grid viewer and then sort that column to view the messages that have the highest server response times. Note that high server response times can typically rule out network issues as the cause of delays, providing that operation TimeElapsed values are reasonable.

Applying Hostname and Port Filters to an Unencrypted HTTPS 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 Unencrypted HTTPS Trace Scenario with the Microsoft-Pef-WebProxy provider Hostname Filter to isolate messages sent to and from a particular web site, and a Port Filter to isolate messages on a particular port, such as 80. This scenario is useful for achieving better performance than using a comparable Session Filter that specifies a particular destination IP address and port number. The Hostname Filter and Port Filter act similarly to the way Fast Filters do in that they cause less data to be collected, allow for minimal parsing, 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.

Note  In this scenario, you will be unable to analyze the message data for possible TCP issues because the Microsoft-Pef-WebProxy provider captures messages above the Transport Layer.

To apply HTTP filters to an Unencrypted HTTPS trace and expose status indications

  1. On the client computer, perform steps 1 through 3 of the previous procedure: To filter data on a specific network interface in a Local Network Interfaces trace.

  2. From the Select a trace scenario drop-down list on the Live Trace tab of the New Session dialog, select the Unencrypted HTTPS Trace Scenario.

    The ETW Providers list is populated with the Name and Id (GUID) of the Microsoft-Pef-WebProxy provider, along with the Configure link, which provides access to the provider Advanced Settings dialog.

  3. In the ETW Providers list on the Live Trace tab, click the Configure link next to the Id of the Microsoft-Pef-WebProxy provider to display the Advanced Settings - Microsoft-Pef-WebProxy provider dialog.

  4. In the Advanced Settings dialog, click the Provider tab to display the filter configuration.

  5. In the Hostname Filter text box, enter a Hostname value in a format similar to the following:

    www.bing.com

  6. In the Port Filter text box, enter an HTTP Port number in a format similar to the following:

    80

  7. Click OK to exit the Advanced Settings dialog.

  8. Verify that the Analysis Grid is selected in the Start With drop-down list in the New Session dialog. If it is not, then select it.

  9. Click the Start button in the New Session dialog to begin capturing data.

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

  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. Ensure that the Column Chooser Tool Window is displayed. If it is not, then in the View Options group on the Ribbon of the Message Analyzer Home tab, click the Choose Columns button to open the Column Chooser window.

  13. In the Column Chooser, scroll down to the HTTP message hierarchy, click its expansion node, and then expand the Response node.

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

  15. 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 status code table in the Addendum 1: HTTP Status Codes section of this documentation.

Filtering Live Trace Session Results

This section provides examples of possible ways to filter displayed data that was collected from live traces that utilized the Local Network Interfaces, Loopback and Unencrypted IPSEC, and Unencrypted HTTPS Trace Scenarios. The types of filters that are applied consist of Address, Port, HTTP, and TCP View Filters.

Applying a View Filter to Local Network Interfaces 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 Network Interfaces 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 Local Network Interfaces trace results that removes unwanted traffic

  1. On the client computer, perform steps 1 through 4 of the previous procedure: To filter data on a specific network interface in a Local Network Interfaces trace.

    Depending on your operating system, either the Microsoft-PEF-NDIS-PacketCapture provider or the Microsoft-Windows-NDIS-PacketCapture provider and its Id are displayed in the ETW Providers list on the Live Trace tab of the New Session dialog.

  2. Verify that the Analysis Grid is selected in the Start With drop-down list in the New Session dialog. If it is not, then select it.

  3. Click the Start button in the New Session dialog 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 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 Tool Window, enter the following Filter Expression to remove unwanted SQL and RDP traffic, while substituting the actual SQL server IP address for the italic value:

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

  7. On the toolbar of the View Filter window, click the Apply 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 the algorithms or behaviors that expose unique virus signatures.

Applying an HTTP View Filter to Loopback and Unencrypted IPSEC 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 the Loopback and Unencrypted IPSEC Trace Scenario with the Microsoft-PEF-WFP-MessageProvider 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 the Loopback and Unencrypted IPSEC Trace Scenario to ensure capture of all HTTP traffic, rather than the Unencrypted HTTPS Trace Scenario with the Microsoft-PEF-WebProxy provider, which captures browser traffic only. 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 Network Monitor, which returns only the HTTP headers rather than all message fragments as Message Analyzer does.

To apply an HTTP View Filter to Loopback and Unencrypted IPSEC trace results and examine all HTTP-related messages

  1. On the server computer, perform steps 1 through 3 of the previous procedure: To filter data on a specific network interface in a Local Network Interfaces trace.

  2. From the Select a trace scenario drop-down list on the Live Trace tab of the New Session dialog, select the Loopback and Unencrypted IPSEC Trace Scenario.

    The ETW Providers list is populated with Microsoft-PEF-WFP-MessageProvider information.

  3. Verify that the Analysis Grid is selected in the Start With drop-down list in the New Session dialog. If it is not, then select it.

  4. Click the Start button in the New Session dialog to begin capturing data.

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

  5. While Message Analyzer is capturing data, attempt to reproduce any conditions that cause the client or web server 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. In the View Filter Tool Window, enter the following atomic Filter Expression:

    HTTP

  8. In the View Filter window, click the Apply button to isolate all HTTP operations and other messages that contain HTTP in the message 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 HTTP operations (request and response messages) into their original chronological order for a different analysis perspective.

  9. 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 Tool Window and execute the Group command on the StatusCode and ReasonPhrase columns to create groups of identical HTTP status codes, for ease of analysis.

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

Applying TCP View Filters to Loopback and Unencrypted IPSEC 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 Loopback and Unencrypted IPSEC trace results and expose TCP diagnostics

  1. On the server computer, perform steps 1 through 3 of the previous procedure: To filter data on a specific network interface in a Local Network Interfaces trace.

  2. From the Select a trace scenario drop-down list on the Live Trace tab of the New Session dialog, select the Loopback and Unencrypted IPSEC Trace Scenario.

    The ETW Providers list is populated with Microsoft-PEF-WFP-MessageProvider information.

  3. Verify that the Analysis Grid is selected in the Start With drop-down list in the New Session dialog. If it is not, then select it.

  4. Click the Start button in the New Session dialog to begin capturing data.

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

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

  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. If the Column Chooser Tool Window is not displayed, click the Choose Columns button in the View Options group on the Ribbon of the Message Analyzer Home tab to display it.

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

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

  10. In the text box of the View Filter Tool Window, enter the following Filter Expression:

    TCP#DiagnosisLevels

  11. On the toolbar of the View Filter window, click the Apply button to filter the Loopback and Unencrypted IPSEC trace results and verify whether you have any TCP-related errors.

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

  13. To isolate lost or out-of-order TCP segments, enter the following Filter Expression in the text box of the View Filter window and then click Apply to start the filtering process:

    *TCPDiagnosis contains "Segment-Lost"

    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 contains "Segment-Lost"

  14. 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::WindowScaled < 1000

  15. 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  If you are interested in examining the IP conversations where the TCP options were negotiated, along with the TCP ports that carried the traffic, add an IP Network column and a TCP Transport column to the Analysis Grid viewer column layout and then perform the Group function on these columns to quickly reorganize the data into common groups. 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.

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

    • Ensure that Selective Acknowledgement (SACK) is enabled, to minimize TCP retransmits.

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

  16. To search for incomplete three-way handshake patterns in a trace along with surrounding messages potentially related to a failure, do the following:

    • Click the Viewpoints drop-down list in the Viewpoints group on the Ribbon of the Message Analyzer Home tab, and then select the TCP Viewpoint to display all TCP messages at top-level.

    • Click the Find Messages button in the View Options group on the Ribbon of the Message Analyzer Home tab.

    • Enter any of the following Filter Expressions in the Find Messages text box and then successively click the Find binoculars icon to locate messages that meet the specified filtering criteria:
      TCP::TCPDiagnosis contains "Segment-Lost"
      TCP::AcknowledgementNumber==0
      TCP::Flags.Syn==true && TCP::Flags.Ack==true


    You can use the method described immediately above to find TCP messages that participated in incomplete three-way handshake operations. By locating the TCP messages that contain TCP Options and broken or incomplete patterns of SYN, ACK, SequenceNumber, and AcknowledgementNumber field values, you may be able to determine where failures have occurred.

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

    Table 17. 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 about three-way handshake sequence expressions, see Matching Message Sequences.

Applying a View Filter to Unencrypted HTTPS 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 Unencrypted HTTPS  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 operations where server responses are slow, as indicated by high ResponseTime values.

  • 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 Unencrypted HTTPS trace results and expose HTTP status codes

  1. On the client computer, perform steps 1 through 3 of the previous procedure: To filter data on a specific network interface in a Local Network Interfaces trace.

  2. From the Select a trace scenario drop-down list on the Live Trace tab of the New Session dialog, select the Unencrypted HTTPS Trace Scenario.

    The ETW Providers list is populated with the Microsoft-Pef-WebProxy provider information.

  3. Verify that the Analysis Grid is selected in the Start With drop-down list in the New Session dialog. If it is not, then select it.

  4. Click the Start button in the New Session dialog to begin capturing data.

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

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

  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. Ensure that the Column Chooser Tool Window is displayed. If it is not, click the Choose Columns button in the View Options group on the Ribbon of the Message Analyzer Home tab to display it.

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

  9. In the HTTP message hierarchy, locate the StatusCode and ReasonPhrase fields under the Response node and double-click each one to add it as a new column in the Analysis Grid viewer column layout.

  10. In the Column Chooser window, open the Global Annotations node and then double-click the ResponseTime annotation to add it as a new column in the Analysis Grid viewer.

  11. Click the Viewpoints drop-down list in the Viewpoints group on the Ribbon of the Message Analyzer Home tab and select the HTTP Viewpoint to push all HTTP messages to top-level with no messages above, for ease of analysis.

  12. In the text box of the View Filter Tool Window, enter the following Filter Expression text:
    #ResponseTime >=1

  13. On the toolbar of the View Filter window, click the Apply button to isolate the HTTP operations where the server response to client requests is greater than or equal to 1 second.

    Operations that meet the ResponseTime criteria of the applied filter would likely indicate excessive server response times, providing that the TimeElapsed for the entire operation is a reasonable value. Note that if the TimeElapsed is also taking a while, this could be an indication of network issues rather than a slowly responding server.

    Note  The ResponseTime is the difference between the Timestamp value of the first response message from the server minus the last Timestamped value in the request message stack.

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

  15. Isolate specific HTTP StatusCodes in the trace by typing “10”, “20”, “30”, “40”, or “50” into the Column Filter text box beneath the StatusCode column header, 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.

  16. Examine the different StatusCodes and ReasonPhrases to determine any problem areas that might provide some additional indications as to why the web server is performing poorly. To review the definitions of StatusCodes and ReasonPhrases, refer to the Addendum 1: HTTP Status Codes section of this documentation.

  17. Analyze the TimeElapsed column values in the Analysis Grid to verify whether overall HTTP operations are taking a long time.

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

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 runs the Network Tunnel Traffic and Unencrypted IPSEC Trace Scenario to take advantage of the Microsoft-PEF-WFP-MessageProvider that captures data at the Transport Layer and above, along with a Session Filter that isolates traffic on SMB port 445. The administrator then does the following:

  • Creates a new right-gradient Color Rule to highlight TCP diagnostic information.

  • Adds a TCP.TCPDiagnosis column to enable quick examination of TCP errors that appear in the trace.

  • Creates a new left-gradient Color Rule to highlight SMB error status.

  • Adds an SMB2.ErrorResponse.Header.Status.Value column to enable quick examination of SMB2 error values that appear in the trace.

  • Uses the Color Rule highlighting as a prompt to perform various operations for error analysis.

Applying Color Rules to Network Tunnel Traffic and Unencrypted IPSEC Trace Results

  1. On the client computer, perform steps 1 through 3 of the previous procedure: To filter data on a specific network interface in a Local Network Interfaces trace.

  2. From the Select a trace scenario drop-down list on the Live Trace tab of the New Session dialog, select the Network Tunnel Traffic and Unencrypted IPSEC Trace Scenario.

    The ETW Providers list is populated with Microsoft-PEF-WFP-MessageProvider information.

  3. In the Session Filter text box of the New Session dialog, enter the following Filter Expression:

    TCP.Port == IANA.Port.SMB

  4. Verify that the Analysis Grid is selected in the Start With drop-down list in the New Session dialog. If it is not, then select it.

  5. Click the Start button in the New Session dialog to begin capturing data.

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

  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. Create and save a new Color Rule with a right-gradient pattern and the following Filter Expression, 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, retransmits, and so on, to expose any possible TCP connection issues:

    TCP#DiagnosisTypes

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

  9. In the Column Chooser Tool Window, navigate the TCP message hierarchy to the TCP.Segment level and add the TCPDiagnosis field as a new column in the Analysis Grid viewer, so the you can easily view TCP error descriptions.

  10. Create and save a new Color Rule with a left-gradient pattern and the following Filter Expression, to highlight SMB Status errors that might have occurred during file share access:

    SMB2.ErrorResponse.Header.Status.Value > 0

  11. In the Column Chooser window, navigate the SMB message hierarchy to the SMB2.ErrorResponse.Header.Status level and add the Value field as a new column to the Analysis Grid viewer, so you can examine the values of any SMB errors that might have occurred.

  12. Perform the following operations to expose error messages for analysis purposes:

    • Display TCP messages at top-level to improve analysis by applying the TCP Viewpoint from the Viewpoints drop-down list on the Ribbon of the Home tab.

    • Analyze TCP error messages as appropriate to determine various TCP issues.

      For example, apply a Column Filter to the TCPDiagnosis column in the Analysis Grid viewer with the text “retransmit”, to isolate all error messages that contain the text “Retransmitted” in the description. Then apply an “ack” Column Filter to isolate all error messages that contain the text “Dup-Ack” in the description.

    • Display all SMB2 messages in the trace as top-level operations by applying an SMB2 Viewpoint from the Viewpoints drop-down list on the Ribbon.

    • Display SMB2 error messages only by clicking the Hide Operations in the Viewpoints group on the Ribbon and then reapply the above specified Color Rule filter as a View Filter:

      SMB2.ErrorResponse.Header.Status.Value > 0

      To view the filenames where such errors occurred, add an SMB2Request.Filename column to the Analysis Grid viewer.

      At this point, you might also invoke one of the SMB chart viewers from the File Sharing category in the New Viewer drop-down list for further statistical analysis, for example, the SMB File Stats viewer.

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.

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв
Показ:
© 2014 Microsoft