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?
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.