0
IHttpAsyncHandlerを実装しているashxからSilverlightクライアントにビデオをストリーミングしています。Internet Explorer 9 Silverlight 4メモリリーク
クライアント側では、非同期ハンドラがMediaStreamSourceの実装で使用されています。
これは、すべての最新のFirefox、ChromeともInternet Explorerの8
で正常に動作しかし、Internet Explorer 9の中で、私たちは、メモリリークを参照してください。メモリをデバッグするためにumdhを使用していて、メモリのダンプに127mbを使用するコールスタックが見つかりました。だから、私はこのコールスタックに絞ったと思う。
しかし、私は今、私のデバッグを続行することを知らない。ここでUMDH情報れる：
まず最初に実行し、二
+ 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
間セカンドランのコールスタックを比較
+ 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
私はUMDHは、CLRのメモリリークを分析するのに非常に有用である疑い：
は、次のようなSLメモリのデバッグのヒントを確認しました。 .NETはメモリを単独で管理するため、CLRは必要なだけメモリを割り当てません。むしろパフォーマンス、フラグメンテーションなどを最適化するために一度に大量のメモリを減らすことになります。ANTSメモリプロファイラという.NET固有のツールから、管理対象または非管理対象のメモリリークを判断します。また、スナップショットを作成する前に強制GCを行うことを忘れないようにしてください。さもなければ、ヒープ内のゴーストオブジェクトをたくさん観察するかもしれません。 –