CCW & Managed Memory Leak?
From: Wayne (gleepnor_at_hotmail.com)
Date: 03/04/05
- Next message: Mattias Sjögren: "Re: Marshal.GetLastWin32Error errors"
- Previous message: Alex: "Help: floating modeless dialog in Word add-in (C#)"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 04 Mar 2005 05:42:54 GMT
I've posted about this before, but now I have more information (I
think) and was wondering if anyone might nudge me in the right direction.
I've got an ASP (*not* ASP.NET) application running on W2K/IIS5, that
utilizes a few COM+ library applications, each containing a few VB6 DLLs.
This runs in IIS5 high isloation mode, and W2K is utilizing the /3GB
switch.
A few of these DLLs have references to .NET assemblies. Two assemblies,
to be precise. The assemblies are properly registered (although one
doesn't have a strong name, so late-binding is used in COM, which I know
is Not Good). Other than the one strong name issue, everything else is
being done as described in Templeman and Mueller. (This problem
occurred before that assembly even entered the picture, anyway.)
The problem is that after the application has been running for a few days,
sometimes for a few weeks, we run into Out of Memory issues. Not system
memory, but managed memory, indicating a leak on the .NET side of things.
The ASP pages in the app that don't have any tie (through COM) to .NET
code still come up fine.
Inside the VB COM Code, aside from having a reference to the .NET DLL,
nothing special is being done to explicitly release the .NET object other
that set it to Nothing. Supposedly one shouldn't have to do anything.
Code review shows nothing unusual in the .NET code that would indicate a
"native" leak, and these assemblies run fine in a W2K3/IIS6 ASP.NET
environment. Of course there you do have worker process recycling to help
out with that somewhat, and there's that tweaking you have to do in the
web.config file when you're using a 4GB machine with the 3GB switch for
ASP.NET.
But this isn't IIS6, and it's not an ASP.NET application, so there's no
worker process recycling or web.config. Complicating this is the fact
that I can't even replicated this in an non-production environment even
under heavy load testing, and I can't do any invasive testing on the
production system, so I can't even run the CLR Profiler and gather
meaningful information.
In researching this though, I came across some older information off a
DevelopMentor where it is mentioned that managed leaks can occur when an
unmanaged process shuts down before GC can take place. To prevent this,
it is recommended that the unmanaged process explicitly call CoEEShutDown.
However, I've not been able to locate any examples of this outside of that
reference, and I'd like to make sure I'm not chasing ghosts.
I'm confident that if this was running under IIS6 and using the IIS6
Process Model, the process recycling would take care of it. Another
option I'm considering is moving these COM DLLs that use .NET to their own
Server COM+ apps so they can run in a dedicated process that stays alive
while idle.
If this was "normal" interop -- using COM DLLs within .NET -- I'd know
about explicitly calling ReleaseComObject() -- but in VB, all I've got is
Nothing. So to speak. :-)
Any advice would be appreciated.
-W-
- Next message: Mattias Sjögren: "Re: Marshal.GetLastWin32Error errors"
- Previous message: Alex: "Help: floating modeless dialog in Word add-in (C#)"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
