Windows memory layout changes on each build.
For Windows XP/Vista, on a Intel chip, using Visual Studio 2005, I've been trying to write a function that will compute a checksum over a range of instructions during runtime. First I build the application and run it, putting a breakpoint on the checksum comparision( the breakpoint is outside of the range of the checksumming instructions, so the breakpoint isn't mucking up the checksum ). Once I get the sum value, I place that value in the comparision check, recompile, and run it. It runs fine, passing the checksum comparision check every time. If, however, I do a clean solution and rebuild( so delete all the objs basically ), the checksum value is different. How can that be, if NO code has changed? Can anyone explain this to me?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ah, I understand the problem now. I didn't state the problem correctly. The checksumming isn't done over the entire executable. It is a checksum that is done at runtime, every update of the main loop. The checksum is computing the sum of the instructions between instruction A through instruction B( where A and B are asm labels ).
static unsigned int addressStart;
static unsigned int addressEnd;
_asm mov eax,GUARD_1_BEGIN
_asm mov ebx,GUARD_1_END
_asm mov addressStart,eax
_asm mov addressEnd,ebx
unsigned int a = addressStart;
unsigned int sum = 0;
while (a <= addressEnd) {
unsigned rawVal = *(unsigned int*)(a);
rawVal &= 0xffff;
sum += rawVal;
a += 4;
}
cout << x << " checksum=" << sum << endl;
if ( sum != 0x001252b3) {
//return 0;
cout << " checksum=bad" << endl;
}
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
GUARD_1_BEGIN and GUARD_1_END are asm labels defined elsewhere in the application. Basically, there will be multiple checksums going on, each checksum responsible for different memory areas of the application to guard.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi grg99,
Thanks for you help. What I don't understand is how it seems to work fine, EVERYTIME I RUN IT. I've run it 4 or 5 times in a row, loaded firefox/IE/Office before,after/during the process to try and get a different memory layout on my windows machine. The checksum passes with flying colors. Without changing code, I simply delete the object files and recompile. Now, instead of the checksum summing up to 0x001252b3, its an entirely different value. Is the loader determining the byte boundaries when I compile/link the app? I thought the loader did its work when I actually ran the application. What's going on when I recompile so that the checksum changes? obviously its got something to do with memory, and how windows places my application in main memory. I just can't seem to understand how its different just by recompiling code that hasn't changed.
Thanks for you help. What I don't understand is how it seems to work fine, EVERYTIME I RUN IT. I've run it 4 or 5 times in a row, loaded firefox/IE/Office before,after/during the process to try and get a different memory layout on my windows machine. The checksum passes with flying colors. Without changing code, I simply delete the object files and recompile. Now, instead of the checksum summing up to 0x001252b3, its an entirely different value. Is the loader determining the byte boundaries when I compile/link the app? I thought the loader did its work when I actually ran the application. What's going on when I recompile so that the checksum changes? obviously its got something to do with memory, and how windows places my application in main memory. I just can't seem to understand how its different just by recompiling code that hasn't changed.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for all your help. I didn't realize unused space might contain random data.
ASKER
On the other hand, after all this I delete the object files and then rebuild again, the app runs but the checksum fails. No code has changed. So I can accept it has to be something to do with the image header. I've only done console programming, so I'm alittle new to windows.