I want to point out some differences between Message Analyzer and Network Monitor in a short series of blogs. In this first one, let’s discuss filtering. There are some nice shortcuts that make it easier to type in filters and some differences from Network Monitor. Our goal with Message Analyzer was to keep the flexibility and power user’s expect of filter creation, while providing more help and shortcuts. So while there are certainly differences with how filters are created, the premise is the same.

Filtering Shortcuts

With a better Intellisense still being implemented on our side, there are some discovery issues for these features. However, you can still take advantage these features which I’ve arranged below as a chart. Keep in mind that there is an example in the filter library for most of these.





Partial Paths

TCP.Flags.Rst is the formal full path. But you only have to put the first and last entity name to make a valid, yet more inclusive filter. This might not be as fast as a more precise filter, but the extent of which depends on the filter.



You can also place a wild card before an element to filter any message which matched “port”. In this case UDP and TCP will be included, as well as any entity called port. It’s also important to note that port is a special way to reference both the source and destination. Again this is not as precise and performs worse than the example above.



This is similar to above, but an important point is that what is on the left side of address might not be obvious. The hardware address could come from wireless or Ethernet. An IP address might be via the firewall or NDIS driver. The IPv4 layer doesn’t exist in the firewall driver, though there is an IPv4 type address there. Remember that Address is the IPv4 type, but IPv4 is the protocol/module name. This is really important when creating capture filters because IPv4.Address in the firewall will not match.

Also important is that the right side can take on any valid literal form. So if you enter an IPv4 address on the right side, we will find those address that match that can return an IPv4 literal type.

Again, the address is a special way to reference both the source and destination addresses.

HTTP.Uri contains “msn”

TCP contains “Microsoft”


You can use contains to search a string or all the raw data. You can also search a specific protocol for a string. You can control case sensitivity, but by default it’s case insensitive. For instance ‘TCP contains “bLah” caseSensitive’ would search for “bLah” matching case. Look at the library to see other options for encoding types.

HTTP.Headers[“Host”] == “www.msn.com”


A big difference in Messages Analyzer is that we created a new type to handle HTTP data. Using a Map is a better data type to describe HTTP and others, but this makes the filtering the syntax different. An advantage is that we can now reference the HTTP fields using the exact match of the HTTP field name. Previously we had to remove dashes which could be confused for subtraction. For instance in Network Monitor 3.x, Content-Type was written as HTTP.Response.ContentType. But now you can Type HTTP.Response.Headers[“Content-Type”] which is more predictable and consistent.

On the other hand we group HTTP request and responses as operations. And for an operation we also expose fields which lift some information from the request or response. For example HTTP.ContentType = “jpeg”. Intellisense will make this easier to explore.

Tcp.port != 80

SMB.FileName ~= “”


This is a Dusey J A feature where math and practicality collide. If you’ve used Network Monitor a lot, you’ll know there’s a difference between tcp.port != 80 and !(tcp.port == 80). This mathematical irony seems to tickle the OCD in all of us.

See below for more detailed info.

Existence Example: TCP.Port != 3389 vs. SMB.FileName ~= “”

There are two possible outcomes a user wants. However, a confused user might try and use the same filter for two different situations.

Example 1: Getting Rid of Traffic

One example is that you want to get rid of TCP traffic by a port, commonly used to remove noise, like RDP traffic. A user could mistakenly type TCP.Port != 3389, for instance. But as you see below, the result is not correct. With Network Monitor we automatically assume you want to include only TCP traffic. Behind the scenes we apply a filter like (TCP && TCP. Port != 3389).



For Network Monitor, if you wanted to get rid of traffic, you type “!(tcp.Port == 3389)”. And of course this could be confusing since these two filters seem mathematically equivalent.


With Message Analyzer, the two statements are equivalent. And we no longer assume you want to look for traffic where the TCP.Port fields exists. Tcp.port != 3389 is the same as !(tcp.port == 3389).


Example 2: Displaying Data where the Field Exists

For this example I want to find messages where the SMB File Name is not blank. With Network Monitor, the default action is to only return those fields with the FileName field already there. So something like Property.SMBFileName != “”, returns what you want.


However with Message Analyzer, we don’t assume to check for existence and the result is not exactly what we want. In this example you see we return other messages like the TCP session setup. The filter is more explicit without the check for existence and since TCP doesn’t even have a matching entity, the message matches the filter because there it is true that the smb2.filename is not blank.


Now, we use a new operator, “~=”, which will additionally check for existence. You can see below that we’ve limited the capture to SMB traffic, because in only these messages does the filename entity exists.


Rather than continuing to violate mathematical laws, and to reduce our OCD medicine intake, we’ve added this new operator, ~=. This includes the check for existence and doesn’t return messages which don’t have the field in the first place. We believe this more explicit notation will provide less confusion and more clarity moving forward.

Right Click Add as Filter

We understand this feature doesn’t work perfectly now and we are working to implement it completely. In future versions, the experience for right clicking something in the UI and adding as a filter should be improved. But still, even in this current implementation, it is a helpful way to learn how to specify entities to filter on.

More to Come

There are even more complex things you can do with the filtering language that I will leave to a later post. Hopefully with these small tips, your filtering experience will be better. Please remember to provide us any feedback on our Connect site where we are hosting the Message Analyzer Beta.