Need Help Eliminating Weak References In My App

Question

Hello. I am trying to resolve a memory leak(s) in my app. I've downloaded and ran RedGate's ANTS Memory Profiler 5.0 and the memory profiler tells me the leak has to do with WeakReferences.

The problem I am running into is that I've never heard of a WeakReference nor are they explicitly declared in my app. From the reading I've done I believe weak reference's are created when you have an object/resource that is trying to be destroyed but cant because too many other objects keep referencing it. I assume much the same way that a file can't be deleted because it is still in use.

So my question is how do I determine where these weak references are coming from? I have suspicions that it might be the use of ByRef? Another collegue suggested hashtables.

Hoping to get some clarification on weakreference detection and elimination and some clarification on my suspicions.

Thanks.

Answer 1

Using a WeakReference should not cause a memory leak. It would cause an object to be collected, but you still have a last minute option to access it.

I have not worked the the Memory profiler but:

All my memory leaks in .Net application have to do with events/delegates.

When you add a method to listen to an event, you create a reference from the object that contains the event (keyword) to the object that has the method you want to call.

If all other references to the object that contains the method are gone, you might think it will be collected, but there is still an (invisible) reference via the event.

Answer 2

In the battles with .NET resource leaks (memory/handles/threads/etc) we've found one culprit that rises above all else: lingering event handlers. If I have an object I'd like to dispose of, but I still have an event handler registered to an event of that object, then the object won't really go away--these zombies multiply and string together in chains until boom! you're managed app has what is for all intents and purposes a resource leak.

We've taken the shotgun approach and scour our most heavily used, and heaviest, classes for events we add both manually and by means of VB.NET's "Handles" keyword and ensure that RemoveHandler / -= is called for each during Dispose. We also explicitly Dispose of as much as possible.

ANTS is a great tool for tracking these down, but it's not a simple tool (but it is the simplest of the tools I've found for these issues). Spend some time getting familiar with it, and if you're on version 5 then make use of those new filters.

Unfortunately there's no silver bullet, it's one of my largest aggrivations with .NET because typically you don't know you have a problem until it's terribly wide-spread and hard to reign in.

Answer 3

I discovered my WeakReferences were being created by the System.Diagnostics.TextWriterTraceListener class. I still havent resolved my memory leak and I'm so deep in it I'm starting to question whether I have a memory leak or not but I'm relieved to know where the WeakReferences are coming from.

Thanks to all who posted!

Answer 4

This memory leak is a known bug in the .NET frameworks. __ENCList is an internal .NET class that is used to provide Edit and Continue functionality. The only resolution to this issue is to recompile in Release mode. (Which is unfortunate if you had been using the debug mode to provide detailed exception reporting in production environments.)

http://support.microsoft.com/?kbid=919481

Moataz Computer Engineer