reading .pdb debug data

[tuli]

Hi,

I am trying to read debug data from a pdb file, specifically the debug data for windows system libraries such as kernel32.dll, where the .pdb was provided by the microsoft symbol store.

I have set this environemnt variabel:

_NT_SYMBOL_PATH =  srv*c:\sym*http://msdl.microsoft.com/download/symbols

where c:\sym\ is my local symbol cache.
I have fired up windbg and loaded some random file to populate the smybol cache, and i now have the public symbols for a lot of windows libraries in c:\sym\

Microsoft provides a very nice example for working wiht pdb files, to be found here: C:\Program Files\Microsoft Visual Studio 9.0\DIA SDK\Samples\DIA2Dump\
(MSVS needs to be installed....)

SO i compiled that example and tried it on itself:

example.exe -all Debug\example.exe.

And sure enough it worked and spit out quiet some info.

Next thing i tried was to load a system lib:

 example.exe -all c:\windows\system32\kernel32.dll

But that failed with this error:

loadDataForExe failed - HRESULT = 806D0005

which stands for "PDB_NOT_FOUND" (or similar). Great.
So i copied kernel32.dll and kernel32.pdb from c:\sym\...\ to c:\, ran -all c:\kernel32.dll again and - poof - it worked!


Although that environemnt variable should really be enough, i tried passing my cache-path directly to the function mentioned in an above error:

hr = (*ppSource)->loadDataForExe(szFilename, L"c:\\sym", &callback);

But again no luck.



Which leaves me with the questions:

==> why wont it read the debugging data, unless it's in the same directory?


I am left feeling a little stupid for having to copy the dll + it's pdb into a temp directory, running the command, then deleting them again.
But maybe that's just what developing for MS Windows feels like.


edit:
resolved the access issue. kernel32.dll had been deleted from my %windir%. Dont ask me how, or why a direct CreateFIle() call succeeded...

[tuli]

it would appear i am not the first or only one to have this problem:

http://social.msdn.microsoft.com/For...-c1903be865e5/

Dear microsoft, if you feel the urge to use technology as broken and unmaintainable as the DIA, please at least make sure the basic and most frequently used tasks actually work.
And when you fail to do so and a customer complains, please fix it, for god s sake.

Unbelievable.

[tuli]

Here's where the DIA is looking for the pdb file.

>Dia2Dump.exe -s c:\windows\system32\kernel32.dll

pdb opening c:\windows\system32\kernel32.pdb...
pdb opening C:\Program Files\Microsoft Visual Studio 9.0\DIA SDK\Samples\DIA2Dump\Debug\kernel32.pdb...
pdb opening C:\WINDOWS\symbols\dll\kernel32.pdb...
pdb opening C:\WINDOWS\dll\kernel32.pdb...
pdb opening C:\WINDOWS\kernel32.pdb...

loadDataForExe failed - HRESULT = 806D0005

But why not look in the local symbol store or _NT_PATH ?
Probably because the developer explicitly forbids it...?

HRESULT STDMETHODCALLTYPE RestrictSymbolServerAccess()
{
// return hr != S_OK to prevent accessing a symbol server
return S_OK;
}

Oh wait, he doesnt.