Memory read error - while trying to examine variables in windbg

WINDBG
2

Hi,
The code actually runs ok. (except for a small bug I am trying to fix)

I’m not analyzing a dump file, I am stepping through the driver C source
line by line without problem, no crash.

When I do a !teb command, I get the following error:

0:000> !teb
TEB at 000007fffffde000
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_TEB ***
*** ***
*************************************************************************
error InitTypeRead( TEB )…

Register dump at this point shows:

0:000> r
rax=0000000001f501e0 rbx=00000000000ae5f0 rcx=000007ff7fca25ba
rdx=0000000000000000 rsi=0000000000000000 rdi=00000000000aee98
rip=0000000001ecb622 rsp=00000000000ae0a0 rbp=0000000000000017
r8=00000000000ae098 r9=0000000000000017 r10=0000000000000000
r11=0000000000000246 r12=00000000000aef08 r13=00000000000aee40
r14=fffffadfbb158248 r15=0000000000000001
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b
efl=00000246
bgspd64!DrvTextOut+0x2b2:
0000000001ecb622 4883bc248000000000 cmp qword ptr [rsp+0x80],0x0 ss:00000000000ae120=0000000001f501e0

So the !teb command shows that windbg cant find my symbols, even though it
tells me earlier that it has loaded my symbol file. The debugger seems to
know about all the symbols, it just cant show me the right values for them.
e.g. if I do a “dv /V” I can see names of my locals, but cant see the
values.
The PDB file gets generated each time I build - its not an old one. I have
deleted all other PDB’s around that it could be getting confused with.

I have actually had to move on with this, as I am out of ideas. I’ve been
debugging by printing out variables to the debugger output. Still, would be
nice to be able to use the debugger properly!

Cheers,
Craig

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, 12 July 2005 11:58 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Memory read error - while trying to examine variables
in windbg

I’ve never seen a user mode stack on page zero (like this one). One
possibility is that someone has overwritten the child RBP and then done a
return. Where does the TEB (!teb) say the thread stack is located? Where
is RSP?

Bottom line: I don’t think this is a *debugger* problem - seems more like a
screwed up thread state, either because someone clobbered a register
directly or (more likely) indirectly - either by misaligning the stack
(doing any mixed language programming?) or by scribbling over a local
variable (in some function you called) and zeroing out the RBP value (ah,
but quite impressive - NOT overrunning the return address!)

In what context are you debugging? Have you been single stepping through
the code and WHAM! suddenly the machine state is wrong? Or is this a post
mortem crash you are analyzing?

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>

3

There’s a difference between the symbols for nt (which is where the
nt!_TEB symbol will come from), and the symbols from your driver, which
are generated at build time for you. ‘lml’ will tell you the symbol
status for each module which has attempted a symbol load.

Jason

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Craig Broadbear
Sent: Monday, July 11, 2005 9:27 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Memory read error - while trying to examine
variables in windbg

Hi,
The code actually runs ok. (except for a small bug I am trying to fix)

I’m not analyzing a dump file, I am stepping through the driver C source
line by line without problem, no crash.

When I do a !teb command, I get the following error:

0:000> !teb
TEB at 000007fffffde000
************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: nt!_TEB
***
***
***
************************************************************************
*
error InitTypeRead( TEB )…

Register dump at this point shows:

0:000> r
rax=0000000001f501e0 rbx=00000000000ae5f0 rcx=000007ff7fca25ba
rdx=0000000000000000 rsi=0000000000000000 rdi=00000000000aee98
rip=0000000001ecb622 rsp=00000000000ae0a0 rbp=0000000000000017
r8=00000000000ae098 r9=0000000000000017 r10=0000000000000000
r11=0000000000000246 r12=00000000000aef08 r13=00000000000aee40
r14=fffffadfbb158248 r15=0000000000000001
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b
efl=00000246
bgspd64!DrvTextOut+0x2b2:
0000000001ecb622 4883bc248000000000 cmp qword ptr [rsp+0x80],0x0 ss:00000000000ae120=0000000001f501e0

So the !teb command shows that windbg cant find my symbols, even though
it tells me earlier that it has loaded my symbol file. The debugger
seems to know about all the symbols, it just cant show me the right
values for them. e.g. if I do a “dv /V” I can see names of my locals,
but cant see the values.
The PDB file gets generated each time I build - its not an old one. I
have deleted all other PDB’s around that it could be getting confused
with.

I have actually had to move on with this, as I am out of ideas. I’ve
been debugging by printing out variables to the debugger output. Still,
would be nice to be able to use the debugger properly!

