When working on network issues it’s often useful to have a network capture (or trace) illustrating the startup of the computer. As a tap, a switch with spanning ports, or wireless capture equipment is rarely available it’s nice to do this right in the OS. Thanks to some improvements in both Windows 7 and Windows Server 2008 R2’s netsh it’s now possible to do just this. Most of the information in this post is gleaned from this article at TechNet Blogs Event Tracing for Windows and Network Monitor, but here I wish to present a simplified version of how to get and save a capture.
While there are more advanced methods available by running Microsoft Network Monitor (eg: capture filtering, remote shutdown via specially crafted packets, etc), this method will accomplish the majority of boot time network capture needs. This is also often much more useful than performing a capture via an external tap as it includes the ID and name of the process responsible for sending or receiving the given traffic.
To start a basic promiscuous mode capture listening on all interfaces with a 250 MB ring buffer (the defaults) and writing the trace file to the default location, use the following command, run as Administrator:
netsh trace start capture=yes persistent=yes
The capture will then run until stopped, even through reboots. To stop the capture and write the capture file out to disk, use the following command:
netsh trace stop
Consult the output from netsh trace start help to determine the other options you may want to set. Here are what I find to be the most-useful options:
maxSize=250 MB: Maximum capture size.
overwrite=yes: If there’s an existing trace of the same name, should it be overwritten?
traceFile=%LOCALAPPDATA%\Temp\NetTraces\NetTrace.etl: The output network Event Trace Log (ETL) file.
After an .ETL is obtained it needs to be opened and filtered with Microsoft Network Monitor to remove the extra headers. To do this ensure that you’re using the Windows set of parsers (Parser Profiles → NetworkMonitor Parsers → Windows), use the display filter:
From here additional filters can be used, such as the example screenshot above which uses the following filter to display all captured ARP traffic:
While I normally prefer Wireshark for capture analysis, I’ve found a number of cases where Network Monitor is more useful. The PID and Process Name capture, the IntelliSense-like autocompletion in the Display Filter, and the seemingly better decoding of a few protocols (SMB in particular) are great, even if the default layout is a bit crap and there aren’t as many built-in analysis tools. While obtuse to many It’s also quite a bit easier to get apprehensive customers to install a single Microsoft-provided tool on their devices than something they view as simply “a freeware tool from online”.