2011-11-11 10 views
2

私はVS2010でC++ Win32プログラムをデバッグしていますが、「Windowsはprogram.exeにブレークポイントをトリガしました」というメッセージが表示されます。Windowsがブレークポイントを生成しました

コードを二重チェック、三重チェック、四回チェックしました。私は何か起こっている必要があります見つけることができません。しかし、毎回同じ場所で起こるので、何かがあるはずです。

コンストラクタ、デストラクタ、ウィンドウメッセージ、メモリ割り当てと割り当て解除などかなりのコードが含まれていますので、具体的な記述は非常に難しいですが、あなたは説明をするために本当に多くのことをすることはできません。

基本的にボタンをクリックすると、画像を示すウィンドウが表示されます。特定の条件が満たされた場合、私はそのウィンドウにWM_DESTROYを送り、Release()を私のLPPICTUREに呼び出すデストラクタをトリガする変数を削除し、解放された変数はNULLに設定されます。

次に、ユーザーがボタンを再度クリックすると、以前に行ったのと全く同じ方法で新しいインスタンスを動的に割り当てようとするため、ブレークポイントが生成されます。 AFAIK(と私は1時間以上これをデバッグしようとしてきました)、コンストラクタは起動しません。これは、動的メモリ割り当てのためのnew()関数の中で壊れているようです。

は、私の知る限り、それは私がVS2010の外でexeファイルを実行すると、すべてが正常続けていることは何奇妙なライン54または

malloc.cあるreturn HeapAlloc(_crtheap, 0, size ? size : 1);に壊れます。プログラムはクラッシュしませんし、期待どおりに動作し続けます!

答えて

6

コードを確認せずに診断するのは難しいですが、説明に基づいて、ヒープの破損のように思えます。私の推測では、HeapAllocの破損が検出され、int 3が生成され、基本的にデバッガでブレークポイントがトリガされます。私のアドバイスは、あなたのオブジェクトの割り当て/割り当て解除のすべてを見直し、割り当てられていない(またはすでに解放されている)メモリを踏んでいないことを確認することです。

また、WM_DESTROYメッセージを明示的に送信していると述べました。通常、WindowsにDestroyWindowを呼び出すか、WM_CLOSEを送信してDefWindowProcDestroyWindowを呼び出して、WindowsにWM_DESTROYメッセージを生成させます。これはあなたの問題とは関係ないかもしれませんが、ちょうどFYIです。

+1

+1これは非常にうまくいく可能性があります。ウィンドウが偽の 'WM_DESTROY'を処理した後、ウィンドウが本当に適切に破壊されたときに別のウィンドウを取得する可能性があります。 @Ozzah 'WM_DESTROY'を生成しないでください。システムがそれを生成し、それを処理します。 –

+1

関連リンク:http://blogs.msdn.com/b/oldnewthing/archive/2011/09/26/10216420.aspx –

+0

コードをチェックして、私は 'WM_DESTROY'を送信していません。私は' DestroyWindow (HWND) 'と呼ばれます。私はそれが難しいことを認識していますが、おそらく関連性の高いコードがたくさんあります。私はそれをもう一度長く見直して、私がそれを突き止めることができるかどうかを見ます。 – Ozzah

-1

私は問題は、Visual Studio内のデバッグでは、デバッグフォルダの特定のディレクトリにある必要なファイル(ここではあなたが話しているイメージ)を配置しなければならないと思います。 VS2010の外でEXEを実行するとファイルが見つからないため、クラッシュしません。

+0

"lol"以外は何を言うべきか分かりません – Ozzah

+0

なぜビジュアルスタジオの外で完璧に動作するのですか?画像をロードすると本当に大変ですが、VSの外では完全に動作しますが、デバッグ中にクラッシュし、デバッグディレクトリは問題を解決します(2つのデバッグフォルダがあります) – andrewmag

+0

まず、OPENFILENAMEを使って任意のパスからイメージをロードしていますので、パスは完全に無関係です。同じ作業ディレクトリに画像を読み込むだけでは便利ではありません。第二に、元の質問では、ヒープ上に割り振るときにブレークポイントがトリガーされると言いました。これは、デバッガでプログラムが動作していないときにユーザには完全に見えないはずの 'INT 3'割り込みだと確信しています。 (確認?)後のクラッシュのような副作用だけが見えます。 – Ozzah

2

私の経験では、ヒープ訂正/無効なポインタの使用が発生しました。ブレークポイントは、障害が検出された時点で発生します。これはほとんど決して実際の失敗ではありません。問題は以前に発生しました。これらのタイプのブレークポイントは、デバッガが存在する場合にのみ発生します。多くの場合、腐敗は致命的ではなく、他の何らかの行動によっても是正されています。

いずれにしても、問題が見つかるかどうかはappverifierとする必要があります。ヒープチェックオプションを必ず使用してください。

+0

ありがとう、ありがとう。問題を絞り込もうとすると、多くの助けになります:) – Ozzah

関連する問題