Cheers,
Craig

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, 12 July 2005 11:58 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Memory read error - while trying to examine
variables in windbg

I’ve never seen a user mode stack on page zero (like this one). One
possibility is that someone has overwritten the child RBP and then done
a return. Where does the TEB (!teb) say the thread stack is located?
Where is RSP?

Bottom line: I don’t think this is a *debugger* problem - seems more
like a screwed up thread state, either because someone clobbered a
register directly or (more likely) indirectly - either by misaligning
the stack (doing any mixed language programming?) or by scribbling over
a local variable (in some function you called) and zeroing out the RBP
value (ah, but quite impressive - NOT overrunning the return address!)

In what context are you debugging? Have you been single stepping
through the code and WHAM! suddenly the machine state is wrong? Or is
this a post mortem crash you are analyzing?

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

There’s definitely something strange - while you can’t find the TEB
(sure sounds like wrong OS symbols, did you try “.symfix” and then add
the path to your program symbols?) the RSP is 00000000000ae0a0 but RBP
is 17 - that means your *stack frame* is 712,841 bytes. Now, that’s
(barely) within the limits of the normal user stack size, it is
alarmingly large.

So, my guess is that the RBP has been reused for something other than as
a stack frame. Since there is already some sort of symbol issue going
on, I’d check and see if the symbols are properly loaded. As Jason
suggests, “lml” will give you the loaded module list and show you the
symbols that are, or are not loaded. Another trick is to use “!sym
noisy ; .reload” to turn on symbol loading debugging.

With partial or wrong symbols, the debugger tries hard to provide valid
information but is often wrong. I’ve watched people get frustrated with
WinDBG numerous times over this issue, but once we get symbols fixed and
working properly, life is good - and using the debugger is vastly better
than relying upon DbgPrint messages…

Regards,

Tony

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Craig Broadbear
Sent: Tuesday, July 12, 2005 12:27 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Memory read error - while trying to examine
variables in windbg

Hi,
The code actually runs ok. (except for a small bug I am trying to fix)

I’m not analyzing a dump file, I am stepping through the driver C source
line by line without problem, no crash.

When I do a !teb command, I get the following error:

0:000> !teb
TEB at 000007fffffde000
************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: nt!_TEB
***
***
***
************************************************************************
*
error InitTypeRead( TEB )…

Register dump at this point shows:

0:000> r
rax=0000000001f501e0 rbx=00000000000ae5f0 rcx=000007ff7fca25ba
rdx=0000000000000000 rsi=0000000000000000 rdi=00000000000aee98
rip=0000000001ecb622 rsp=00000000000ae0a0 rbp=0000000000000017
r8=00000000000ae098 r9=0000000000000017 r10=0000000000000000
r11=0000000000000246 r12=00000000000aef08 r13=00000000000aee40
r14=fffffadfbb158248 r15=0000000000000001
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b
efl=00000246
bgspd64!DrvTextOut+0x2b2:
0000000001ecb622 4883bc248000000000 cmp qword ptr [rsp+0x80],0x0 ss:00000000000ae120=0000000001f501e0

So the !teb command shows that windbg cant find my symbols, even though
it tells me earlier that it has loaded my symbol file. The debugger
seems to know about all the symbols, it just cant show me the right
values for them. e.g. if I do a “dv /V” I can see names of my locals,
but cant see the values.
The PDB file gets generated each time I build - its not an old one. I
have deleted all other PDB’s around that it could be getting confused
with.

I have actually had to move on with this, as I am out of ideas. I’ve
been debugging by printing out variables to the debugger output. Still,
would be nice to be able to use the debugger properly!

Cheers,
Craig

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, 12 July 2005 11:58 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Memory read error - while trying to examine
variables in windbg

I’ve never seen a user mode stack on page zero (like this one). One
possibility is that someone has overwritten the child RBP and then done
a return. Where does the TEB (!teb) say the thread stack is located?
Where is RSP?

Bottom line: I don’t think this is a *debugger* problem - seems more
like a screwed up thread state, either because someone clobbered a
register directly or (more likely) indirectly - either by misaligning
the stack (doing any mixed language programming?) or by scribbling over
a local variable (in some function you called) and zeroing out the RBP
value (ah, but quite impressive - NOT overrunning the return address!)

In what context are you debugging? Have you been single stepping
through the code and WHAM! suddenly the machine state is wrong? Or is
this a post mortem crash you are analyzing?

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com