An interesting result: the breakpoint was hit (rsCheckData had been corrupted to 0x00000001), but rsThreadData - the value created from the same pointer when the function was called - was NOT corrupted:
rsCheckData = 0x00000001
rsThreadData = 0x02F51F54
On the outside of the function (up the call stack one level to the place where it is called), psThreadData (still held in ESI) is valid (0x02F51F54). Thus, although it was passed in twice with the same value, the first one got corrupted on entry!
OK, this probably means that some other piece of code is trashing the memory which holds this variable. This indeed proves that the compiler is right (it just pushes the value two times instead of one time, and the last one gets corrupted.)
Now, what you've got to do is to find out what part of the code is doing this change, and that's the hard part. How long does it get the app to crash? Does it crash under the debugger as well? Can you step through the code in the caller right before the call to WaitForRX which leads to the crash? We've really got to take a look at the stack memory as well as the registers to debug this thing.
---------
Ehsan Akhgari
www.farda-tech.com
List Owner: [email protected]
[Email: [EMAIL PROTECTED]]
[WWW: http://www.beginthread.com/Ehsan
]
| State is the name of the coldest of all cold
monsters. Coldly it lies; and this lie slips from its mouth: "I, the
state, am the people." -Thus Spoke Zarathustra, F. W. Nietzsche |
_______________________________________________ msvc mailing list [email protected] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
