13

編集: この同じ問題が発生している場合 (VS2010 でこれが表示されないことに慣れている場合) は、以下にコメントしてください。 ..

VS2012 RTM で .NET 4.5 で実行するようにアプリを更新していて、よくわからないことに気付きました。これは、(黄色ではなく) 予期せず緑色に強調表示されたステートメントです。

ここに画像の説明を入力

これで、これが何を意味するのかがよくわかりました。IDE には、簡単な説明のツールチップも表示されます。

これは、このスレッドが現在の関数から戻ったときに実行する次のステートメントです

ただし、このコードには非同期またはスレッド ベースのものはまったくありません。string.ToUpper()この単純な例では、別のスレッドでオフにならないことに同意していただけると確信しています。問題なくコードをステップ実行できます。

他に何も起こっていません。私はここにあるようにメイン スレッドにいます。

s

andと(上記のメソッドは RelayCommand の結果です) を使用していますが、 コードパスが.asyncawaitMVVM-LightPreviewKeyDown

ここに画像の説明を入力

新しいアプリを作成すると、これを複製できませんawait。.

誰かが何か考えましたか？それは私を夢中にさせ始めています!!

4

3 に答える 3

5

現在の命令ポインターがステートメントの先頭に正確にない場合、緑色になります。いくつかの一般的な原因:

  • スレッド化されたコードで一般的で、あるスレッドにブレークポイントを設定し、コンテキストを別のスレッドに切り替えます。もう一方のスレッドは、完全にランダムな場所でデバッガーによって中断されます。多くの場合、String.ToUpper() のように、ソース コードやデバッグ情報がないコードでは、デバッガーは「最も近い」ソース コードしか表示できません。
  • Debugger + Break All を使用して、デバッガーに侵入します。上記と同じ考え方で、命令ポインターはランダムなアドレスになります
  • デバッグ情報がないコードで例外を取得します。エディタには、ソース コードがあるコール スタックの最後のエントリが表示されます。実際の例外が発生した場所を確認するには、コール スタック ウィンドウが必要です。または例外アシスタント、その理由
  • 最適化されたコードのデバッグ。ジッター オプティマイザーはコードをかなり激しくスクランブルするため、デバッガーが現在の位置を正確に表示できない可能性があります。
  • デバッグ情報が古いか、デバッグ中にコードを編集する
  • x64 ジッターによって生成されたコードのデバッグは、プロジェクトのターゲット プラットフォーム設定が AnyCPU の場合に発生します。x64 ジッタには、修正されていない多くの慢性的なバグがあり、誤ったデバッグ情報を生成することはその 1 つです。RyuJIT プロジェクトによって完全に書き直され、.NET バージョン 4.6 で最初に利用可能になるまで対処されなかった問題。EXE プロジェクトで x86 をターゲットにすることが回避策です。
于 2012-09-14T13:09:01.867 に答える