I have a Silverlight 3 application which seems to be leaking DispatcherTimer objects. At least, over time when the application runs I find more of them on the heap:
!dumpheap -type DispatcherTimer
returns an increating number of them.
I’d like to find the Tick event handler method for these so I can identify where they’re created in my code.
When I try dumping one of these in windbg, I get something like:
!do 098b9980
Name: System.Windows.Threading.DispatcherTimer
MethodTable: 0bfd4ba0
EEClass: 0bc98d18
Size: 20(0x14) bytes
File: C:\Program Files (x86)\Microsoft Silverlight\4.0.50524.0\System.Windows.dll
Fields:
MT Field Offset Type VT Attr Value Name
0bfd1538 40008be 4 ...eObjectSafeHandle 0 instance 098b9994 m_nativePtr
0bfd3d0c 40008bf 8 ...reTypeEventHelper 0 instance 098b99ac _coreTypeEventHelper
506a07e4 40008c0 c System.Boolean 1 instance 1 _isEnabled
0bfd3c68 40008c1 cec ...ependencyProperty 0 shared static IntervalProperty
>> Domain:Value 086d3f38:NotInit 086daeb8:098b99b8 <<
But from here, I don’t know how to find the method handling the Tick event. I suspect it’s something to do with _coreTypeEventHelper, but when I dump that, I get:
!do 098b99ac
Name: MS.Internal.CoreTypeEventHelper
MethodTable: 0bfd3d0c
EEClass: 0bc98420
Size: 12(0xc) bytes
File: C:\Program Files (x86)\Microsoft Silverlight\4.0.50524.0\System.Windows.dll
Fields:
MT Field Offset Type VT Attr Value Name
00000000 40009f5 4 0 instance 098b9ae4 _eventAndDelegateTable
506a0e94 40009f4 514 System.Int32 1 shared static _nextAvailableTableIndex
>> Domain:Value 086d3f38:NotInit 086daeb8:669 <<
then I dump the _eventAndDelegateTable:
Name: System.Collections.Generic.Dictionary`2[[System.Int32, mscorlib],[MS.Internal.CoreTypeEventHelper+EventAndDelegate, System.Windows]]
MethodTable: 0bfcc0a0
EEClass: 5026c744
Size: 52(0x34) bytes
File: C:\Program Files (x86)\Microsoft Silverlight\4.0.50524.0\mscorlib.dll
Fields:
MT Field Offset Type VT Attr Value Name
5068f2d0 4000648 4 System.Int32[] 0 instance 098b9b18 buckets
50691060 4000649 8 ...non, mscorlib]][] 0 instance 098b9b30 entries
506a0e94 400064a 20 System.Int32 1 instance 1 count
506a0e94 400064b 24 System.Int32 1 instance 1 version
506a0e94 400064c 28 System.Int32 1 instance -1 freeList
506a0e94 400064d 2c System.Int32 1 instance 0 freeCount
50697f08 400064e c ...Int32, mscorlib]] 0 instance 098b9650 comparer
506ccfb0 400064f 10 ...Canon, mscorlib]] 0 instance 00000000 keys
506ceaac 4000650 14 ...Canon, mscorlib]] 0 instance 00000000 values
506a02e4 4000651 18 System.Object 0 instance 00000000 _syncRoot
506895d8 4000652 1c ...SerializationInfo 0 instance 00000000 m_siInfo
And then I’m kind of lost!
Before attempting to find the relevant event handler, you could also search for the source of the leak by investigating why the
DispatcherTimerinstances doesn’t get released.After you have the output of the
!dumpheap -type DispatcherTimer, execute the!gcrootcommand on a couple of instances ofDispatcherTimer. You should be able to see which object holds a reference to the timer.Also, you could place appropriate breakpoints (using
!bpmd), in order to obtain helpful stacktraces.