WinDbg Memory pane sees different values than code

[Ilya Konstantinov]

While the following might sound theoretical, this is at the base of a
real problem I'm having now: a crash attributed to "memory_corruption"
before my driver even loads but completely dependent on my driver being
loaded. I'm seeing this only on a certain brand of machines -- a
certain 4 CPU (8 with HT) beast.

When my driver loads (before DriverEntry is invoked), RtlImageNtHeader
is called. Among others, it verifies that my PE driver has a valid "MZ"
signature. It is failing this check and subsequentially crashing[1].
The compare operation is pretty straightforward:
cmp word ptr[eax], 5a4d
While standing on this command, WinDbg's Disassembler suggested that
word ptr[eax] indeed contained 5a4d. However, the result of the
comparison was: unequal (ZF = 0).

Looking at @eax in the Memory pane showed a beatiful header starting
with:
MZ.. 0x4d 0x5a 0x90 0x00
However, when I tried reading this DWORD from the context of the code
(by manipulating some 'mov' I found in the code to do this -- a dirty
trick), I've got:
0xcc 0x5a 0x90 0x00

0xcc? Weird! How could it be that WinDbg's Memory pane shows something
different than what the code sees?
Next thing, I tried overwriting the header with 0x01 0x02 0x03 0x04 and
then reading it back from the code. Guess what I've got?
0xcc 0x02 0x03 0x04

How could this be possible? Are WinDbg's memory reads performed
differently?

P.S. I had additional two pairs of eyes seeing this, suggesting that
I'm not hallucinating.

[1] MiEnablePagingForDriver never checks RtlImageNtHeader's return
value but that's a different issue altogether (and a corrupted driver
will cause a bugcheck one way or another, so this is not significant).

[Alexander Grigoriev]

Remove all breakpoints. 0xCC you see is a stray breakpoint beause of WinDbg
configuration screwed up.

"Ilya Konstantinov" <ilya.kon...@gmail.com> wrote in message
news:1127563715.9...@z14g2000cwz.googlegroups.com...