symbol problems

[Andrew]

Im running xp sp1 - when i use the symbol server i get errors saying the
symbols are incorrect - then I ran symchk to get the symbols and all of the
are failing - here is a little snippet

C:\Program Files\Debugging Tools for Windows>symchk /r c:\windows\system32
/s sr
v*c:\symbols*http://msdl.microsoft.com/download/symbols
SYMCHK: 6to4svc.dll FAILED - 6to4svc.pdb mismatched or not found
SYMCHK: acelpdec.ax FAILED - Built without debugging information.
SYMCHK: AdobePDF.dll FAILED - AdobePDFNT.pdb mismatched or not
found
SYMCHK: asfsipc.dll FAILED - asfsipc.pdb mismatched or not found

Please help

Thanks

[Ben McDonald [MSFT]]

Andrew,

Ahhh.. It would be wonderful to have a single place to go, where all
manufacturers checked in symbols for thier apps. Unfortunatly, you will
only be able to find symbols for Microsoft files up on that server.

However, i think your question is more general. You are saying that its not
working for any files at all. Lets talk internet connectivity, is this
machine behind a firewall(try setting _NT_SYMBOL_PROXY)? Does it require
authentication (try !sym prompts)? What kind of output are you getting
from !sym noisy? Are you using the latest debugger download?

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

--------------------
From: "Andrew" <and...@fredlewis.com>
Subject: symbol problems
Date: Tue, 4 Nov 2003 09:36:35 -0500

[Del Fredricks]

Yes, it would be nice to find a single stop shop for all symbols. However,
with that not being the case, it would be great if we could access the
version information for say a driver so that we could get the correct
symbols and even source level debugging. This is especially true for the
Windows Error Reporting (WER) where we have mini-dumps being collected, but
could really use a way of identifying what driver is running so that we can
obtain symbols and source for that driver and effectively troubleshoot the
report.

It's not really clear to me, but WinDbg does compare symbol files to the
drivers and knows if they are even one compilation apart. This results in a
rejection of the symbols. This appears to be based upon checksums or some
other sort of information because like I said, I can have a driver which has
been locally recompiled, with no version stamp change, get the newer symbol
file rejected.

Is there a means of obtaining the version stamped in the resource file
associated with the driver so that at least from the WER dumps that we can
identify which version of a driver is running and thus be able to
troubleshoot the dump?

"Ben McDonald [MSFT]" <benj...@online.microsoft.com> wrote in message
news:qPyYsL6o...@cpmsftngxa06.phx.gbl...

[Andre Vachon [MS]]

the version number in the version resource is not unique (it relies on a
human being updating the file each time) so we don't use that.
We use the timestamp of the image, which is embedded in the image by the
linker when the image is created. Each time you recompile\relink an image,
the timestamp is updated.

link -dump -headers <image>

shows you the timestamp (it's about 5 lines from the top).

When you do !drivers or lm in the debugger, that is the timestamp that is
diplayed.

-Andre

"Del Fredricks" <im.sick...@ask.i.might.tell> wrote in message
news:u6bIZgUq...@TK2MSFTNGP11.phx.gbl...