DBGHelp.dll -- getting value of symbols

[neojava]

Hi, I am trying to write a function which will spit out the function
parameters of its parent function. I have tried to implement this using
DBGHelp.dll. Not easy considering the minimal documentation! However, I am
very close to making it work.

I can walk the stack and find the stackframe for the function I am
interested in. I then enumerate the symbols and I can see the symbol names
in PSYMBOL_INFO. However I cannot seem to get any other detailed information
from the symbols. Nearly all my calls to SymGetTypeInfo with various
IMAGEHLP_SYMBOL_TYPE_INFO fail with an error code of 1. The only one that
succeeds is TI_GET_BASETYPE. I am interested in getting the name, type, and
the value for each of the symbols. Below is my call to SymGetTypeInfo. My gut
feeling is that I am missing some minor little detail, or that I am somehow
not initializing something properly.

Any advice would be great. Thanks,
Adam

BOOL CALLBACK SymEnumSymbolsCallback( PSYMBOL_INFO pSymInfo, ULONG
SymbolSize, PVOID UserContext)
{
int symbolType=0;
if (!SymGetTypeInfo(GetCurrentProcess(),pSymInfo->ModBase,
pSymInfo->TypeIndex, TI_GET_TYPE,&symbolType))
{
DWORD ErrCode = GetLastError();
if( ErrCode == 1 )
std::cout<<"Error: SymGetTypeInfo() failed. Property not
supported"<<std::endl;
else
std::cout<<"Error: SymGetTypeInfo() failed. Error
code:"<<::GetLastError()<<std::endl;
}

[roge...@gmail.com]

On Mar 12, 3:00 pm, neojava <neoj...@discussions.microsoft.com> wrote:
> Hi, I am trying to write a function which will spit out the function
> parameters of its parent function.  I have tried to implement this using
> DBGHelp.dll.  Not easy considering the minimal documentation! However, I am
> very close to making it work.
>
> I can walk the stack and find the stackframe for the function I am
> interested in.  I then enumerate the symbols and I can see the symbol names
> in PSYMBOL_INFO.  However I cannot seem to get any other detailed information
> from the symbols. Nearly all my calls to SymGetTypeInfo  with various
> IMAGEHLP_SYMBOL_TYPE_INFO fail with an error code of 1.  The only one that
> succeeds is TI_GET_BASETYPE. I am interested in getting the name, type, and
> the value for each of the symbols. Below is my call to SymGetTypeInfo. My gut
> feeling is that I am missing some minor little detail, or that I am somehow
> not initializing something properly.

Start with:-

enum SymTagEnum tag = (enum SymTagEnum)0;
SymGetTypeInfo( GetCurrentProcess(), pSymInfo->ModBase, pSymInfo-
>TypeIndex, TI_GET_SYMTAG, &tag );

Then switch on the various tag values...

Most simple variables will be "SymTagBaseType".

For this tag type you can call TI_GET_BASETYPE.
Look in cvconst.h for the various btXxx values in the BasicType enum

TI_GET_SYMNAME gets you the name of the type (which you seem to need
to LocalFree).
TI_GET_LENGTH gets you the # bytes

Regards,
Roger.

[neojava]

Roger,
Thanks, the suggestion was illuminating. I had previously been looking at
the Tag returned from the PSYM_INFO in the EnumSymbolsCallback function. It
was always returned SymTagData.

Following your direction
SymGetTypeInfo( GetCurrentProcess(), pSymInfo->ModBase, pSymInfo, TypeIndex,
TI_GET_SYMTAG, &tag );

now allows me to see the following two types:
SymTagBaseType
SymTagPointerType.

However when I try to get the SymTag for a symbol that is a class or struct
I end up with SymTagNull. I suspect that I have either somehow not properly
loaded the symbols or that I need to drill down into the child symbols to get
the information. I tried checking to see if the Symbol had children via
SymGetTypeInfo but I get back 0.

Any ideas?

Thanks Again,
Adam

[neojava]

It turns out that I was using the wrong version of the DLL. I was using the
DLL in the Windows/system32. I copied the most recent version of the DLL to
my executable's directory and suddenly everything started to work.

If anyone else encounters strange issues with DBGhelp where absolutely
nothing seems to make sense the first thing to check would be that you are
using the most recent DLL.

http://blogs.msdn.com/matt_pietrek/archive/2005/02/04/367494.aspx

[Jeffrey Walton]

Hi Adam,

Sorry to off the newsgroup...

On Mar 13, 2:31 pm, neojava <neoj...@discussions.microsoft.com> wrote:
> It turns out that I was using the wrong version of the DLL. I was using the
> DLL in the Windows/system32.

It burned me also. I make it a point to call load library on
DbgHelp.dll (even though I am statically linked) to verify the version
info on DbgHelp. I think this is the only time I have ever checked a
file version at runtime.

> I copied the most recent version of the DLL to my executable's directory
> and suddenly everything started to work.

And Windows File Protection won't allow us to drop a newer version
into \System32...

Jeff

[Pat Styles [MSFT]]

Hello Jeffrey.

Please note my comments on this topic from another thread. I understand that
you may not like to copy over your required version of dbghelp.dll, however
that is how you are supposed to use it and for good reason. It allows you to
get new versions of the dll before the next OS release. Updating the version
in the system32 directory is a serious security issue and we cannot do this.
You need to ship with whatever version you need.

from the other thread...

I have always suggested if you need a certain version dbghelp.dll to support
your application, then you should ship with it in your program directory and
specifically load it from there. That is how windbg.exe and the other
debuggers load dbghelp.dll and that is also how dbghelp.dll loads symsrv.dll
and srcsrv.dll. All three of these modules are completely redistributable.
You own your destiny here.

.pat styles [microsoft]

"Jeffrey Walton" <nolo...@gmail.com> wrote in message
news:7ba739e1-4293-4285...@p25g2000hsf.googlegroups.com...