0

We are streaming video from a ashx implementing IHttpAsyncHandler to our Silverlight client.

On the clientside the async handler is getting use in a implementation of MediaStreamSource.

It all runs fine in latest Firefox, chrome and also in Internet Explorer 8.

But in Internet Explorer 9 we see a memory leak. I have been using umdh to debug the memory and have found a callstack that used 127mb between to dumps of the memory. So i think i have narrowed it down to this callstack.

But now i don't know now to continue with my debugging. Here is the umdh info:

First the compare between first run and second

+ 117440512 ( 134217712 - 16777200)      1 allocs   BackTrace121282BC
+       0 (      1 -      1)    BackTrace121282BC   allocations

ntdll!RtlAllocateHeap+00000274
npctrl!???+00000000 : 56FE1A65
npctrl!DllCanUnloadNow+000157F0
npctrl!???+00000000 : 56FF477E
npctrl!???+00000000 : 56FF48D5
urlmon!CBSCHolder::OnDataAvailable+0000003A
urlmon!CBinding::CallOnDataAvailable+0000002B
urlmon!CBinding::OnDataNotification+000000D7
urlmon!CBinding::OnTransNotification+000001DB
urlmon!CBinding::ReportData+00000085
urlmon!COInetProt::ReportData+0000006E
mscorie!CorFltr::ReportData+0000002B
urlmon!CTransaction::DispatchReport+0000037A
urlmon!CTransaction::OnINetCallback+000000DB
urlmon!TransactionWndProc+00000028
USER32!InternalCallWinProc+00000023
USER32!UserCallWinProcCheckWow+00000109
USER32!DispatchMessageWorker+000003BC
USER32!DispatchMessageW+0000000F
IEFRAME!CTabWindow::_TabWindowThreadProc+00000722
IEFRAME!LCIETab_ThreadProc+00000317
iertutil!CIsoScope::RegisterThread+000000AB
IEFRAME!Detour_DefWindowProcA+0000006C
kernel32!BaseThreadInitThunk+0000000E
ntdll!__RtlUserThreadStart+00000070
ntdll!_RtlUserThreadStart+0000001B

The second run callstack

+ 7fffff0 ( 7fffff0 -     0)      1 allocs  BackTrace121282BC
+       1 (     1 -     0)  BackTrace121282BC   allocations

ntdll!RtlAllocateHeap+00000274
npctrl!???+00000000 : 56FE1A65
npctrl!DllCanUnloadNow+000157F0
npctrl!???+00000000 : 56FF477E
npctrl!???+00000000 : 56FF48D5
urlmon!CBSCHolder::OnDataAvailable+0000003A
urlmon!CBinding::CallOnDataAvailable+0000002B
urlmon!CBinding::OnDataNotification+000000D7
urlmon!CBinding::OnTransNotification+000001DB
urlmon!CBinding::ReportData+00000085
urlmon!COInetProt::ReportData+0000006E
mscorie!CorFltr::ReportData+0000002B
urlmon!CTransaction::DispatchReport+0000037A
urlmon!CTransaction::OnINetCallback+000000DB
urlmon!TransactionWndProc+00000028
USER32!InternalCallWinProc+00000023
USER32!UserCallWinProcCheckWow+00000109
USER32!DispatchMessageWorker+000003BC
USER32!DispatchMessageW+0000000F
IEFRAME!CTabWindow::_TabWindowThreadProc+00000722
IEFRAME!LCIETab_ThreadProc+00000317
iertutil!CIsoScope::RegisterThread+000000AB
IEFRAME!Detour_DefWindowProcA+0000006C
kernel32!BaseThreadInitThunk+0000000E
ntdll!__RtlUserThreadStart+00000070
ntdll!_RtlUserThreadStart+0000001B
mimo
  • 937
  • 12
  • 19
  • I doubt umdh is very useful for analyzing CLR memory leaks. Since .NET manages memory by itself, CLR won't allocate memory as little as necessary. Rather it will cut big peices of memory at once in order to optimize performance, fragmentation, etc. I'd start with .NET-specific tools, say ANTS Memory Profiler, to determine which memory leaks: managed or unmanaged. And you should remember to do a forced GC before taking snapshots, otherwise you might observe lots of ghost objects in the heap. – Pavel Gatilov Jan 30 '12 at 17:44