最近、製品の欠陥を修正しました。その症状は、ダングリングポインターへのアクセスによって引き起こされたアクセス違反でした。
良い習慣として、バグが再発しないことを確認するために単体テストを追加しました。単体テストを作成するときは、常に欠陥修正を取り消して、単体テストが失敗することを確認します。そうしないと、単体テストが適切に機能していないことがわかります。
欠陥修正を取り消した後、ユニットテストがまだ合格していることを発見しました（良くありません）。デバッガーを単体テストに接続して合格した理由を確認すると、テストが失敗し（つまり、例外がスローされ）、コールスタックが壊れて、修正した元の欠陥のスタックと一致することがわかりました。
Visual Studio 2005の[例外の中断]設定を変更しませんでした。これは実際に重大なWin32例外であり、テストハーネスが終了します（つまり、正常な例外ハンドラーがありません）。
例外のテキストは次のとおりです。
Unhandled exception at 0x0040fc59 in _testcase.exe: 0xC0000005:
Access violation reading location 0xcdcdcdcd.
注：場所は常にではありません0xcdcdcdcd（割り当てられていますが、書き込まれていないWin32ヒープメモリ）。ある場合もあれ0x00000000ば、別のアドレスである場合もあります。
これは、デバッガーを介して問題を観察すると問題が解消される、従来のHeisenbugの逆のように見えます。私の場合、デバッガーでそれを観察すると問題が発生します！
私の最初の考えは、これはデバッガーのタイミングの違いによって明らかになった競合状態であるということでした。ただし、コードにトレースを追加してデバッガーとは別に実行した場合、出力するデータは、デバッガーで実行する場合と同様の方法でアプリケーションを中止する必要があることを示しています。そうではありません！
これを引き起こしている可能性があるものについての提案はありますか？
更新： 私はこの問題の原因を絞り込んでいます。詳細については、この質問を参照してください。私がそれを見つけたら、答えでこの質問を更新します。