Question:

If, as part of our ASP.NET code, we create references to COM objects, do the (native) allocation of memory for these com objects get counted under the aspnet_wp process ?? Or are they going to be counted under, for instance InetInfo ?

Answer:

Yes they are counted under the ASPNET_WP process in Win2K.  You can dispose of your RCW wrapped objects by calling ReleaseComObject however don't call this more than once as you will get a disconnected error.  If what you suspect is true this will not be the root cause of your memory problem.  The ASP.NET process will garbage collect under memory pressure and it wrapped COM objects are released when their wrapper is GC'd.  Hence you can't actually run out of memory just because these things are kept around longer than you expect them to.
 
Some rule of thumb advice I found (reproduced without permission - sorry):
1) If you are a server application, calling ReleaseComObject may be an important and necessary requirement for getting good throughput.  This is especially true if the COM objects are STA-based (e.g. ASP compatibility mode uses the DCOM STA threadpool).  You would create a COM object, use it, then eagerly call ReleaseComObject on each request.
2) If you are a client application using a modest number of COM objects that are passed around freely in your managed code, you should not use ReleaseComObject.  You would likely inflict Disconnected errors on parts of the application by doing so.  The performance benefit of eagerly cleaning up the resources isn’t worth the problems you are causing.
3) If you have a case where you are creating COM objects at a high rate, passing them around freely, choking the Finalizer thread, and consuming a lot of unmanaged resources… There's no good solution, redesign.
 
Here's some other pointers to help when investigating memory concers with an ASP.NET web site.
 
318263 INFO: Identify Memory Leaks in the Common Language Runtime
http://support.microsoft.com/?id=318263
 
Log Performance Counters to Identify whether your leaked memory is managed or directly on the heap
 
Good MSDN Article on ASP.NET performance monitoring
 
You can use the windbg and cdb debuggers to identify how many of what managed objects are residing in your ASP.NET processes.  This can be helpful in identifying object leaks of user code referenced objects.
http://www.microsoft.com/ddk/debugging/installx86.asp
 
A description of using cdg and sos.dll is here:
 
Many of these "public" references were found on this blog.

Cheers,
Paul
--
This posting is provided "AS IS" with no warranties, and confers no rights.