Symbol Server can be used to find symbols for a dump and works the exact
same as live debugging.
It also suffers from the same restriction as live debugging. Which is
that the info needed to do a symbol server lookup is in the image
header. If that header is paged out then the debugger has no idea what
symbol to get. So symbol server does not work in that scenerio.
When using a traditional sympath sometimes (depending on the exact
scenerio) the debugger will load the symbol in the dir on the assumption
that it is right. This is what the “unknown sig” message means. That
the debugger loaded a symbol because it was there, but has no clue if it
is the right symbol or not because the verification info is in the
header which is paged out.
As described in the docs “Reading Symbols from Paged-Out Headers”
article you can have the debugger use the image header from a binary
that you provide when the header on the target system is unavailable.
If you provide a header in this way then symbol server will work for the
symbol lookup as now the debugger has the info it needs for the symbol
lookup.
However, it still isn’t working exactly like I would think it should.
For
example, I can place my PDB file in a symbol server, but I have to have
the
associated SYS file in the symbol path. What I would like to do is
just
have a dump and point it at the symbol server and never worry about the
binaries/symbols. Is this possible?
As long as the headers are paged in then yes it is possible and
works great. I do this daily.
Also, there is a NT registry setting called DisablePagingExecutive. I
tried
that thinking that I could force the headers to remain paged-in, but it
still didn’t work.
I know of no way to tell the system not to page out image
headers.
What is the relationship between the SYS file, the PDB file, and the
data
contained in the dump (i.e. the header for the SYS)?
That is a big question so I don’t know where to start.
-----Original Message-----
From: xxxxx@emc.com [mailto:xxxxx@emc.com]
Sent: Friday, April 27, 2001 9:36 AM
To: Kernel Debugging Interest List
Subject: [windbg] Does the SymSrv work dumps when you don’t have
binaries?
We have a product that uses several kernel drivers and user space
applications on NT 4.0. I think our environment lends itself well to
the
Symbol Server feature of Windbg to analyze kernel dumps.
I’m trying to get the SymSrv feature working with our custom build
environment. There were some issues with how we constructed the PDB
files.
Previously windbg would load the symbols only as a last resort (it would
print out a message about an “unknown sig” in verbose mode). I’ve had
to
tinker with a couple of the complier / linker options (I can supply
those if
necessary).
However, it still isn’t working exactly like I would think it should.
For
example, I can place my PDB file in a symbol server, but I have to have
the
associated SYS file in the symbol path. What I would like to do is just
have a dump and point it at the symbol server and never worry about the
binaries/symbols. Is this possible?
Does the “Reading Symbols from Paged-Out Headers” article in the Windbg
help
apply to my situation at all? I have messed around with the !lmi
and !dh Windbg commands and it does appear that the debug data
directories are paged out.
Also, there is a NT registry setting called DisablePagingExecutive. I
tried
that thinking that I could force the headers to remain paged-in, but it
still didn’t work.
What is the relationship between the SYS file, the PDB file, and the
data
contained in the dump (i.e. the header for the SYS)?
Thanks,
Alan
Alan Taylor CLARiiON Advanced Development, EMC? The Enterprise Storage
Company
62 T.W. Alexander Drive, Durham, NC 27709-0023
Phone: (919) 248-6349, Tie line: 262-6349, Fax: (919) 248-5942
You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com