http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Josh, There is a bug. It is in the parallel execution of the Application_End and the AppDomain.Unload http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment8http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment8Fri, 23 Jan 2009 01:30:02 GMTShould you have titled this post "... CLR bugs" when you have not even identified a bug? http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment7http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment7Fri, 23 Jan 2009 01:11:40 GMTI'm aware of this issue and I think that i know why. As you know you can set the modifier of the constructor, but you can't set the modifier of the deconstructor and I believe that there lies the problem. When you make a constructor static and assign an unmanaged resource to a static field than there's no deconstructor which can free the unmanaged resource. When you mark a class static you get even a compile error when you tryu to create a deconstructor. So my question is: Why can I create a constructor, but not a deconstructor. It seems to me that a static class isn't a whole different from a 'normal' class. The scope of a static class is the application domain and when the appdomain is disposed, the CLR should call the deconstructors on the static class used. So currently I try to avoid unmanaged resources stored in static fields. http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment6http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment6Thu, 22 Jan 2009 08:00:30 GMTHi Ayende, perhaps this link can shed some light onto your problem: [www.codeproject.com/.../...ApplicationShutdow.aspx](http://www.codeproject.com/KB/cs/ManagedApplicationShutdow.aspx) The golden rules of finalization are: Do not rely on it, do not take any locks inside a finalizer. Do not call to other objects which are also finalizable or do contain finalizable objects because the might be also finalized at this very moment if you have server GC enabled which means that you have several finalizer threads running. It seems you have cornered yourself with a design which relies on finalization order. You could mitigate it a bit if you use a CriticalFinalizer to get at least some ordering. [geekswithblogs.net/akraus1/articles/81629.aspx](http://geekswithblogs.net/akraus1/articles/81629.aspx) Yours, Alois Kraus http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment5http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment5Wed, 21 Jan 2009 23:04:03 GMTThe problem is that in this case, the shutdown process occurs concurrently with the cleanup code. http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment4http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment4Wed, 21 Jan 2009 21:33:48 GMTAs far as I know, when Unloading AppDomains and shutting down processes, all objects are finalized even when they are reachable. Isn't that consistent with the spec? http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment3http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment3Wed, 21 Jan 2009 21:03:17 GMTI won't presume to know more about this stuff than you, but I was wondering something. If a managed class -- say PersistentHashTable -- which implements IDisposable and contains no references to unmanaged objects and only references to managed objects that also implement IDisposable, then there is no need to implement a finalizer. However, if the object that it references -- a Microsoft.Isam.Esent.Interop.Instance -- holds onto an unmanaged resource but fails to properly implement a finalizer (in case Dispose() is not called), isn't that object ill-behaved? I wonder if implementing a finalizer on PersistentHashTable which calls Instance.Dispose() makes any sense? I would imagine you'd have to wrap that in a try/catch as finalizer ordering is not guaranteed. On a side note, does this have anything to due with the problems with Castle Windsor and object lifetime (issues that have apparently just recently been addressed in the trunk)? http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment2http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment2Wed, 21 Jan 2009 20:40:39 GMTThere's an old post by Chris Brumme that seems to confirm that this is expected behavior. [blogs.msdn.com/.../77460.aspx](http://blogs.msdn.com/cbrumme/archive/2004/02/20/77460.aspx) "Astute readers will have noticed that during process shutdown and AppDomain unloading we actually finalize objects in the RegisteredForFinalization queue. Such objects are still reachable and would not normally be subject to finalization." I assume this is because they don't want to risk leaving resources like database connections orphaned during process shutdown. http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment1http://ayende.com/3824/i-am-being-stalked-by-clr-bugs#comment1Wed, 21 Jan 2009 18:23:22 GMT