3

After a long debugging effort, I found out that my application probably writes a wrong value to address 0x5b81730. I would like to find out which part of my code does this.

Some time ago, when I used Windows XP, this would be very easy. I would restart my application in a debugger (MS Visual Studio 2005), set a data breakpoint at that address, and the debugger would point my the offending code.

Now, after I switched to Windows 7, this seems impossible (or at least very hard). When I run my application, I see that each time the addresses of the same object in the heap are slightly different (e.g. 0x53b71b4 in one run but 0x55471b4 in another).

I have heard that Windows 7 has ASLR, which might be the reason I see these changes in addresses.

So what can I do to continue using my debugging technique?

Should I turn off ASLR? (I believe it's possible but couldn't find out how to do it)

Or is my problem caused by something else and not ASLR?

Or should I forget the convenience of using data breakpoints, and use some other techniques?

anatolyg
  • 26,506
  • 9
  • 60
  • 134
  • did you try this http://msdn.microsoft.com/en-us/library/f7f5138s(v=vs.80).aspx ? –  Feb 28 '13 at 14:02
  • This seems to be caused by ASLR (is this the correct abbreviation?). And you shouldn't turn it of, than rather live with it. In the end, it might scramble things up, if you don't use it. – bash.d Feb 28 '13 at 14:03
  • @bash.d [citation needed]! Can you prove that disabling ASLR can cause problems (or 'scramble things up')? I'm very sure that it cannot and that it's a good idea to turn it off while debugging an isolated issue. (Of course, it may be a good idea for security reasons to turn it back on for the release builds.) – us2012 Feb 28 '13 at 14:05
  • If ASLR is "breaking" your code, then there is most likely an issue in your code that needs fixed. – jbh Feb 28 '13 at 14:11

2 Answers2

4

If you are using something like UB, there is absolutely no guarantee at all what the address will be. You cannot depend on it being the same every time.

However, you can try disabling ASLR in the Linker settings - one of the attributes there is "Randomized Base Address".

The command-line syntax is /DYNAMICBASE:NO. It doesn't exist in Visual Studio 2005, but it does exist in VS 2012 and later.

anatolyg
  • 26,506
  • 9
  • 60
  • 134
Puppy
  • 144,682
  • 38
  • 256
  • 465
1

I would try using Application Verifier. It is a great way to debug memory leak issues. It will break execution of your code when there is a memory corruption issue.

jbh
  • 1,153
  • 2
  • 11
  • 24