none
Severe GDI object leak inside Network Monitor RRS feed

  • Question

  • Hi there,

    I'm running Network Monitor 3.4 x64 on two systems, and in both cases, I see an extremely severe GDI handle leak in the netmon.exe process immediately upon starting a capture. The leak is exacerbated by greater network traffic on the captured interfaces, and with moderate traffic, can exhaust the GDI object limit of 10,000 for the process within mere minutes. The two systems contain different hardware (desktop/laptop) but a similar set of software so it is plausible that a program on the computer is the culprit rather than Network Monitor itself, however, I'm uncertain how to determine which is responsible assuming this is the case.

    Could anyone provide any insight as to how to track down the source of this leak as it makes Network Monitor effectively unusable?

    EDIT: I've compared the DLLs loaded into the process on each computer and there was only one in common (DisplayFusion AppHook). I've disabled this hook on one system but am still able to reproduce the exact same behaviour. Looking at the process threads there also doesn't appear to be anything unusual that has been injected into the process.

    Kind regards,

    Samuel Leslie


    • Edited by nexiom Monday, January 21, 2013 3:46 PM Extra info
    Monday, January 21, 2013 3:35 PM

Answers

  • Hi Michael,

    Each of the involved systems has approx. ~80GB of space available on the volume we're capturing to and we're using the default of 2% so lack of space shouldn't be an issue. That being said, I can't seem to reproduce the issue anymore! The Network Monitor GUI GDI leak remains and is present every single execution, but both the GDI leak and the erroneous free disk space errors in NMCap.exe seem to have gone and I'm at a loss as to explain why.

    At any rate, if I can reproduce them (reliably) I'll update the thread. I'd be interested in any advice on tracking down the source of the GDI leak in NetMon GUI if anyone can help as it's still present and effectively cripples the usability of the application, but as for the other two issues, they're seemingly "dead" for now.

    Kind regards,
    -SDL

    • Marked as answer by Paul E Long Thursday, February 14, 2013 4:11 PM
    Wednesday, February 6, 2013 2:26 PM

All replies

  • The UI is not suited for long term or high volume captures.  The network conversation tree will continue to grow as new traffic comes in.  The UI also doesn't have a concept of circular capture, so it will continue to capture until diskspace is gone.

    For captures like this you should use the command line tool, NMCap, which is designed to run for long periods of times and handle busy data as well.  You should have more luck with NMCap.

    Paul

    Monday, January 21, 2013 10:39 PM
  • Hi Paul,

    Thanks for your reply. The amount of capture we're attempting isn't particularly high volume (100Kb/s typical maximum) or long term (10 mins tops) but I took a look at the nmcap.exe CLI tool. Amazingly, I'm seeing the same GDI leak I reliably can reproduce in netmon.exe. That is, when running nmcap.exe it'll start allocating (and leaking) GDI objects at an alarming rate in the same manner as netmon.exe. The fact it's allocating GDI objects at all is bizarre being a command line utility. I've also seen some odd behaviour with it terminating with out of disk space warnings despite this clearly not being the case.

    I've isolated the issue at some level to the capture filter. It turns out that adding in any form of capture filter results in the GDI object leaks. So, by way of example:
    nmcap.exe /network * /capture -< will run fine
    nmcap.exe /network * /capture (tcp) -< will leak GDI objects

    Netmon.exe will always leak GDI objects regardless of whether a filter is specified or not.

    Can this please be looked into? The nmcap.exe tool doesn't seem viable as while the GDI object leakage is bizarre, it doesn't affect the functionality of the program being a console application, however, instead the capture will prematurely terminate with spurious out of disk space errors. The netmon.exe tool doesn't seem to have this issue, but leaks GDI objects in all cases to the point where its functionality is completely compromised due to UI elements failing to draw.

    I'm more than happy to assist with providing any additional diagnostic data that may help determine the root cause?


    Kind regards,
    Samuel Leslie

    • Edited by nexiom Tuesday, January 22, 2013 1:09 PM Minor fixes
    Tuesday, January 22, 2013 1:07 PM
  • NMCap with a filter will cause state to be saved, and this will eat up memory over time.  While not all filters require the state to be saved, we have no way to know which ones do and which do not.  But you can control it by adding the /DisableConversations switch.  However, you now must figure out if you filter requires state (conversations) to work.  For the most part filters on TCP and below won't require conversations.  For other cases, we'd probably have to discuss case by case.

    So, I would expect memory to grow, but not GDI memory.  How are you determining that NMCap has a GDI leak?

    Thanks,

    Paul

    Wednesday, January 30, 2013 4:28 PM
  • Hi Paul,

    In my particular case I'm using the built-in "Authentication Traffic" filter which definitely does need conversation tracking (it's explicitly noted in the filter itself).

    I'm basing my assessment of a GDI leak by monitoring the number of GDI objects allocated to the process via Process Explorer. The object counts constantly rise in proportion to amount of captured network traffic. When using the Network Monitor GUI the default limit of 10,000 objects can be reached in minutes with moderate traffic making the tool effectively unusable in my case as we'd need a sample of I'd estimate at least 10-15 minutes. When the limit is hit, various graphics operations predictably begin to fail (e.g. drawing the Save dialogue) effectively necessitating terminating the process.

    Bizarrely, I can't seem to reproduce the GDI object leak in NMCap right now, so there must be some factor I don't yet understand. I was monitoring the GDI leaks using Process Explorer in the same manner as Network Monitor, and it definitely was increasing at a rapid rate in the same style. Unlike Network Monitor though, the GDI object leak would only occur when a filter was used, no matter how simple. If no filter was specified on the command line, the leak wouldn't occur.


    Thanks,
    -SDL

    Saturday, February 2, 2013 12:18 PM
  • Hi,

    You also mention a diskspace error message?  You could be hitting the diskspace limit set by Network Monitor which could be causing the undesired behavior.  How much space do you have on the capturing system and what are the options set in the Network Monitor GUI under Options -> Capture?  It defaults to 2% which can be a lot these days still.

    Thanks,


    Michael Hawker | Program Manager | Network Monitor

    Tuesday, February 5, 2013 11:06 PM
    Moderator
  • Hi Michael,

    Each of the involved systems has approx. ~80GB of space available on the volume we're capturing to and we're using the default of 2% so lack of space shouldn't be an issue. That being said, I can't seem to reproduce the issue anymore! The Network Monitor GUI GDI leak remains and is present every single execution, but both the GDI leak and the erroneous free disk space errors in NMCap.exe seem to have gone and I'm at a loss as to explain why.

    At any rate, if I can reproduce them (reliably) I'll update the thread. I'd be interested in any advice on tracking down the source of the GDI leak in NetMon GUI if anyone can help as it's still present and effectively cripples the usability of the application, but as for the other two issues, they're seemingly "dead" for now.

    Kind regards,
    -SDL

    • Marked as answer by Paul E Long Thursday, February 14, 2013 4:11 PM
    Wednesday, February 6, 2013 2:26 PM