Question

I have a wrapper managed application(.net) over a COM Component(created using vb6) where Com component also uses native c++ dll.

Aplication runs as a background process and is supposed to run continously 24 X 7.
The application runs fine for certain time, but after certain time it crashes.
Possible reasons might be momory leak in c++ dll or com component.There is a lot of code for COM and c++ dll’s.

Since i am not familiar with com and c++, i am trying to resolve the problem from managed application. I am thinking for resolving this way : if the managed application starts consuming a lot of memory then i will restart my managed application.

1) How can we programatically monitor the total memory used by application (managed + unmanaged).

2) Would restarting the managed application also free up the unmanaged resources.

3) Is there any other alternative approach.

4) what are best debugging tools for monitoring managed application which also used unmanaged resources.

If i am not clear in my explanation then do ask me again.

Any help will be greatly appreciated.

Answer 1

How can we programatically monitor the total memory used by application (managed + unmanaged).

Use performance counters. In development/test easiest to use PerfMon to collect data in the background (using a data collection set) and then analyse the results in Excel or similar.

If you need to continue with this in production usage, the application can read performance counters itself (using System.Diagnostics.PerformanceCounter and related classes).

2) Would restarting the managed application also free up the unmanaged resources.

Yes.

3) Is there any other alternative approach.

Yes: fix the problem.

If the COM component or C++ library really leaks then those really need to be fixed (and if previously only used for short lived processes the leak could have been there for a long time).

You might be hitting an interaction of the .NET managed heap and GC with use of the native heap. The managed GC runs when there is memory pressure (i.e. would otherwise need to get more memory for the process to complete an allocation). If the managed wrapper is not allocating memory (or not much) there is no cause for it to run the GC. When you reference COM components from .NET the reference is held in a native wrapper type, this wrapper frees the COM instance (by releasing the last counted COM reference) when it is collected by the GC.

So if the GC does not run, then COM components will not be freed. All it takes is for COM instances to use a significant amount of memory and the total process memory commit can start to grow.

There are three approaches (in decreasing preference):

1. Use a method on the COM instance to free its memory use (e.g. releasing sub-objects) if it has one.
2. Explicitly free the COM component instances when the managed code has finished with them—don’t wait for GC—using Marshal.ReleaseComObject.
3. Force a GC.

#3 is the simplest, and can be used to confirm this approach by forcing a full GC after a few hours of running (e.g. on a timer) and looking at the memory usage performance counters. If it is the case the proceed with #1 or #2.

(This is essentially what happened in one of my first .NET projects, interaction of large amounts of unmanaged heap kept from being freed by a managed instance that wasn’t been collected due to lack of managed memory pressure. Fix in that case was to add an additional method to the key COM component to release the objects it was holding.)