Network tracing (packet sniffing) data to provide when troubleshooting.

  • Article

Applies to:

Windows Server 2012 R2

Windows 8.1

Windows Server 2008 R2

Windows 7

Windows Server 2012

Windows 8

Windows Server 2008 R2

Windows 7

Windows Server 2008

Windows Vista

Windows Server 2003

Windows XP

 

First published Dec 2012.  Updated May 2015.

 

When troubleshooting an issue that might be network related.  And you are capturing a network trace (sniffer trace, packet sniff).

At a minimum, gather the following data:

  • IPv4 address and IPv6 address:

Note:  The client (source) and server (destination). 

Additionally, if you are troubleshooting an application that is multi-tiered, get the ip addresses of the Domain Controller, DNS servers, DHCP servers, Proxy servers, File servers, Web servers, SharePoint servers, Exchange servers, SQL servers etc… on top of all the IP addresses that the client will interact.

Having it handy as a document, will save time for all your peers and support folks that are helping to troubleshoot the issue.

  • Time (HH:MM:SS):

Note:  Important to make sure that we captured the issue while it was occurring.

Note 2:  It’s also useful to correlate to an error log or .etl (WPT (WPRUI/WPR/Xperf) or a .dmp (DebugDiag/ProcDump/Adplus/WinDbg/Cdb) output.

  • Application name and the executables that make up the application that is having the problem, and it’s Process ID (PID) from Task Manager:

Note:  The PID will help when we are filtering (parsing) the network trace output.

  • Network share name that is having the problem:

If it’s a DFS, DFS-N, or DFS-R, all the servers that comprise these.

  • Website name (if troubleshooting a website/webpage related problem):
  • Document name (.doc, .docx, .xls, .xlsx, etc…):
  • Domain name/User name  (if troubleshooting an authentication problem):

Yong

P.S.  Original post:

Problem description:

Windows 8 RTM, after hibernating, when resuming the system, the connection will be “limited” for around a minute (60 seconds) before it finally connects all the way.

Action Plan:

We had our fellow peer (P1) gather a network trace per my previous post.

Network tracing (packet sniffing) built-in to Windows Server 2008 R2 and Windows Server 2012.
https://blogs.technet.com/b/yongrhee/archive/2012/12/01/network-tracing-packet-sniffing-built-in-to-windows-server-2008-r2-and-windows-server-2012.aspx

Data analysis:

P1 provides the network trace.  And that is it.

Issue:

I don't know what IP address that they got.  ipv4.address==172.x.x.x OR ipv6.address==fe80::x:x:x

What was the timeframe of the 60 seconds that was delayed?

Filtering the network trace.

The first packet with those addresses are:
10:31:17 a.m.
10:43:18 a.m.

Ok, that is 12 minutes with over 90,000 packets.
Talk about finding a needle in the haystack.

The moral of the story is, at a minimum, gather the following data when troubleshooting a network related issue:

IPv4 address:

IPv6 address:

Time (HH:MM:SS):

Ipv4 address of target:

Ipv6 address of target:

Application that is having the problem, and it’s Process ID (PID) from Task Manager:

Network share name that is having the problem:

Website name (if troubleshooting a website/webpage related problem):

Document name (.doc, .docx, .xls, .xlsx, etc…):

Domain name/User name  (if troubleshooting an authentication problem):

DC Ipv4/Ipv6 address:

DHCP Ipv4/Ipv6 address:

DNS Ipv4/Ipv6 address:

Comments

  • Anonymous
    September 16, 2014
      Applies to: Windows Server 2012 R2 Windows 8.1 Windows Server 2012 Windows 8 Windows Server 2008
  • Anonymous
    May 23, 2015
    ARCHIVED as of May 2015.  Instead look at Tool: Installing the Microsoft Message Analyzer version
  • Anonymous
    May 23, 2015
    Applies to: Windows Server 2012 R2 Windows 8.1 Windows Server 2012 Windows 8 Windows Server 2008 R2 Windows
  • Anonymous
    May 26, 2015
    Applies to: Windows 10 Windows Server 2012 R2 Windows 8.1 Windows Server 2012 Windows 8 Windows Server