http://www.codeproject.com/KB/threads/StackWalker.aspx
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lin George
Sent: Thursday, September 25, 2008 14:08
To: Kernel Debugging Interest List
Cc: Kernel Debugging Interest List
Subject: SPAM-LOW: Re: [windbg] Debugging issue to watch variable values
Thanks Martin!
Actually I have read this, but it only covers the format of PDB file in a
very high level (e.g. into blocks and streams), not mentioned how debugger
utilizing PDB file to work. Any comments? Do you have any brief description
of how debugger utilizing PDB file? 
http://www.informit.com/articles/article.aspx?p=22685
regards,
George
----- Original Message ----
From: Martin O’Brien
To: Kernel Debugging Interest List
Sent: Thursday, September 25, 2008 9:02:05 PM
Subject: Re:[windbg] Debugging issue to watch variable values
I don’t know if it is still published, but ‘Undocumented Windows 2000
Secrets’ covers part of this.? There’s not a whole lot out
there that discusses this subject.
Good luck,
mm
Lin George wrote:
> Thanks Skywing,
>
>
> 1.
>
> So you think my issue of watching variables in release x64 mode with
optimized code is, PDB file has limitation which could not correctly
reflects the values in registers?
>
> 2.
>
> I am interested in how debugger could utilize information in PDB file to
find related symbol related to some binary code. And also how to find
related source code. I have made quite some search, but few good
documents/articles. Do you have any of such materials to recommend to read?
>
>
> regards,
> George
>
>
> ----- Original Message ----
> From: Skywing
> To: Kernel Debugging Interest List
> Cc: Kernel Debugging Interest List
> Sent: Thursday, September 25, 2008 8:49:28 PM
> Subject: RE: [windbg] Debugging issue to watch variable values
>
> To reiterate what I said earlier, as far as I know, the debug info
format’s support for locals is based on the assumption that they are stack
based.
>
> This is a limitation of the current tools, and not so much of any
fundamental technical roadblock aside from the fact that it’s not how things
were written to work.
>
> This is why debug builds always try and put locals on the stack instead of
exclusively saving them in a register.
>
> The .pdb is built at code generation time.? Think of it as reflecting a
view of locals before the optimizer has had a chance to figure out that some
locals do not need to live on the stack at all, but may reside exclusively
in a register.
>
> - S
>
> -----Original Message-----
> From: Lin George
> Sent: Thursday, September 25, 2008 01:07
> To: Skywing
> Cc: Kernel Debugging Interest List
> Subject: Re: [windbg] Debugging issue to watch variable values
>
>
> Thanks Skywing,
>
>
> 1.
>
> I think PDB is generated at compile/link time, correct?
>
>
> I listed my confusions in 2 and 3, but I do not know which one is correct.
Any comments?
>
> 2.
>
> If yes to 1, then during compile/link time, whether variable will be put
on stack or in register is still not decided, only during runtime will the
location (whether variable on stack or in register) be decided. – So that
the generated PDB is not matching the exact situation (e.g. PDB may think
some variable on stack, but actually it is in register), which cause the
wrong variable value during debugging?
>
> 3.
>
> If yes to 1, then during compile/link time, whether variable will be put
on stack or in register is still be decided, but PDB will completely ignore
such information in register.? – So that the generated PDB is not matching
the exact situation (e.g. PDB may think some variable on stack, but actually
it is in register), which cause the wrong variable value during debugging?
>
>
> regards,
> George
>
>
> ----- Original Message ----
> From: Skywing
> To: Kernel Debugging Interest List
> Cc: Kernel Debugging Interest List
> Sent: Thursday, September 25, 2008 1:11:17 PM
> Subject: RE: [windbg] Debugging issue to watch variable values
>
> .pdb is the debug file information format which contains symbol and type
info (including line number mappings) for a binary.
>
> As far as I know, the current .pdb formats only describe locals in terms
of stack locations and not registers.? Thus, for locals (including function
arguments) that get moved into registers, this fact is not recorded in a
usable way that would allow the debugger to track this.
>
> The bottom line is that when you have parameters and locals being moved
into registers, they will not show correct values in the local variable
display in the debugger.? The only guaranteed reliable way to do it is to
look at the actual disassembly and figure out what variables are going
where.
>
> - S
>
> -----Original Message-----
> From: Lin George [mailto:xxxxx@yahoo.com]
> Sent: Thursday, September 25, 2008 12:50 AM
> To: Skywing
> Cc: Kernel Debugging Interest List
> Subject: Re: [windbg] Debugging issue to watch variable values
>
> Hi Skywing,
>
>
> 1.
>
> My confusion is what is the relationshp between PDB and source code, in
what mechanisms do PDB and source code establish mapping relationship?
>
> 2.
>
> “This is because PDB does not allow reliable tracking of variables that
get cached in registers” – I always think PDB is 100% match binary even if
optimized code, but seems not?
>
>
> regards,
> George
>
>
> ----- Original Message ----
> From: Skywing
> To: Kernel Debugging Interest List
> Sent: Wednesday, September 24, 2008 9:58:05 PM
> Subject: RE: [windbg] Debugging issue to watch variable values
>
> This is because PDB does not allow reliable tracking of variables that get
cached in registers.
>
> You should be analyzing the code manually in this case.
>
> Local variable support is only reliable when you are doing source line
stepping in a non-optimized debug build.
>
> - S
>
> -----Original Message-----
> From: Lin George
> Sent: Wednesday, September 24, 2008 05:09
> To: Kernel Debugging Interest List
> Subject: [windbg] Debugging issue to watch variable values
>
>
> Hello everyone,
>
>
> 1.
>
> Sometimes in x64 release code (optimized to full level), even if we
defined some global data, variables or member variables for some data
structures, we can not see the actual value in debugger. The related error
message is – “Error: expression cannot be evaluated”.
>
> I think it is because of x64 code optimization to remove some variables or
changed code execution path?
>
> 2.
>
> Any ways to “watch” such variables? Currently I am just looking at the
asembly code to find what the actual execution is. For example, in source
code I pass variable foo to function SetValue, but since in debugger I can
not watch such variable foo, then I go to assembly code to watch what values
are passed to function SetValue through register or stack.
>
> Any better ideas to debug such x64 optimized code? Is it a common issue in
debugging x64 release code?
>
>
> thanks in advance,
> George
>
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@valhallalegends.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>
> —
> You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>
> —
> You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>? ? ?
>
—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Information from ESET NOD32 Antivirus, version of virus signature
database 3471 (20080925)
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
). That with the DbgHelp interface (as Ski pointed out) would be good thing to look at… that has plentry of infos about pdb etc…