長い間私を悩ませてきた何かが、最終的にスタックオーバーフローでここに尋ねることにしました:
Windows フォーム プロジェクトを DEBUG モードで実行しているときに一時停止ボタンをクリックすると、常にApplication.Runで停止するのはなぜですか?
Application.Run(new FormGuiV2()); // pressing pause stops here
これは私には欠陥のようです。実行中の実際のコード行で一時停止しないのはなぜですか? スタックの一番上で停止することは、デバッグ時には役に立ちません。デバッガを間違って使用しているに違いないと思いますか?
これを回避するには、実行中のコード行を認識してデバッグ ポイントを配置する必要があります。これはエラーが発生しやすく、デバッグ ポイントを配置する場所を追跡するのに時間がかかる場合があります。
一時停止ボタンをクリックして、実行中のコード行で実際に停止させる適切な方法を知りたいです。
ありがとう
そうではなく、Debug + Break コマンドを実行したときにアクティブだったコードで停止します。これは、デバッガーの呼び出し履歴ウィンドウで確認できます。ただし、独自の実行中のコードを中断する可能性は非常に低く、プログラムは 99% の時間を Windows が何か興味深いことが起こったことを知らせるのを待っています。通常、コール スタックは次のようになります。
[Managed to Native Transition]
System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(System.IntPtr dwComponentID, int reason, int pvLoopData) + 0x444 bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason, System.Windows.Forms.ApplicationContext context) + 0x155 bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) + 0x4a bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.Run(System.Windows.Forms.Form mainForm) + 0x31 bytes
> WindowsFormsApplication1.exe!WindowsFormsApplication1.Program.Main() Line 16 + 0x1d bytes C#
[Native to Managed Transition]
[Managed to Native Transition]
mscorlib.dll!System.AppDomain.ExecuteAssembly(string assemblyFile, System.Security.Policy.Evidence assemblySecurity, string[] args) + 0x6b bytes
Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() + 0x27 bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x6f bytes
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0xa7 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x16 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x41 bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 bytes
[Native to Managed Transition]
FPushMessageLoop() メソッドがスタック トレースの最上位にあることに注意してください。これは、Windows 通知を受け取る Windows GUI アプリの有名なメッセージ ループです。アンマネージ デバッグも有効にすると、さらに表示されるようになります。コアの GetMessage() winapi 関数は、メッセージ ループの重要な部分です。
>スタック トレースのマーカーに注意してください。それがあなたが話しているコード行です。これが表示される理由は、その上のコードが .NET フレームワークの一部であるためです。また、参照ソースをインストールしていない場合、そのソース コードはありません。
そのため、デバッガーはスタックをたどり、表示する関連ソース コードを探します。そして必然的に、Program.cs 内の Main() メソッドである Application.Run() 呼び出しに行き着きます。
GUI アプリで便利なブレークを取得するには、ブレークポイントを設定する必要があります。
これは、実行されている実際のコード行である可能性が高いです。
実際には、メソッド内Application.Runのコードが実行されていますが、そのコードは .NET Framework ライブラリの一部であり、.NET ソースのステップ実行が有効になっていません。そうした場合、WinForms ライブラリ コードの迷路のどこかに足を踏み入れることになり、おそらくあまり役に立たないでしょう。
この謎の背後にある秘密は、Windows アプリケーションがユーザー入力やその他のイベントに基づいてオペレーティング システムからのメッセージを待機しているループ内でほとんどの時間を費やしていることです。これをメッセージ ループと呼びます。.NET Framework (およびその他のフレームワーク) は、これらのメッセージを内部で処理し、重要なものを別の方法 (イベントの発生など) で公開して、これらをすべて抽象化します。しかし、それはまだ舞台裏で進行中です。
「一時停止」ボタンをランダムに押して、ユーザーコードのどこかを壊すには、ちょうどいいタイミングにする必要があります。ほとんどの場合、実行を中断するとき、コードは「アイドル」ポイントにあり、ユーザー入力またはその他のアクションを待機しています。したがって、ブレークポイントは通常、より適切で管理しやすいアプローチです。
アプリケーションを起動したメイン スレッドは になりますApplication.Run。それ以外の場合、アプリケーションは終了します。Application.Runは、予想される位置にある UI スレッドと、場合によっては他のスレッドをスピンアップします。
アプリケーションのメイン スレッドは、デバッガーが常にジャンプする場所です。そうしないとプロセスが閉じてしまうため、これは常にそこにある必要がある 1 つのスレッドです。
[Debug] -> [Windows] -> [Threads] ウィンドウを開くと、他のスレッドに切り替えることができます。そのうちの 1 つが、おそらく予想される場所で実際に一時停止されていることがわかります。