Enumerating symbols with SymEnumSymbols() doesn't always work

[Sylvester Hesp]

Hi,

I'm trying to list all the symbols in a pdb file. Unfortunately, my
code doesn't work with most of the pdb files I tried it on. It loads
the pdb, and the SymEnumSymbols() returns without errors, but the
supplied callback isn't called.

Here's my code:

------------------------
#include <iostream>
#include <windows.h>
#include <DbgHelp.h>

#pragma comment(lib, "dbghelp")

BOOL CALLBACK EnumSymbolsProc(SYMBOL_INFO * pInfo, ULONG symSize, void
* pContext)
{
char undName[1024];
UnDecorateSymbolName(pInfo->Name, undName, 1024, UNDNAME_COMPLETE);
std::cout << undName << std::endl;
return TRUE;
}

int main()
{
HANDLE hSym = GetCurrentProcess();
SymInitialize(hSym, 0, FALSE);
char * pSymFile = "c:\\full_path_to_pdb.pdb";
if (!SymLoadModuleEx(hSym, 0, pSymFile, 0, 0x00100000, 0, 0, 0))
{
std::cout << "Error loading pdb" << std::endl;
return 0;
}

std::cout << "Loaded" << std::endl;

if (!SymEnumSymbols(hSym, 0x00100000, 0, EnumSymbolsProc, 0))
{
HRESULT r = GetLastError();
std::cout << "Failed: " << r << std::endl;
}

SymCleanup(hSym);
}
------------------------

I have found a project which produces a .pdb that works with above
code, and I've verified every single compiler and linker setting on the
project, but I haven't found a single difference. Note, btw, that
things like enumerating line information and getting a symbol from an
address using SymFromAddr() works fine with all loaded pdb's. It's just
the SymEnumSymbols() (and it's deperecated SymEnumerateSymbols()
counterpart) doesn't work.

Am I doing something wrong? Or is there a compiler/linker setting that
I'm overlooking?

Cheers.
- Sylvester

[Sylvester Hesp]

Sylvester Hesp wrote:
> *snap*

Oh btw, I forgot to mention that I'm running Windows XP x64, the latest
Debugging Tools (x64 version), and have tried it with Visual Studio
2005 and 2008 on two machines

Cheers.
- Sylvester

[Jeffrey Walton]

Hi Sylvester,

SymLoadModuleEx returns the address at which the module was loaded. It
is fed back to SymEnumSymbols as the second parameter. Can you verify
that the module is being loaded at 0x00100000?

See http://msdn.microsoft.com/en-us/library/ms679318(VS.85).aspx.

Jeff

[Sylvester Hesp]

Hi Jeff,

Yes, SymLoadModuleEx() does indeed return 0x00100000. But just to make
sure I passed the returnvalue to SymEnumSymbols(), and I've also tried
different base addresses, but no cigar.

Cheers.
- Sylvester

Jeffrey Walton wrote:
> Hi Sylvester,
>
> SymLoadModuleEx returns the address at which the module was loaded. It
> is fed back to SymEnumSymbols as the second parameter. Can you verify
> that the module is being loaded at 0x00100000?
>
> See http://msdn.microsoft.com/en-us/library/ms679318(VS.85).aspx.
>
> Jeff
>
> On Feb 24, 10:00 am, Sylvester Hesp <a...@b.c> wrote:
>> Hi,
>>

>> ...
>>
>> Cheers.
>> - Sylvester

[pat styles [microsoft]]

Hello Sylvester.

My suggestion is to run dbh.exe on the pdb in question and see how well it
does. This will show you what symbols are available in the pdb. BTW, the
source for dbh.exe is in the PSDK.

dbh.exe foo.pdb x *

.pat styles [microsoft]

"Sylvester Hesp" <a@b.c> wrote in message
news:49a43441$0$197$e4fe...@news.xs4all.nl...

[Sylvester Hesp]

