11

私は時々奇妙な問題を示し、UI でハングしているように見える WPF アプリケーションに取り組んでいます。一貫性がなく、別のページで発生しますが、大きな問題になるほど頻繁に発生します。以下で説明するように、これは真のハングではありません。

私が最初に考えたのは、一部のボタンのアニメーションはほとんどのページで使用されているため問題であるということでしたが、それらを削除した後もハングは発生しますが、頻度は少し下がったようです。ハングが発生したときにデバッガーに侵入しようとしました。ただし、表示するコードはありません。私のコードは実行されていません。「ハング」が完了していないことにも気付きました。引き続き機能するフォームをドラッグできるコードがあります (境界線やタイトルはありません)。また、クリックすると機能する、勝った閉じるボタンもあります。ボタンをクリックすると、コードが実行されると実際に機能するように見えますが、UI が更新されて新しいページが表示されることはありません。

この奇妙な問題を追跡するためのアドバイス、ツール、またはテクニックを探しています。

編集: もう一度起こったので、今回はデバッガーに侵入しようとしたときに「逆アセンブリを表示する」ことを選択しました。MS.Win32.UnsafeNativeMethods.GetMessageW に移動します。スタック トレースは次のとおりです。

[Managed to Native Transition]

WindowsBase.dll!MS.Win32.UnsafeNativeMethods.GetMessageW(ref System.Windows.Interop.MSG msg, System.Runtime.InteropServices.HandleRef hWnd, int uMsgFilterMin, int uMsgFilterMax) + 0x15 バイト
WindowsBase.dll!System.Windows.Threading. Dispatcher.GetMessage(ref System.Windows.Interop.MSG msg, System.IntPtr hwnd, int minMessage, int maxMessage) + 0x48 バイト WindowsBase.dll!System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame フレーム= {System.Windows.Threading.DispatcherFrame}) + 0x8b バイト WindowsBase.dll!System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame フレーム) + 0x49 バイト
WindowsBase.dll!System.Windows.Threading. Dispatcher.Run() + 0x4c バイト
PresentationFramework.dll!System.Windows.Application.RunDispatcher (オブジェクトは無視) + 0x1e バイト
PresentationFramework.dll!System.Windows.Application.RunInternal(System.Windows.Window ウィンドウ) + 0x6f バイト PresentationFramework.dll!System.Windows.Application. Run(System.Windows.Window ウィンドウ) + 0x26 バイト PresentationFramework.dll!System.Windows.Application.Run() + 0x19 バイト WinterGreen.exe!WinterGreen.App.Main() + 0x5e バイト C# [Managed Transition にネイティブ]
[管理からネイティブへの移行]
mscorlib.dll!System.AppDomain.nExecuteAssembly(System.Reflection.Assembly アセンブリ、string[] args) + 0x19 バイト mscorlib.dll!System.Runtime.Hosting.ManifestRunner.Run(bool checkAptModel) + 0x6e バイト mscorlib.dll!System .Runtime.Hosting.ManifestRunner.ExecuteAsAssembly() + 0x84 バイト mscorlib.dll!System.Runtime.Hosting.ApplicationActivator.CreateInstance(System.ActivationContext activationContext, string[] activationCustomData) + 0x65 バイト mscorlib.dll!System.Runtime.Hosting. ApplicationActivator.CreateInstance(System.ActivationContext アクティベーションコンテキスト) + 0xa バイト mscorlib.dll!System.Activator.CreateInstance(System.ActivationContext アクティベーションコンテキスト) + 0x3e バイト
Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone() + 0x23 バイト
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(オブジェクトの状態) + 0x66 バイト
mscorlib.dll!System.Threading. ExecutionContext.Run(System.Threading.ExecutionContext executionContext、System.Threading.ContextCallback コールバック、オブジェクト状態) + 0x6f バイト
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 バイト

4

5 に答える 5

6

ウィンドウのボーダーレス動作を削除してみて、それが役立つかどうかを確認してください。また、BeginInvoke() または Invoke() を長時間実行している操作はありますか?

もう 1 つ注目すべき点: コードに割り込むときは、メイン スレッド以外のスレッドを調べてみてください。そのうちの 1 つが UI スレッドをブロックしている可能性があります。

于 2008-09-19T18:21:30.417 に答える
6

パフォーマンスの問題により、WPF アプリがハングしている可能性があります。Perforatorを使用して、ソフトウェア レンダリングされた部分があるかどうか、またはアプリがビデオ RAM を使いすぎていないかどうかを確認してください。

于 2008-09-19T18:26:48.127 に答える
4

Bob King の提案に従って、ボーダーレス動作を削除しました。今日まで、それは問題を取り除いたようです。

問題は、なぜ、どのように問題を解決できるのかということです。角を丸くしたり、一部透明部分を設けたりとフチのないデザインとなっております。

于 2008-09-22T17:12:31.260 に答える
4

優れたツールの 1 つがSnoopです。特定の時間にビジュアル ツリーに表示される WPF オブジェクトを確認するには、非常に便利です。それがどれだけ役立つかはわかりませんが、UI スレッドがやらなければならない多くの余計なことで、UI スレッドを妨害している可能性があります。スヌープは、画面に何が表示されているかを追跡して、何を探すべきかを知るのに役立つ場合があります.

于 2008-09-19T18:21:39.777 に答える
1

フラー、... 問題はボーダーレス ウィンドウに関連していないようです (少なくとも私の場合)。

trueに設定すると、パフォーマンスが大幅に低下AllowsTransparencyします。全体がUIスレッドをハングさせる可能性があるほどのヒットのようです。非常に奇妙な振る舞い。このチケットに関連している可能性があります

于 2009-12-15T15:41:06.693 に答える