12

VS2012を使用して、デバッグモードでアプリケーションを起動/デバッグすると、次のダイアログが表示されることがあります。

<blahblah.exe>がブレークポイントをトリガーしました。

他の情報は含まれていないので、何が起こっているのかを確認するために休憩を取ります。ああ、でも「wntdll.pdbがロードされていません」というメッセージが表示され、問題に関する他の情報はありません。呼び出しスタックはntdll.dllを指しており、この時点ではまだアプリケーションの実行が開始されていないようです。

この時点で続行を選択すると、アプリケーション/デバッガーは通常どおり続行できます。

これは非常に頻繁に発生します（10回のうち約7回の起動）。Windows 8（64ビット）と、更新プログラム1のVisualStudio2012を実行しています。

以前はWindows7（64ビット）とVS2010を使用していましたが、この問題が発生することはありませんでした。この特定のプロジェクトは、（2010）で作成されたバージョンからアップグレードされているため、おそらくそれが問題の一部です。

誰かが以前にこの問題に遭遇しましたか？どこから原因を探し始めるのかわかりません。私は64ビットWindowsを実行していますが、32ビットアプリケーションを構築していることに言及する必要があります。

更新： Microsoft Symbol Serverを有効にすると、呼び出しスタックは次のようになります。

>   ntdll.dll!_LdrpDoDebuggerBreak@0()  Unknown
    ntdll.dll!_LdrpInitializeProcess@8()    Unknown
    ntdll.dll!__LdrpInitialize@8()  Unknown
    ntdll.dll!_LdrpInitialize@8()   Unknown
    ntdll.dll!_LdrInitializeThunk@8()   Unknown

また、念のため、コードのどこにもブレークポイントを手動で設定していないことを追加する必要があります。

4

4 に答える 4

5

この厄介な問題は、VisualStudio内のバグに起因します。

何が起こっているのかというと、異なるプロセスからの複数のローダーブレークポイントイベントを同時に正しく処理していないということです。OSは、プロセスが起動して実行されるとローダーブレークポイントをトリガーしますが、デバッガーがブレークポイントをインスタンス化して他のアクションを実行するために実行が行われる前にトリガーします。通常、これらは正常に無視されます（少なくとも単一の起動の場合）。これを回避するには、ツール->オプション->デバッガーの[1つのプロセスが中断したときにすべてのプロセスを中断する]チェックボックスを無効にします。また、これは致命的なエラーではないことに注意してください。内部のブレークピオントで停止しているところです。もう一度F5キーを押すだけで続行できます。

これは競合状態であるため、追跡するのはそれほど簡単ではなく、VSでの複数の起動の使用量はかなり少ないので、上記の回避策がブロックを解除するのに十分であると仮定して、これを修正しません。追加の顧客からのレポートがさらに表示された場合は、これを再検討します。それはあなたにとって合理的に聞こえますか？

フィードバックをありがとうございます。

Marc PaineVisualStudioデバッガーエンジニアリングマネージャー

出典：Microsoft Connect

Visual Studioデバッガー設定の[1つのプロセスが中断したときにすべてのプロセスを中断する]チェックボックスを無効にするためのアドバイスに従いました。これにより、今のところ問題が「削除」されました。

おそらく、このバグの同じ問題/不快感を報告する人をさらに数人増やすことができれば、Microsoftは最終的に彼らが提案するようにそれを修正するでしょう。

于 2017-05-30T07:42:08.647 に答える
3

デバッガーでアプリケーションを実行する場合、プロセスが開始されるとすぐに自動ブレークポイントがあります。このブレークポイントは、プロセスの実行を開始する前に、さらにブレークポイントを設定する機会を提供します。気に入らない場合は、通常、デバッガーに最初のデフォルトのブレークポイントを無視するオプションがあります。たとえばcdb 、オプションには-g。があります。

于 2014-10-06T13:46:31.130 に答える
0

同様の問題が発生していることに気づきましたが、これは私のコールスタックでした。

ntdll.dll!LdrpDoDebuggerBreak()
ntdll.dll!LdrpInitializeProcess()
ntdll.dll!_LdrpInitialize() 
ntdll.dll!LdrInitializeThunk()

私の場合、Visual Studioソリューションにはいくつかのプロジェクトがあり、そのうちの3つのプロジェクトは、ソリューションの「複数のスタートアッププロジェクト」設定によって開始（およびデバッグ）に設定されています。

スタートアッププロジェクトの2つは（管理されていない）C ++であり、そのうちの1つはC＃です。C＃プロジェクトのプロジェクトプロパティを開き、「ネイティブコードのデバッグ」を有効にすることで、この起動ブレークポイントを取り除くことができました。

編集：どうやらこれは私の問題を完全には解決しませんでした、それはそれが起こる頻度を大幅に減らしただけです。しかし、私は同じ一般的な解決策がまだそれを修正するかもしれないと思います。

このソリューションの他のプロジェクトの1つは、プロジェクトのとしてバイナリを手動で指定することによって起動される、ビルド済みのバイナリですTargetPath。

プロジェクトのプロパティページでにDebugger Typeを変更することも役立ったようです。Native OnlyDebugging

したがって、これらの両方を変更することで、実際に問題が解決したように見えます。

于 2017-01-13T16:57:36.947 に答える
-1

ファーストチャンス例外でデバッガーへの侵入をオンにしたかどうかを確認します。

これは「デバッグ/例外...」で確認できます。いずれかのボックスがチェックされているかどうかを確認します。（少なくとも、これは古いVSバリアントのメニューの場所でした-現在VS 2012はありません）有効にすると、アプリケーションによって正しく処理されたとしても、例外がスローされたときにデバッガーが中断します。無効にすると、デバッガーは例外が処理されない場合にのみ中断します。例外がチェックされている場合は、チェックを外して、これが続くかどうかを確認してください。

于 2014-10-06T13:32:27.233 に答える