3

長いデバッグ作業の後、アプリケーションがアドレス 0x5b81730 に間違った値を書き込んでいる可能性があることがわかりました。コードのどの部分がこれを行っているかを知りたいです。

以前、Windows XP を使用していたときは、これは非常に簡単でした。デバッガー (MS Visual Studio 2005) でアプリケーションを再起動し、そのアドレスにデータ ブレークポイントを設定すると、デバッガーは問題のあるコードを指摘します。

今、Windows 7 に切り替えた後、これは不可能に思えます (少なくとも非常に困難です)。アプリケーションを実行すると、ヒープ内の同じオブジェクトのアドレスが毎回わずかに異なることがわかります (たとえば、ある実行では 0x53b71b4 ですが、別の実行では 0x55471b4 になります)。

Windows 7 にはASLRがあると聞いたことがあります。これが、アドレスにこれらの変更が見られる理由かもしれません。

では、デバッグ手法を引き続き使用するにはどうすればよいでしょうか?

ASLR をオフにする必要がありますか? (可能だと思いますが、方法がわかりませんでした)

それとも、私の問題は ASLR ではなく、別の何かによって引き起こされているのでしょうか?

それとも、データ ブレークポイントを使用する便利さを忘れて、他の手法を使用する必要がありますか?

4

2 に答える 2

3

UB のようなものを使用している場合、アドレスがどうなるかはまったく保証されません。毎回同じであることに依存することはできません。

ただし、Linker 設定で ASLR を無効にすることもできます。そこにある属性の 1 つは「Randomized Base Address」です。

コマンドライン構文は/DYNAMICBASE:NO. Visual Studio 2005 には存在しませんが、VS 2012 以降には存在します。

于 2013-02-28T14:01:45.380 に答える
1

Application Verifierを使用してみます。これは、メモリ リークの問題をデバッグする優れた方法です。メモリ破損の問題がある場合、コードの実行が中断されます。

于 2013-02-28T14:05:56.257 に答える