Ahh I understand better now. When multiple inheritance is used you do
need to do more work to figure out the correct “this” pointer to cast.
If you debug release mode optimized programs in Visual Studio, it most
often cannot actually figure out what the correct “this” pointer is and
you’ll have to go hunting through registers (often “esi” is used) and
add
some painstakingly calculated offset to that pointer to actually get it
to show up as the object you want. As far as I can tell, this is the
method you have to ALWAYS use in WinDbg.
Is this a sperate issue? In any case if you Windbg isn’t figuring out
the local vars like you think it should then get a concrete example
(like a dump) and send it to the debugger team. Contact info is someone
on http://www.microsoft.com/ddk/debugging
If I have a list of addresses representing a call stack in my
application,
written down in a text file, and a copy of the application and my .pdb
file, but no longer any process to attach to, how do I use WinDbg to
actually turn these addresses into symbol values. Basically, all I want
to do is use WinDbg as a convenient symbol file parser…
What you need in addition to the symbols are the load addresses
of modules. The symbols contain offsets from this load location for
each function. Armed with that information a tool could take an address
& give you the module it’s in (if any) and the closest matching symbol
in that module. Once you have that it is easy to iterate over a list of
addresses (your stack). This would be the same as doing a “dds” command
in windbg.
An actual stack walk is more complex, but could be done too.
I know of no tool that does this. Windbg certainly is close to
doing this, but it always works against a target & gets info like module
load info from that target. If you had a target (either running process
or dump) which had the exact same modules loaded at the same addresses
then you could just “ln” each address in your text file.
You could write your own app to do it without a target by using
the DbgHelp.dll. There are some past BugSlayer columns in MSDN which
use DbgHelp API to build a map file (text file which contains function
offsets and such) from a PDB. That would get you most of the way to
writing a tool that does what you want.
However I think the winning scenerio would be to try and get a
dump instead of a text file of addresses. You could do so much more and
use familiar tools. Minidumps are pretty small if that is the concern.
The debugger even includes a sample on how an app can use dbgeng.dll to
make a minidump of its self if it detects a fault.
-----Original Message-----
From: WinDbg [mailto:xxxxx@mindcontrol.org]
Sent: Wednesday, July 24, 2002 9:56 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: WinDBG Feature requests
- This doesn’t really have to do with information in the symbols
file, but rather run-time identification of which class you really
have a pointer to. I don’t know if it is possible or not. If it is
possible then chance are the Visual Studio debugger does it. If is is
possible I
It is possible, and Visual Studio does it, and it does it even when you
don’t enable RTTI. In fact, if you have a pointer to some abstract
class;
*ANY* abstract class, and dereference it, and it appears to be pointing
at “something else”, then the type displayed of the dereferenced pointer
will be that of “something else” rather than the “statically known” type
of the abstract class. Pretty slick!
You should be able to manually type cast a pointer in the watch/locals
window to a different class. So this should work manually.
The problem with that is that, when you’re using multiple inheritance,
just taking the bits and casting them to another pointer type isn’t
sufficient. Because of the multiple inheritance layout rules, the “this”
pointer value for the same object actually changes depending on which
interface you’re entering the object implementation through (i e, the
assumed offset of “this” from the actual start of the object is
different
in different member functions).
If you debug release mode optimized programs in Visual Studio, it most
often cannot actually figure out what the correct “this” pointer is and
you’ll have to go hunting through registers (often “esi” is used) and
add
some painstakingly calculated offset to that pointer to actually get it
to show up as the object you want. As far as I can tell, this is the
method you have to ALWAYS use in WinDbg.
Of course, as far as low-level monitors go, WinDbg is pretty studly, so
I’m not complaining too loudly.
Which lets me Non Sequiteur into my actual question 
If I have a list of addresses representing a call stack in my
application,
written down in a text file, and a copy of the application and my .pdb
file, but no longer any process to attach to, how do I use WinDbg to
actually turn these addresses into symbol values. Basically, all I want
to do is use WinDbg as a convenient symbol file parser…
I’m able to open the .exe and have it find the .pdb by setting the right
symbol path, but then I’m a little stuck on how to use this context to
resolve address->symbol (rather than the other way around). I tried
plugging in some search words in the help file but didn’t find anything
obvious, although I’m sure it’s some simple command I’m just missing.
Cheers,
/ h+
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%