How do I triage a bugcheck from a non debug driver. All I see from the stack
is the name of the driver + offset. I m guessing these are offsets from the
base load address of my image. Question is how do I look up this information
in a MAP file. Whats the best a MAP file can do? Just provide the nearest
function (symbol) at that location or is source level information possible
as well.
thanks
banks
The MAP file is just a plain text list of symbols and offsets, perhaps with
some other info depending on what generated it and how. You can use it to
walk your stack by hand, or you can use a tool like Ken Johnson’s SDbgExt
debugger extension (http://www.nynaeve.net/index.php?paged=2) to parse the
file into something WinDbg can use.
-sd
On 7/19/06 1:25 AM, “bank kus” wrote:
> How do I triage a bugcheck from a non debug driver. All I see from the stack
> is the name of the driver + offset. I m guessing these are offsets from the
> base load address of my image. Question is how do I look up this information
> in a MAP file. Whats the best a MAP file can do? Just provide the nearest
> function (symbol) at that location or is source level information possible
> as well.
>
> thanks
> banks
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@positivenetworks.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Bank,
This is not directly responsive to your question, and it might be
obvious to you already, but in case not: Long term, instead of using
a map file, the thing to do is to build symbols files (.pdb) for your
free drivers, in addition to building them for your checked
drivers. This will give you source level information just as in a
checked build.
Note that an optimized free build will behave somewhat unexpectedly
at times while debugging, because the optimizer will rearrange
program flow and may optimize away some local variables.
Best regards,
David
At 11:25 PM 7/18/2006 -0700, bank kus wrote:
How do I triage a bugcheck from a non debug driver. All I see from the stack
is the name of the driver + offset. I m guessing these are offsets from the
base load address of my image. Question is how do I look up this information
in a MAP file. Whats the best a MAP file can do? Just provide the nearest
function (symbol) at that location or is source level information possible
as well.
Well actually this has always been a source of confusion for me and I dont
see any good tutorial to demystify this.
So there are 4 players in the debug game:
<1> function names ( name vs address )
<2> FPO information
<3> source + line information
<4> variable information ( type information )
This much I get from MSDN.
On the other hand there is a compiler switch /Zi and /Zd and the doc says
that /Zd will only place line information into the .obj file. With /Zd no
pdb file
can be created . (I m not even talking of map files here !) /Zi seems be
debug info replete. There is link.exe which takes /debug flag.
Now can somebody explain how these different flags map to the above 4
factors. My understanding is that a release pdb is
cl /Zd and then finally link /debug /pdb:name.pdb. So now you have 1, 2 and
3 but no 4. I have an uneasy understanding of this idea can somebody
correct me or tie this whole thing together.
thanks
banks
“David Markun” wrote in message news:xxxxx@windbg…
> Bank,
>
> This is not directly responsive to your question, and it might be obvious
> to you already, but in case not: Long term, instead of using a map file,
> the thing to do is to build symbols files (.pdb) for your free drivers, in
> addition to building them for your checked drivers. This will give you
> source level information just as in a checked build.
>
> Note that an optimized free build will behave somewhat unexpectedly at
> times while debugging, because the optimizer will rearrange program flow
> and may optimize away some local variables.
>
> Best regards,
> David
>
> At 11:25 PM 7/18/2006 -0700, bank kus wrote:
>>How do I triage a bugcheck from a non debug driver. All I see from the
>>stack
>>is the name of the driver + offset. I m guessing these are offsets from
>>the
>>base load address of my image. Question is how do I look up this
>>information
>>in a MAP file. Whats the best a MAP file can do? Just provide the nearest
>>function (symbol) at that location or is source level information possible
>>as well.
>
“bank kus” wrote:
> Well actually this has always been a source of confusion for me and I dont
> see any good tutorial to demystify this.
>
> So there are 4 players in the debug game:
> <1> function names ( name vs address )
> <2> FPO information
> <3> source + line information
> <4> variable information ( type information )
>
> This much I get from MSDN.
>
> On the other hand there is a compiler switch /Zi and /Zd and the doc says
> that /Zd will only place line information into the .obj file. With /Zd no
> pdb file can be created . (I m not even talking of map files here !) /Zi
> seems be debug info replete. There is link.exe which takes /debug flag.
>
> Now can somebody explain how these different flags map to the above 4
> factors. My understanding is that a release pdb is
> cl /Zd and then finally link /debug /pdb:name.pdb. So now you have 1, 2 and
> 3 but no 4. I have an uneasy understanding of this idea can somebody
> correct me or tie this whole thing together.
Dated but relevant reference I usually start with, and was very
helpful originally when read from start to end:
Generating and Deploying Debug Symbols with Microsoft Visual C++ 6.0
http://msdn.microsoft.com/library/en-us/dnvc60/html/gendepdebug.asp
In short, compile including /Zi so all debug information the compiler
can provide will be generated. Link including /DEBUG /DEBUGTYPE:CV
/PDB:filename so the debug information goes into the PDB only.
This is regardless of whether you’re creating a checked build or a
free build of the code; the choice of checked or free affects other
switches such as optimizations and pre-processor definitions, but not
the choice of “do I want symbol information for the code built”. You
always want it, and you always want the maximum amount of it, for the
code that was generated.
Symbols certainly will not be as completely helpful from a free build
that has optimizations enabled, since things start being executed more
obscurely and “out of order”. Since you want code that is
shipped/released to perform, you’ll usually leave optimizations
enabled. But you always want to have symbol information for the code
shipped/released, regardless of whether it was optimized or not.
Alan Adams
Banks,
The top three hits on Google for “build pdb for free
driver” all look good. The one on osronline.com
www.osronline.com/article.cfm?id=
68 especially.
-David
At 11:53 PM 7/19/2006 -0700, you wrote:
Well actually this has always
been a source of confusion for me and I dontsee any good tutorial to demystify this.
or you could check out Crashfinder.exe
Alan Adams wrote: “bank kus” wrote:
> Well actually this has always been a source of confusion for me and I dont
> see any good tutorial to demystify this.
>
> So there are 4 players in the debug game:
> <1> function names ( name vs address )
> <2> FPO information
> <3> source + line information
> <4> variable information ( type information )
>
> This much I get from MSDN.
>
> On the other hand there is a compiler switch /Zi and /Zd and the doc says
> that /Zd will only place line information into the .obj file. With /Zd no
> pdb file can be created . (I m not even talking of map files here !) /Zi
> seems be debug info replete. There is link.exe which takes /debug flag.
>
> Now can somebody explain how these different flags map to the above 4
> factors. My understanding is that a release pdb is
> cl /Zd and then finally link /debug /pdb:name.pdb. So now you have 1, 2 and
> 3 but no 4. I have an uneasy understanding of this idea can somebody
> correct me or tie this whole thing together.
Dated but relevant reference I usually start with, and was very
helpful originally when read from start to end:
Generating and Deploying Debug Symbols with Microsoft Visual C++ 6.0
http://msdn.microsoft.com/library/en-us/dnvc60/html/gendepdebug.asp
In short, compile including /Zi so all debug information the compiler
can provide will be generated. Link including /DEBUG /DEBUGTYPE:CV
/PDB:filename so the debug information goes into the PDB only.
This is regardless of whether you’re creating a checked build or a
free build of the code; the choice of checked or free affects other
switches such as optimizations and pre-processor definitions, but not
the choice of “do I want symbol information for the code built”. You
always want it, and you always want the maximum amount of it, for the
code that was generated.
Symbols certainly will not be as completely helpful from a free build
that has optimizations enabled, since things start being executed more
obscurely and “out of order”. Since you want code that is
shipped/released to perform, you’ll usually leave optimizations
enabled. But you always want to have symbol information for the code
shipped/released, regardless of whether it was optimized or not.
Alan Adams
—
You are currently subscribed to windbg as: xxxxx@yahoo.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
All new Yahoo! Mail “The new Interface is stunning in its simplicity and ease of use.” - PC Magazine