ANTS Memory Profiler Walkthrough - Part 2

Figure 11. The Instance Categorizer shows chains of instances sorted by their shortest path to GC Root.

We see that over 21MB of the String class are held in memory by the same shortest path back to GC Root, via our QueryForm and ConnectForm. We select Show the Instances on this Path to view a list of every instance in the previous category.

Figure 12. The instance list view shows us a set of strings which we recognize as coming from our SQL Database.

The Instance List is showing us data which QueryBee had retrieved from the SQL Database, but that data should have been destroyed when QueryForm was closed. We select one of the instances and click the icon to generate an Instance Retention Graph.

Figure 13. This instance retention graph.

Using the instance retention graph, we should be able to find out what is still referencing our String instances. Then, we'll be able to go back into our code to break the chain of references that is keeping them in memory.

We start at the bottom and work our way up the graph until we find a reference that needs to be broken. We'll just need to break the chain at one point to allow the garbage collector to clean up everything below that.

By navigating up, we can see the string is being held onto by QueryForm, even though that should have been released from memory. Looking a little further up, the graph is telling us that a System.EventHandler is referencing QueryForm and, if we step up one more level, it's telling us that the event handler is referenced by our ConnectForm instance – this is the form that asked us for the database connection details. In other words, the ConnectForm is holding onto the QueryForm via an Event Handler.

If we look at this node more closely, we see that it's actually being referenced by the ConnectForm's Foregrounded field. 

Let's find this Foregrounded event in our code. We right-click on the QueryBee.ConnectForm node and open the ConnectForm source code in Visual Studio^™.

Figure 14. Foregrounded event in the ConnectForm source code.

The profiler automatically jumps to the Foregrounded event. We check where it is being used by right-clicking on Find All References.

Figure 15. The Foregrounded event is used in three places.

We've got three usages and we find that the last usage is where QueryForm registers for the Foregrounded event, but it doesn't look like it unregisters. If we fix that, then the memory leak should go away.

Once we're done, we need to rebuild, but first we need to stop profiling QueryBee so that the executable isn't locked. We go back to Profiler and click on the Stop Profiling button.
Then, we rebuild.

Figure 16.  We rebuild our QueryBee application.

Back in the profiler, we start up a new profiling session. We want to find out whether the reference to the QueryForm has disappeared.Note that it remembered our settings from last time, so all we need to do is click Start Profiling.

Figure 17.  The settings dialog remembers settings from last time.

We take a first snapshot to use as a baseline.
We perform the same actions as last time: take a baseline snapshot while QueryBee is idle, then a snapshot once we’ve connected and run a query.
We'll also take an extra snapshot, because we want to be able to verify that the QueryForm has disappeared.

Finally, we close the query window with the results grid and we take a third snapshot.
We switch to a comparison between snapshots 1 and 3, using the snapshot selection field just under the timeline.

Figure 18.  Summary screen comparing snapshots 1 and 3.

We can see there is now only a small memory increase between the snapshots, which is promising. Let's see if there's a QueryForm still in the class list.
We switch to the class list view and search only for classes in the QueryBee namespace.

Figure 19.  Class list for the QueryBee namespace.

No, it's gone. We're no longer leaking the form.
As you saw, it was fairly easy to track down a form which was being leaked.