14

追跡するために、WPFアプリケーションで非常にトリッキーな欠陥が発生しています。エラーメッセージは次のとおりです。

レイアウト/レンダリングプロセス中にTimeManagerを繰り返し無効にした結果、無限ループが発生したようです。

スタックトレース（その価値について）は次のとおりです。

System.Windows.Media.MediaContext.RenderMessageHandlerCore（Object resizedCompositionTarget）at System.Windows.Media.MediaContext.RenderMessageHandler（Object resizedCompositionTarget）at System.Windows.Threading.ExceptionWrapper.InternalRealCall（Delegate callback、Object args、Int32 numArgs）at MS .Internal.Threading.ExceptionFilterHelper.TryCatchWhen（オブジェクトソース、デリゲートメソッド、オブジェクト引数、Int32 numArgs、デリゲートcatchHandler）

これは断続的な欠陥であり、私がこれを見つけることができる唯一の場所は、Application_DispatcherUnhandledExceptionメッセージをトラップしているアプリ構成ファイルです。私のアプリにあるものはすべてtrycatchブロックにラップされていますが、これは未処理の例外をキャッチする場所になります。

誰かがこれについて何か洞察を持っていますか？私はインターネットで何かを検索しましたが、何も見つかりませんでした。おそらく、ここの誰かがこれを追跡する方法についての洞察やアイデアを持っているのではないかと思いました。現在、私はこの例外を飲み込み、アプリに影響を与えていないように見えるため（クラッシュする以外）、アプリを実行し続けています。

4

3 に答える 3

4

コードで例外をキャッチできないことが予想されます。バグは、アプリケーションのXaml部分、おそらくアニメーションに起因します。

したがって、Xaml内でアニメーションを作成する場合でも、コードを使用する場合でも、たとえば、アニメーションBが停止するとアニメーションAが開始し、アニメーションAが開始するとアニメーションBが停止します。つまり、無限ループが発生します。A開始->B停止->A開始->B停止->..。

実際に可能な無限のループシナリオはたくさんあります。それらは、CurrentStateInvalidatedハンドラーまたはCompletedハンドラー、またはCurrentTimeInvalidatedによってトリガーされる可能性があり、他のタイプのトリガー（マウス、...）および/または前述の3つを使用するいくつかのシナリオを忘れる可能性があります。おそらく、コードが複雑すぎます。

このシナリオをテストするには、すべてのアニメーションを削除してください。

バグを再現する明確な方法を用意し、どのハンドラーがそのようなループに関与している可能性があるかを確認し、お互いを際限なく呼び出すようにしてください。

...ハンドラー内でカウンターを使用して、たとえば、指定された（多数の）呼び出しに到達したことをチェックボックスで警告することもできます。このチェックボックスは、ハンドラーの名前も示します。[OK]を数回クリックして、ループの「メンバー」を確認します。
リリースバージョンでも同様のコードを保持し、ログファイルを1回だけ書き込むことができます。その数に達すると、ハンドラーは常に何かを実行する前に戻ります。クラッシュよりはましだ。

...またはコードレビューだけで、考えられるループが表示される場合があります。

お役に立てれば。

編集：私のアドバイスを聞いてください：

A）すべてのアニメーションを削除し、アプリケーションをテストして、何が起こるかを確認します。B）バグが見当たらない場合：これが原因です。

C）次に、アニメーションで、最も「危険な」トリガーであるイベントトリガーを削除してみます。を使用してXAMLをコメントに入れることができるので、アニメーションの後にトリガーを超えてコピーするだけです。

D）もう一度テストします。バグが見つからない場合、これはイベントトリガーです。E）すべてのイベントトリガーを確認し、上記のようなループを監視します。

D）でまだバグが見られる場合は、C）で他のトリガー（プロパティトリガー/データトリガー）を使用して繰り返します

2番目ですが：それは、いくつかのデータが非常に頻繁に変更されるプロパティ/データトリガーである可能性があります...

たぶんxamlを投稿してください。

私は考えを持っていました：Application_DispatcherUnhandledExceptionにブレークポイントを設定してみてください。次に、MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhenに到達するまで、内部例外の内部例外の...を監視します。例外として、ソースを知ることができます。問題を引き起こしているのはインフラジスティックグリッドであることに驚かないでしょう。私はかつてTelerikの制御をテストし、いくつかのひどい問題と戦った後、自分でカスタマイズした古典的なグリッドに戻りました。お金と時間の両方が節約されました。私はこのグリッドをすばやく監視しました。これらは、コンバーターの問題や、このグリッドのカスタムスタイルのような問題のようなものです。->可能であれば、標準のDataGridを試してください。
->バグがない場合、根本的な原因があります。「裸の」インフラジスティックグリッドを試してから、テストしてから、スタイルを追加してから、テストしてください。コンバーターなしでテストできるかどうかはわかりません。それでも、ビューモデルに「変換された」プロパティを公開させることは常に可能です。

繰り返しますが、投稿で、いくつかのxamlを引用し、失敗事例を説明してください。

于 2013-02-12T11:56:10.810 に答える
-1

例外は非常に扱いにくい場合があります。提案の 1 つは、例外オブジェクトなしで catch ブロックを作成することです。したがって、次から catch ブロックを更新できます。

 catch(Exception ex)
{
..
}

に

    catch()
{
..
}

Peliの返信で述べたように、キャッチするのが難しい他の低レベルの例外があります

于 2013-02-13T10:38:44.990 に答える