0

現在、.NET WinForms アプリケーションで発生しているメモリの問題のトラブルシューティングを行っています。SciTech の .NET Memory ProfilerとdotTraceを使用していますが、それらはすべて、.NET Framework コントロールの静的イベント ハンドラーによるルート割り当てを示しているようです。google'ing から、これに関するレポートがこことここに見つかりましたが、これは .NET Framework の v1.1 で報告されているようで、修正は 2.0 で約束されています。2.0 で実行していますが、まだこれらの問題が発生しています。私が見つけた上位 25 のメモリ違反者はすべて、これらの静的イベント ハンドラー、特に SystemEvents.UserPreferenceChanged を指しています。 この男これらのハンドラーを巻き戻す方法を見つけるために多大な努力をしました。これはまだ試していませんが、マイクロソフトのサポート チケットに記載されている回避策を試しましたが、どれもうまくいきませんでした。

イベント ハンドラー (特に長寿命の静的ハンドラー) のリークの可能性についてはよく認識していますが、これはほとんど制御できません。誰でもこれを経験したことがありますか？

4

2 に答える 2

1

For really deep memory leak problems in the CLR, I find the best tool is windbg. If you can get past the cryptic syntax it's an amazingly effective debugger and leak tracker. The downside is it's not very intuitive to use and there is a very steep learning curve.

The best way to learn windbg though is by doing. Here are a couple of articles that talk about using windbg to track down a leak.

于 2008-11-13T18:24:40.280 に答える
0

WinDBGがここで役立つかどうかはわかりません。これは本当にフレームワークのバグのようです。簡単な再現を投稿する方法はありますか？もしそうなら、私は一体何が起こっているのかを掘り下げて、回避策があるかどうかを確認することができます。それ以外の場合は、 Connectでチケットを開くことをお勧めします。彼らは人々に戻ることについてかなり良いです。

WinDBGで調べたい場合は、ヒープで何が起こっているかを調べて、何が起こっているかを確認できます。ぶらぶらしているオブジェクトが何に根ざしているのかを調べ始めます。私の推測では、上記のプロファイラーに表示されるものとほぼ同じように表示されます。WinDBGのトリッキーな点は、必要なことをすべて教えてくれることです。つまり、WinDBGに入力する質問に答える必要があるかどうかを知る必要があります。

于 2008-11-13T18:49:08.580 に答える