Download Message AnalyzerMessage Analyzer Download from Microsoft Download Center
Forums for SupportAsk questions and give feedback about Message Analyzer
Message Analyzer Operating GuideDeep technical documentation of all Message Analyzer features
VideosUsage and Diagnostic videos using Message Analyzer
Message Analyzer ConnectFile bugs, enroll in betas for Message Analyzer
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.
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.
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.
There are two possible outcomes a user wants. However, a confused user might try and use the same filter for two different situations.
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).
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.
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.
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.
To learn more about some of the concepts described in this article, see the following topics in the Message Analyzer Operating Guide on TechNet: