Example 4: Performing a Manual Investigation of Diagnostic Log Files When Diagnostics cannot Identify or Repair the Problem

  • Article

Updated: December 23, 2009

Applies To: Windows 7, Windows Server 2008 R2

In this example scenario, a person - such as an advanced user or IT support professional - performs an in-depth manual examination of the data provided within the Event Trace Logs (ETL) files that Windows 7 NDF automatically rendered during an NDF diagnostic session in which NDF was unable to correct domain network connectivity problems. Following are the steps to manually investigate NDF ETL files.

Performing a manual investigation of ETL files.

Click Start, in Search programs and files, type Troubleshooting history, and then in the results, under Control Panel, click Troubleshooting History. This is shown in the following figure.

 

Troubleshooting History opens, as shown in the following figure.

 

Right-click the Windows Network Diagnostic report to investigate, and then click Save as. The Troubleshooting warning dialog opens, indicating the file you are saving might contain personal data, and that it should be sent only to a trusted person. This is shown in the following figure.

 

Click OK to continue. The Save As dialog opens. Specify a location and filename for the saved .CAB file, and then click OK, as shown in the following example.

 

The .CAB file is saved in the location you specified, with the specified name, appears with a file cabinet icon, as shown in the following example figure.

At this point, the non-advance user can provide the .CAB file to a support professional. The remainder of this example shows what a support engineer could explore by investigating the .CAB file on his own computer.

 

Navigate to the location where you saved the .CAB file, and then double click the file icon. The .CAB file opens and the compressed files are listed. This is shown in the following figure.

 

Note

The number and names of files contained within NDF .CAB files can vary between diagnostic sessions.

Highlight and select each file, as shown in the following figure.

Tip

Check-boxes appear on tablets to enable selection by touch or pen.

 

In the .Cab file toolbar, click Extract, as shown in the following figure.

 

Tip

You can specify almost any location to extract the files, depending on your needs. For example, in you are an advanced user and want to examine the files yourself, or if you are not an advanced user and want to copy and give the files to someone else to examine, you can extract the files to one of your personal folders. Alternately, if you are on a network, you could save the files to a network share that has been set up by a network administrator. This is demonstrated in the following two figures.

 

To extract the files to the local computer, specify a location on your computer to which you want the files extracted, and then click Extract. This is shown in the following figure.

 

To save the files to a network location to which you have permissions to create new folders, select Make New Folder, specify a name for the folder to which the files are extracted, and then click Extract.

The following figure shows a new folder named NDF Logs, in a network share, where the diagnostic log files will be extracted.

 

The following figure shows an example of the files extracted to the specified location on the network share.

 

The next step is to use the netsh trace convert command to convert the .etl diagnostic file for examination.

 

The netsh trace convert command saves the .etl file as a text (.txt) file, as shown in the following two figure.

 

 

 

In the previous figure, the command notepad DFCDF5EF-609F-41D3-9605-8DB9F47BBF37.Diagnose.0.txt is run to open the log files. This is shown as a split screen (left and right) in the following two figures.

 

 

Summary of this manual investigation of diagnostic ETL files

Interpreting transactions registered in the log:

  • WinInet was unable to reach the proxy server.

  • DNS attempted to resolve the hostname of the proxy server. DNS also dumped the Name Resolution Policy Table into the log for support purposes.

  • DNS hypothesized possible causes and examined:

    • Winsock, to check whether the DNS server was reachable.

    • IGD, to check whether wireless router was up.

    • Because the computer is configured for DirectAccess, Network Location Awareness (NLA), to check whether Inside/Outside (I/O) detection was correct.

  • Winsock returned indeterminate, hypothesizes to Transport (TCP/IP).

  • Internet Gateway Device (IGD) rejected, because the network was not a home network.

  • NLA found evidence that inside/outside detection was incorrect.

  • Transport attempted to reach the DNS server, but failed; hypothesized possible causes and examined:

    • IP Path, to see whether the DNS server was online.

    • WFP, to see whether the connection was allowed.

  • IP Path identified no problems.

  • WFP found a problem with an IPsec tunnel, hypothesized possible causes and examined: the IP Path, to see whether the IPsec gateway was up.

  • IP Path identified no problems.

Conclusion: The only helper class which returned a definite root cause and the repair was NLA; Inside/Outside detection was not correct. The repair was to re-run Inside/Outside detection, but detection came back with the same result. The problem does not appear to be local, but identifying it is beyond the scope of Network Diagnostics in Windows 7. This problem is continued as a Network Tracing example, Example: Troubleshooting an Expired Server Certificate, which demonstrates how to use Network Tracing to perform root cause analysis for a network problem which cannot be resolved on the client computer.