If you aren’t familiar with implementing the Dispose/Finalize pattern to clean up resources, stop and read this first. It is really important to get the implementation of the pattern right, or you’ll run into a performance problem at best, or risk leaking and running out of resources at worst.
Assuming that you’ve implemented the pattern correctly for your types, how do you guarantee that Dispose is called on all finalizable types in your application? Sure, you have finalizers, but depending on them for cleanup is bad because
1. There is a definite cost to finalization. An object for which a finalizer runs requires an extra garbage collection cycle to get GC’ed.
2. Your finalizers may not run at all. If your application chews up resources in a way that doesn’t trigger a garbage collection, you might run of resources and crash long before the GC (and the finalizer) decides to run.
Finding undisposed objects implementing finalizers becomes important then. Windbg with SOS has the !finalizequeue command that can show you objects that are ready for finalization. If you have only a few distinct types in that list that are created and used in very few places, !finalizequeue is all you need – just look for missing Dispose calls in those places, add them and you’re done.
Oftentimes it isn’t that simple though – a certain type could be used throughout your code base and hunting down missing Dispose calls on that type will quickly turn into an exercise in frustration. Wouldn’t it be great if a tool could show you the list of finalized objects, along with the something that tells you where they were created and used?
Undisposed (http://undisposed.codeplex.com/) does exactly that. It uses the CLR profiling API to watch for finalizations and object allocations, and matches them to show you constructor stack traces for finalized objects. All you have to do is launch your application from Undisposed and then run your application through a set of scenarios exercising various code paths. Once your application is closed, Undisposed’s Log Viewer (screenshot below) will open up, showing you the number of undisposed objects per type, with each type grouped by constructor stack trace.
If you do download the software, remember to register the Undisposed COM dll using
The software is still in Alpha, so please treat it like any pre-release software. Based on my very limited testing, it works reasonably well when you give it a limited set of types – otherwise, it tends to slow down the host application a little too much.
I’m looking for feedback and ideas, so feel free to comment.
PS : The inspiration for Undisposed came from this forum post on CodeProject – that’s when I realized I could automate the whole thing 🙂