views:

54

answers:

0

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)