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
The single most versatile feature in Message Analyzer is “Grouping”. It’s basically a replacement for the conversation tree where the conversation tree is just one kind of grouping. Slicing of data has never been better. It’s like your Ginsu knife deal just got better.
A great first example is grouping by Module. Just right click the module column in summary grid and select Group.
Each group is displayed in the analysis grid with a count of the matching messages in the parenthesis. If you have multiple levels of groups, the number indicates the number of subgroups. At the top, you’ll notice that a grouping box has been added for Module. You can remove it with the red X, or move it to change the order of grouping. This view has conveniently collated the traffic.
And since we reassemble and associate request/response as operations, the list is concise and complete. The TCP group will contain all the TCP specific handshake stuff and unidentified traffic, but none of the SMB2 related fragments. Keep in mind that the Module is determined by the top level. This is a general rule about columns as there is a tree underneath with many different values. So even though there might be TCP in the tree, the top level takes precedence and is displayed.
This question has two answers, because it’s really two questions. One could be, where’s that tree control on the left side? The other more precise question is, how can you dice data like the Network Monitor 3.x conversation tree?
As for the control, we are working on it. The new embedded tree has some advantages, like it takes up less space. But when you want to see related traffic and drive traffic from the tree the separate control is better. For now the control is still on the design table.
For the second part of the question, providing a grouping that represents the conversation view is easy, though with some differences. We can map the Process ID/Network/Transport type view by using the ProcessId field of ETW and some properties we’ve created to expose the Network and Transport conversations as strings. The process ID is buried down in the ETW layer, where all messages from our new providers start. By right clicking and selecting ProcessId, you can quickly add it as a grouping.
For the Network and Provider properties, you have to go to the Column Chooser. In fact you need to add them as columns first, and then right click and add as grouping. In the future I’m sure we can remove some steps.
Here’s the Network property which exists at multiple modules:
And here is the Transport property, again in multiple modules:
One difference concerning the Network/Transport properties and Network Monitor conversations is that the properties don’t define the hierarchy. They only provide a string to describe the port definition. Also there is no conversation ID anymore. Also, if there is tunneled traffic, the last property wins again. So only the top layer is exposed.
Once you are finished, you can right click each Grouping box and collapse all.
Then you can start expanding Processes and Network parents to see the structure.
Another huge benefit of the tree being in the grid is that filtering now affects the tree. How many times have you wanted the tree to be filtered? No longer do you need a sharp eye to pick out a specific IPV4 address and related TCP connections. Now the grouping tree is shown based on the current filter so you can apply an IPv4.Address==192.168.1.13 and see only parts of the tree that involve that single client address.
As I mentioned previously you can move groupings around. Select and drag a grouping box to another location and re-pivot your data.
Transport is at the end:
Transport moved to the middle:
And now, this is where you should go out and play with grouping. Group by Diagnosis and see how many messages are affected by a diagnosis and what kinds there are. Group by destination or source and see who is getting the largest cut of the messages. Group by HTTP.ContentType and see types of objects being requested by your browser. And group by *FileName, (SMB2.FileName and SMB.FIleName), to see what traffic is associated with which file for SMB traffic. And of course you can save your groups by using Manage Columns, “save column layout as…”, which includes your groupings. Let grouping become a normal part of your analysis and embrace the power of this new feature.
To learn more about some of the concepts described in this article, see the following topics in the Message Analyzer Operating Guide on TechNet:
Suddenly this reminds me of the comment my old boss made switching from Mac/Apple to Windows - I don't want flexibility, I want to get some work done.
This has a long way to go compared to Network Monitor on getting work done.
Can it group based on process name?
We don't have a way to expose the process name yet, but we are working on it. But you can group on the process ID, which is done automatically with the Network Conversation Tree with Process ID.
The ability to easily select traffic by process name was easily (for me) the best feature of Network Monitor. I switched from Wireshark for this reason. Why on earth would you get rid of one of the most useful features? In Sept 2013, you posted that you're
"working on it". Message Analyzer looks great and and an impressive feature list, but I agree with Pete Wilson on "getting work done". Please make it useful.
Yes, believe me we hear this feedback frequently. And we will start addressing it in our next version soon (guessing 4-6 weeks right now). However, the original functionality was performance by polling the process tree. Today we use the built-in system
NDIS provider, rather than shipping our own. However, the inbox driver doesn't implement the process tracking, and it is expensive and risky to port into the OS driver at this point. So we purposely remove the functionality, but lost it in an attempt to converge
to one way to capture the NDIS network interface traffic.
Instead we are looking at alternate, more accurate methods, for tracking the process info. The next version is the first step in that direction, which uses the build-in kernel tracing to map process names to process ids. Moving forward we continue to look for
better ways to implement this feature, as each (Network Monitor and Kernel tracing) still have drawbacks.