I am using WinDbg 6.11.0001.404 (x86) on a Windows 7 x64.
I have the following environment variables setup:
_NT_EXECUTABLE_IMAGE_PATH=cache*T:\symbols\sym;srv*T:\symbols\sym*http://msdl.microsoft.com/download/symbols
_NT_SYMBOL_PATH=cache*T:\symbols\sym;srv*T:\symbols\sym*http://msdl.microsoft.com/download/symbols
DBGHELP_HOMEDIR=T:\symbols
When I try to load the symbols, I get the following output from !sym noisy:
0:001> .reload /f notepad.exe
SYMSRV:
t:\symbols\sym\notepad.pdb\E325F5195AE94FAEB58D25C9DF8C0CFD2\notepad.pdb
not found
SYMSRV: notepad.pdb from http://msdl.microsoft.com/download/symbols:
42984 bytes - copied
DBGHELP:
T:\symbols\sym\notepad.pdb\E325F5195AE94FAEB58D25C9DF8C0CFD2\notepad.pdb
- file not found
DBGHELP: C:\WINDOWS\SysWOW64\notepad.pdb - file not found
DBGHELP: notepad.pdb - file not found
*** ERROR: Module load completed but symbols could not be loaded for
C:\WINDOWS\SysWOW64\notepad.exe
DBGHELP: notepad - no symbols loaded
I also see the following file created:
t:\symbols\sym\notepad.pdb\E325F5195AE94FAEB58D25C9DF8C0CFD2\notepad.pd_
Though, the symbols are not loaded:
0:001> lmm notepad
start end module name
00490000 004c0000 notepad (no symbols)
The notepad.pd_ file looks like a cabinet (.cab) that contains just the
single notepad.pdb.
If I manually uncab the notepad.pd_ file in the same directory, WinDbg
is able to load the symbols just fine:
0:001> .reload /f notepad.exe
DBGHELP: notepad - public symbols
t:\debughomedir\sym\notepad.pdb\E325F5195AE94FAEB58D25C9DF8C0CFD2\notepad.pdb
Why does WinDbg download the symbols in compressed format, does not
uncompress them, and then expect to fail? This is very frustrating.
I don’t remember this happening in older WinDbg versions, two years or
so ago.
Hmmm. I’m not sure exactly what you could have done to cause this, but what you’re observing is what happens if you setup a symbol store and add files to it with the /compress option.
symstore add /t t /f c:\tmp_hal.pdb /compress /s x:\target\sym
cd\target\sym_hal.pdb\F53D289AB3314A8B8B91E848E41639A41
dir /b
hal.pd
Unfortunately, I don’t know how this information helps you. The only thing I can think of to suggest is trying it without the the ‘cache*’ statement. I’m not saying it’s a problem; I’ve never used it, but it does stand out and I also don’t see what it’s doing for you in your case.
Good luck,
mm
Removing cache* did the trick, thanks mm!
Not sure if the documentation mentions that this may happen. It is strange.
xxxxx@evitechnology.com wrote:
Hmmm. I’m not sure exactly what you could have done to cause this, but what you’re observing is what happens if you setup a symbol store and add files to it with the /compress option.
symstore add /t t /f c:\tmp_hal.pdb /compress /s x:\target\sym
cd\target\sym_hal.pdb\F53D289AB3314A8B8B91E848E41639A41
dir /b
hal.pd
Unfortunately, I don’t know how this information helps you. The only thing I can think of to suggest is trying it without the the ‘cache*’ statement. I’m not saying it’s a problem; I’ve never used it, but it does stand out and I also don’t see what it’s doing for you in your case.
Good luck,
mm
Glad I could help.
I’d like to be able to claim this as a result of clever insight, but, alas, I can’t. I haven’t a clue why removing ‘cache’ fixed the problem, but I’m glad it did. It just stuck out as ‘different’ to me, so I thought I’d mention it as worth a shot.
Having just reread the windbg docs on the subject, I still don’t see anything that would explain this behavior. It’s quite possible I’m just missing something or looking in the wrong place, but I forwarded something to someone on the windbg team to see what they think.
mm
wrote in message news:xxxxx@windbg…
…
> Having just reread the windbg docs on the subject, I still don’t see
> anything that would explain this behavior. It’s quite possible I’m just
> missing something or looking in the wrong place, but I forwarded something
> to someone on the windbg team to see what they think.
>
> mm
On a different issue, I’ve received a reply from windbg team that they are
going
to correct some doc errors on sympath syntax, related to cache*.
Looking forward for their next great release…
–pa