1

I'm new to WinDBG. I'm looking for the cause of a memory leak and I've got as far as my current knowledge can take me.

My MVVM App is leaking MyLovelyView objects.

In WinDBG I run !dumpheap -type MyLovelyView and get the following:

Address       MT     Size
05f2a978 0bc948d4       12     
05f39638 04d51114       36     
05f398d4 04d27734       96     
05f7db28 04d51114       36     
05f7dd70 04d27734       96     
05fc48f4 04d51114       36     
05fc4b3c 04d27734       96     
total 0 objects
Statistics:
      MT    Count    TotalSize Class Name
0bc948d4        1           12 MyNamespace.Unity.ProviderUnityExtension+FactoryStrategy+Provider`1[[IMyLovelyViewModel, MyNamespace]]
04d51114        3          108 MyNamespace.MyLovelyViewModel
04d27734        3          288 MyNamespace.MyLovelyView
Total 7 objects

I know that I shouldn't have any MyLovelyView objects in memory at the moment and I've forced the GC to run multiple times to ensure they're not just hanging around.

So I check for roots using the command !gcroot 05f7dd70, which results in the following:

Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 5 OSTHread 3428
Scan Thread 19 OSTHread 36a0
Scan Thread 20 OSTHread 1280
Scan Thread 23 OSTHread 2e90
Scan Thread 24 OSTHread 3738
Scan Thread 27 OSTHread 2398
DOMAIN(04936520):HANDLE(Pinned):44f12f8:Root:  066e4260(System.Object[])->
  056f946c(System.Collections.Generic.List`1[[System.Object, mscorlib]])->
  05ed1920(System.Object[])->
  05f8891c(ThirdParty.Control.DiagramPanel)->
  05f7e1e8(ThirdParty.Control.Diagram)->
  05f7f79c(System.Windows.DataContextChangedEventHandler)->
  05f7f748(System.Windows.Data.BindingExpression)->
  05f7db28(MyNamespace.MyLovelyViewModel)->
  05f7dd70(MyNamespace.MyLovelyView)

I've attempted to reproduce the leak using the third party controls is a simple dummy app and have, so far, been unsuccessful.

At this point, I'm stuck. Does anyone with more debugging experience have any idea what my next step should be?

For additional info, it might be helpful to see that the XAML in MyLovelyView looks something like this:

<Grid x:Name="LayoutRoot" Background="White">
    <Control:Diagram SomeProperty="{Binding SomeBoundProperty}" />
</Grid>

Thanks,

UPDATE: If I remove the binding from the XAML (above) the !gcroot output looks like this:

Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 5 OSTHread 36b4
Scan Thread 20 OSTHread 17c0
Scan Thread 21 OSTHread 3300
Scan Thread 22 OSTHread 3570
Scan Thread 23 OSTHread 2968
Scan Thread 26 OSTHread 2934
Scan Thread 27 OSTHread 34d8
DOMAIN(04DA8FE8):HANDLE(Pinned):37812f8:Root:  07324260(System.Object[])->
  0633946c(System.Collections.Generic.List`1[[System.Object, mscorlib]])->
  06a72860(System.Object[])->
  06b3823c(ThirdParty.Control.DiagramPanel)->
  06b2d8f8(ThirdParty.Control.Diagram)->
  06b2f568(System.Windows.Controls.Grid)->
  06b2d67c(MyNamespace.MyLovelyView)->
  06b2d7f0(System.Windows.DataContextChangedEventHandler)->
  06b2d79c(System.Windows.Data.BindingExpression)->
  06b2d434(MyNamespace.MyLovelyViewModel)

(All the memory addresses have changed because this is a rerun)

Montgomery 'monty' Jones
  • 1,061
  • 2
  • 14
  • 27
  • I see you are using Unity...Prism as well? Have you seen this, no idea if it is connected or not but thought I'd toss it out there...http://blogs.southworks.net/dschenkelman/2009/12/23/memory-leak-removing-view-with-child-regions-in-prism-v2/ – Aaron McIver Oct 21 '10 at 15:29
  • @Aaron Good idea, but I have no regions in the child view. Thanks for pointing that out though, I'll keep it in mind. – Montgomery 'monty' Jones Oct 21 '10 at 15:32
  • How are DiagramPanels referenced from your application? – Brian Rasmussen Oct 21 '10 at 17:17
  • @Brian If you want to template how the Diagram looks, you can use a DiagramPanel. In this example, however, I am not using templates so the instance of DiagramPanel that you see is entirely internal to the Diagram. – Montgomery 'monty' Jones Oct 22 '10 at 07:11
  • Incidentally, `06a72860(System.Object[])` in that last output contains all the leaked DiagramPanels. I'm not sure if that's relevant. – Montgomery 'monty' Jones Oct 22 '10 at 07:14
  • @elggarc: The reason I ask is because a pinned object[] root could indicate a static reference to your DiagramPanel. – Brian Rasmussen Oct 22 '10 at 07:41
  • @Brian: Absolutely, and that's largly where I got stuck. `06a72860(System.Object[])` is clearly the internal structure used by the generic List `0633946c(System.Collections.Generic.List` but I don't know how to trace it. – Montgomery 'monty' Jones Oct 22 '10 at 08:01
  • @elggarc: My point is that a pinned object[] by itself could be the internal structure used for static references. Are there any static `List` that could reference your DiagramPanels? I know very little about Silverlight, but I could imagine this to be some kind of cache. You could look at the contents of the generic list to give you more info. – Brian Rasmussen Oct 22 '10 at 08:06
  • @Brian: I don't know what's going on inside the Diagram class, so I can't be sure there aren't any static references in there, but I've be unable to reproduce the issue by creating my own simple program that uses the Diagram. There are no references, static or otherwise, to DiagramPanel in our app. The object[] contains the leaked DiagramPanel objects and then what appear to be random controls. – Montgomery 'monty' Jones Oct 22 '10 at 08:45
  • @elggarc: Hmm ... does dumping the handle's domain give you anything useful? – Brian Rasmussen Oct 22 '10 at 11:10
  • @Brian: Running a `!dumpdomain` command on `04DA8FE8` gives me a list of the loaded assemblies. How might that information help me? Or have I misunderstood you? – Montgomery 'monty' Jones Oct 22 '10 at 12:06
  • @elggarc: No that's correct. My idea was that perhaps there would be assemblies in the AppDomain that you didn't expect to find there. I guess that isn't the case. Perhaps you could set up an event for loading the assembly that contains DiagramPanels and then inspect the call stacks to see how the instance comes into play. – Brian Rasmussen Oct 22 '10 at 12:50
  • @elggrac Along with what Brian had mentioned about assembly loading you could also have a break-point on the objects constructor to check for call-stacks. – Naveen Oct 23 '10 at 23:52

0 Answers0