C# loosing WeakReference in finalizer - by Eric Ouellet

Status : 


Sign in
to vote
ID 780039 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 2/26/2013 9:20:05 AM
Access Restriction Public


Althought exists a strong reference to an object B, a WeakReference to B into A is not accessible in A finalizer as shown in the sample. The behavior is exactly like the WeakReference has already been garbage collected which is not the case.

That is very restricitve in many cases and also prevent proper WeakEvent clean up without any artifacts (like timer, polling, enumeration, ...).

That bug prevent the separation of different GC root tree classes (throught weak ref). Due this fact, it prevent proper clean up of weak referenced but dependend classes if required.

You can see: http://stackoverflow.com/questions/15093762/c-sharp-loosing-weakreference

See: "Steps to reproduce" for clean code to easily reproduce the bug (into console app).
Sign in to post a comment.
Posted by Eric Ouellet on 2/27/2013 at 11:35 AM
… Where 2 objects in relation could have different lifespan but are not static and you want one to be advise of something from the other, you use WeakEvent. I know you know that. But the only way (without artifacts: polling, controller, timer, …) for the handler of the event to advise the source that it is dying and to clean up its ~weak pointers to the handler is through the usage of handler finalizer having WeakReference to the source. But with a WeakReference that is not valid in finalizer, everything become impossible to realize simply (it add extraneous works and artifacts).
WeakReference should be valid in finalizer. Serious limitations will be hit by many programmers when working with WeakEvent if WeakReference are not still valide in finalizer and Microsoft itself will be penalized by that. I think it would be a nice gift to everybody to ensure validity of WeakReference in finalizer. It could be achieved by running WeakReference finalizer after any other ones.
Posted by Microsoft on 2/26/2013 at 7:11 PM
Thank you for your feedback. Unfortunately, this behavior is by design. The weak reference is itself a managed object with finalizer, and is subject to garbage collection and finalization just like any other managed object. The finalizers of two objects are not guaranteed to run in any specific order, even if one object refers to the other. That is, if Object A has a reference to Object B and both have finalizers, Object B might have already finalized when the finalizer of Object A starts. It is exactly what happened in your repro.

The following MSDN topics have more details about finalizers and weak references:


You may also find ConditionalWeakTable useful for what you are trying to do:

Jan Kotas
Posted by Microsoft on 2/26/2013 at 6:20 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Posted by Microsoft on 2/26/2013 at 9:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)