When troubleshooting difficult connection or application issues, it can be very useful to see what is being transmitted over the network. Microsoft originally proposed the Microsoft network monitor who was succeeded by the Microsoft Message Analyzer. Unfortunately, Microsoft has discontinued Microsoft Message Analyzer and removed its download links. Currently, only the old Microsoft Network Monitor is available.
Of course, you can use third-party tools to take network captures, like WireShark. While some third-party tools may provide a better experience, Microsoft Network Monitor still holds up. In this article, we will see how to capture and inspect packets using the latest available version of Microsoft Network Monitor, one of the most popular tools on the market.
While I could have used WireShark, I found the interface and usability of Microsoft Network Monitor, out of the box, to be much easier to use. The same can be accomplished in WireShark, but you may need to do a lot more configuration in the interface.
Packet capture using Microsoft Network Monitor
First, we need to install Microsoft Network Monitor, you can locate the download here then proceed with its installation. Once Microsoft Network Monitor is installed, go ahead and launch the program. Once launched, you will click on New Capture.
Display of the start page
Then you will want to start monitoring by clicking on the Start button. This will instantly start capturing and you will see conversations starting to appear on the left side.
New capture screen displayed before capture begins
If you find that you get an error message that no adapter is attached, you should run Microsoft Network Monitor as an administrator. Also, if you just installed it, you may need to reboot.
One of the great advantages of using Microsoft Network Monitor is that it easily groups your network conversations on the left side. This makes finding specific processes much easier to find and deepen.
Viewing network conversations
Expanding one of the plus signs will show you the specific set of “conversations” that the network monitor may have captured and grouped under one process.
You will quickly find that with all of this incoming data, you will need to filter the noise more easily. An example of using a filter is the DnsAllNameQuery, under the DNS section of the standard filters. By adding this line to the display filter section and clicking Apply, you will only be able to display packets that are DNS queries, as below.
Displaying the DnsAllNameQuery filter
Creating filters or modifying built-in filters is very simple. In the Display filter field, there are several ways to create filters. By entering a protocol name and following it with a. (period), you will see an automatic entry of the possible field values to compare. Using the standard comparison operator of ==, we can see if some values are equal. We can even create multiple expressions using logical operators such as and and or. An example of what it looks like is below.
DNS.ARecord.TimeToLive == 14
There are also a few methods available, such as contains () and UINT8 (). You can see using the contains method below to filter only the DNS records that contain [google.com](http://google.com) and a TimeToLive of 14.
DNS.ARecord.TimeToLive == 14 AND
As you can see, there are several ways to combine the filters to make them useful and convenient to use. This is a great way to return only the data that interests you, especially since packet capture can get quite large. In the next section, we look at some more useful examples.
Examples of filters
A few practical examples, beyond those integrated by default, will greatly help you understand how to access the useful data you need.
Filtering by port number
Although it is possible to use HTTP to filter, using the following method allows you to take into account custom ports, such as 8080 or 8443, which is particularly useful when troubleshooting.
// Filter by TCP port number
tcp.port == 80 OR Payloadheader.LowerProtocol.port == 80
tcp.port == 443 OR Payloadheader.LowerProtocol.port == 443
TCP frames that have been fragmented are reassembled and inserted into a new frame in the trace that contains a special header called Payloadheader. By searching for both, we can ensure that we get all the data we are looking for here.
Find SSL negotiation frameworks
When troubleshooting, you may need to understand which SSL connections are being attempted to be negotiated. Although you cannot decrypt internal traffic, it will help you find the servers that the connection is trying to use.
// Filter by SSL Handshake
TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.HandShakeType == 0x1
Find TCP retransmissions and SYN retransmissions
To resolve download and file upload issues, you can see if there are many retransmissions occurring that could affect performance.
Property.TCPRetransmit == 1 || Property.TCPSynRetransmit == 1
Make sure that conversations are activated, this filter depends on this functionality.
Reading of frames and hexadecimal data
By default, the window layout has two lower panes dedicated to frame details and hexadecimal details. In the frame details, each package is divided into its components. On the other side are the hexadecimal details which are the raw bytes and decoding. When you select a different section in the frame details, the same section in the Hex code will also be highlighted.
Display of frame details and raw hexadecimal data
Running network traces is very simple with the latest version of Windows. Although Microsoft has chosen to stop or disapprove of their internally created tools, some still thrive. There are many others, such as WireShark, but Microsoft Network Monitor still makes it easier to analyze and understand the information about the packets that are captured.