Thanks for the tip! Dbh.exe indeed showed all symbols as expected, so I
thought it must be the way I'm using the dbghelp API. But after
investigating the sourcecode it revealed nothing different than what
I'm doing. However, trying to actually debug dbh.exe was a different
experience altogether. It simply wouldn't run because of missing
functions in dbghelp.dll.

This got me thinking... I copied the dbghelp.dll from the debugging
toosl install dir to the dir of my .exe file but that didn't help. I
triend building a x64 version of dbh.exe, and now it runs and shows
symbols!

So apparently, there were two issues I wasn't aware of
- I need to install the 32 bits version of debugging tools while using
the dbghelp api in 32 bits applications, even though the download page
clearly states I only need the 64 bit version for both 32-bit and
64-bit debugging on a 64-bit processor
- The debugging tools installer does not replace the default
dbghelp.dll in the windows\system32 directory, so you have to make sure
to somehow reference it from the right location (for instance by
copying it to your exe dir). I have read nothing about SxS assemblies
nor does a search in \windows\WinSxS\ reveal any dbghelp.dll so I
assume simply adding a manifest describing the right dbghelp version
isn't going to do the trick.

Anyway, thanks for the pointers, it all works as expected now :)

Cheers.
- Sylvester

pat styles [microsoft] wrote:
> Hello Sylvester.
>
> My suggestion is to run dbh.exe on the pdb in question and see how well it
> does. This will show you what symbols are available in the pdb. BTW, the
> source for dbh.exe is in the PSDK.
>
> dbh.exe foo.pdb x *
>
> .pat styles [microsoft]
>
> "Sylvester Hesp" <a@b.c> wrote in message

> ...

[pat styles [microsoft]]

Hello Sylvester.

The 64 bit version of dbh.exe *will* analyze the pdb of a 32bit application.
It just needs to call a 64 bit version of dbghelp.dll. This is pretty much
how most applications work. One would have to go to extra effort to marshal
the calling of a 32 bit dll from a 64 bit application. I'll bet if you had
run dbh.exe from the directory the it and the debugger bits were installed
to, everything would have worked fine.

dbh.exe deliberately calls the dbghelp.dll in that same directory and not
any other in the path for good reason. The dbghelp.dll in the system
directory is not something you can upgrade as a normal Windows user.
Therefore, it is expected that the version of that file could be really old
and out of date. dbh.exe (and the other debugger bits) specifically
LoadLibrary dbghelp.dll from the same directory is is in.

.pat styles [microsoft]

"Sylvester Hesp" <a@b.c> wrote in message

news:49a47b72$0$191$e4fe...@news.xs4all.nl...

[Jeffrey Walton]

Hi Sylvester,

> The debugging tools installer does not replace the default
> dbghelp.dll in the windows\system32 directory, so you have to make sure
> to somehow reference it from the right location (for instance by
> copying it to your exe dir).

This is a known 'issue' ('issue' may be too strong) [1]. I like to say
that Dll hell is alive and well with the library. The reason is that
DbgHlp is offered by the OS Team (corrections, please) as a tool for
developers. It is not a core file so Windows Update Services does not
update it. In fact, if you tried to copy the latest to %SYSTEM32%,
Windows File Protection would revert it to a down level version.

Jeff

[1] http://www.codeproject.com/KB/cpp/BackPatch.aspx

> > "Sylvester Hesp" <a...@b.c> wrote in message
> > ...- Hide quoted text -
>
> - Show quoted text -

[roge...@gmail.com]

On Feb 25, 5:32 pm, Jeffrey Walton <noloa...@gmail.com> wrote:

> This is a known 'issue' ('issue' may be too strong)

My own solution is to take a copy of DbgHelp.dll from Debugging Tools
for Windows as 'DbgCopy.dll', and put it on the path.
My own utilities load 'DbgCopy', rather than 'DbgHelp', and hence
don't have potential conflicts with the 'system' version of
DbgHelp.dll

Regards,
Roger.