locked
Severe UI Performance Problems Using Network Monitor With Filter RRS feed

  • Question

  • I have been using Microsoft Network Monitor 3.4 for over 6 months on a handful of Virtual Machines.  In the past few days, Network Monitor has demonstrated sever problems with two of the machines.  When I start a capture with a filter, the program is slow to update the Frame Summary as new packets are transmitted.  Attempting to view the Frame Details is almost impossible due to the severe delay when accessing them. 

    This seems to occur only when I use a Display Filter.  When I start a capture without filtering, I am able to quickly navigate and inspect all the messages.  Applying a filter slows the UI response to the point of unusability.

    I tried rebooting and reinstalling Microsoft Network Monitor.  Neither alleviated the problem.

    Has anyone else encountered this problem?  I read the question from a month ago about the GDI object creation, but my GDI objects do not seem to be increasing as described in that post.

    • Edited by lronat Friday, February 15, 2013 7:26 PM More details
    Friday, February 15, 2013 7:15 PM

Answers

  • Paul,

    I haven't had any real problems with the tool since the one day when I reported the issue.  If I experience these problems again I will try to find the cause by performing some of the tests that you suggest, but for now it seems to be working great.  It does seem like it was a resource problem, although if it was consuming a disproportionate amount of memeory I think I would have noticed.

    Louis

    • Marked as answer by Paul E Long Tuesday, March 19, 2013 6:59 PM
    Thursday, March 14, 2013 3:23 PM

All replies

  • When capturing the UI could have problems with higher speed traffics and lots of data.

    What display filter are you using?

    How much traffic are you capturing?  Does the pending count increase?

    Does this happen if you save a trace, then open it again and apply the same display filter?

    Thanks,

    Paul

    Monday, February 18, 2013 4:29 PM
  • I can't get this to happen consistently.  It was happening on two of my machines on Friday and was so severe I had to kill the netmon process repeatedly. Today the problem is more intermittent, beginning when I'm at 20K+ captures.  Even then it is just a slowdown and not a complete loss of response.  The pending count is a constant zero, but I do notice a slowdown in the update speed for the bottom "Parsed" progress bar and a delay when selecting different frames to inspect.  My traffic is probably around 1.5K captures per minute, on the average.

    I definitely see a slowdown when I use the filters 'Properties.Source.contains("ALIAS") OR Properties.Destination.contains("ALIAS")' and just filtering by 'SOAP.'  Turning off the filters greatly improved the performance as my capture number increases.

    With a saved trace, the performance is impacted by having the filter on.  When I open the saved trace I can quickly navigate through the entire frame summary without any delay to speak of.  However applying the filter causes some delay when using the scroll bar or selecting the packets for a closer inspection.

    Monday, February 18, 2013 11:38 PM
  • Sorry for the delayed answer.  Some filters are more expensive than others.  Look for strings with contains is probably the most expensive type of filter.  So I could see this cause more of a stress than no filter at all. 

    Is it quick without a filter?

    Do you think you might be running out of memory?  Does taskman show a high percentage of you memory used?  If you copy the resulting trace to another machine is it slow?

    Paul

    Thursday, March 14, 2013 2:09 PM
  • Paul,

    I haven't had any real problems with the tool since the one day when I reported the issue.  If I experience these problems again I will try to find the cause by performing some of the tests that you suggest, but for now it seems to be working great.  It does seem like it was a resource problem, although if it was consuming a disproportionate amount of memeory I think I would have noticed.

    Louis

    • Marked as answer by Paul E Long Tuesday, March 19, 2013 6:59 PM
    Thursday, March 14, 2013 3:23 PM