Beginner's questions

[OvErboRed]

Hi, I have a few small kernel memory dumps that were generated into %
systemroot%\minidumps after Win XP Pro restarted because of driver
issues. I would like to learn how to use windbg (or perhaps VS.NET, if
possible) to analyze system crashes, and in this case, find out what the
exact problem is from a different machine (the problem is actually
because of the ATI video driver). I'm not going to be debugging, just
determining the cause of these crashes. However, I ran into the
following problem, which seems to have been mentioned many times before
on these newsgroups, but for which I couldn't find a straight answer:

*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for
ntoskrnl.exe

My symbol search path is: "srv*C:
\images*http://msdl.microsoft.com/download/symbols"

My image search path is: "C:\windows\system32" **

I've put up the actual minidump at http://overbored.net/minidumps.zip. I
would appreciate any help with this issue. But I also have some general
questions:

- After reading the windbg documentation, I'm wondering how the minidump
specifies the exact file to use; does it have a hash, or does it just
have the filename and timestamp? Where might I find more information
about details like this?

- I've read the windbg documentation, various MSKB articles, and a few
newsgroup articles, but I still feel a bit lost. Can anyone point me to
some primer(s) that explain dumps, symbols, images, etc.? Maybe with
examples?

** The computer I'm running windbg on is not the same as the one that
crashes, so I'm guessing this won't work, but I don't think it's causing
the problem I'm currently having...or is it? Should I set it to the C:
\Windows directory on the crashing computer? or the I386 installation
CD? Also, according to previous posts, the images as well as the symbols
for XP and later are available on Microsoft's public server. What's the
URL to the former?

Thanks!

 

[Pat [MSFT]]

For a mini-dump you need to also set your image file path (under the File
menu) to point to the binaries that are in the mini-dump.

Also, since you are just starting out, use the !analyze -v <enter> command
to give you an initial review.

Pat

 

[Microsoft Video Driver OCA Triage]

You should also try the new ATI Cat. 4.1 from the following location and see
if that addresses your issue.
http://www.ati.com/support/drivers/...prod=productsXPdriver&submit.x=17&submit.y=13
Thanks,
Aaron C. Smith
Microsoft Video Driver OCA Triage
(e-mail address removed)
* This posting is provided "AS IS" with no warranties, and confers no
rights.

 

[Calvin Guan]

(the problem is actually because of the ATI video driver).

Hello,

Can you generate a full memory dump and make it available somewhere on the
net? What model of ATI card are you using? How to repro it?

Thanks,
Calvin

 

[OvErboRed]

For a mini-dump you need to also set your image file path (under the
File menu) to point to the binaries that are in the mini-dump.

Right, but my problem was that I don't know where to point to for
images:

Also, since you are just starting out, use the !analyze -v <enter>
command to give you an initial review.

The problem is that when I enter that, I see more of these errors.
You'll find all the output, small memory dumps, and whatnot available at
http://overbored.net/dumps/.

I guess another question I have is if it's possible to analyze these
Small Memory Dumps without getting access to the machine or its images,
a la MS Error Reporting. My main goal is to learn how to analyze these
memory dumps. I'm not going to be debugging anything, just figuring out
what's causing the crashes (which I already know to be the ATI drivers).
If for some reason I still need images for this purpose, then I'll
accept that and generate larger dumps, but I'd prefer lower bandwidth
solutions. And if images are needed, is there a way for me to determine
what files (name, version, etc.) I need?

Thanks.

 

[OvErboRed]

Haha, well that leads to another question: I'm wondering if it's
possible to analyze these Small Memory Dumps without getting access to
the machine or its images, a la MS Error Reporting. My main goal is to
learn how to analyze these memory dumps. I'm not going to be debugging
anything, just figuring out what's causing the crashes (which I already
know to be the ATI drivers). If for some reason I still need images for
this purpose, then I'll accept that and generate larger dumps, but I'd
prefer lower bandwidth solutions. And if images are needed, is there a
way for me to determine what files (name, version, etc.) I need? It
would be great if you have some answers about this, or my original
questions.

However, it would be nice to fix this driver issues too, so...what
constitutes a "full memory dump"? The Complete or the Kernel? I will try
to make these available soon. I think the ATI card is a Mobility 7500.
I'm not sure how to reproduce the problem, but I think the user said
it's random. You'll find all the output, small memory dumps, and whatnot
available at http://overbored.net/dumps/.

Thanks!

 

[Pat [MSFT]]

Mini-dumps lack some info (specificall the header info found in the
binaries) that help w/symbol resolution. To get the images, you can set
your image path to the location of the actual binaries (i.e. on the machine
that crashed) or (I think for WinXP and later) point it to the symbol server
and get the binaries that way. Either way, mini-dumps will have only their
stack information.

Pat

 

[OvErboRed]

Mini-dumps lack some info (specificall the header info found in the
binaries) that help w/symbol resolution. To get the images, you can
set your image path to the location of the actual binaries (i.e. on
the machine that crashed) or (I think for WinXP and later) point it to
the symbol server and get the binaries that way. Either way,
mini-dumps will have only their stack information.

Pat

Hmm...I'd already tried setting the image path to the same thing as the
symbol path, but it still hasn't gotten past the error I'm getting (see
http://www.overbored.net/dumps/windbg_output.txt). I'm not sure if it makes
sense for me to set the image path to be:

srv*c:\images*http://msdl.microsoft.com/download/symbols

In any case, it doesn't look like it's even gotten past symbol resolution.
Got any hints?

 

[Calvin Guan]

As Pat said, minidumps lack of information to do post-mortem analyzing. A
"complete memory dump" would be much better. Life debugging is way efficient
if possible.

Thanks,
Calvin

 

[Pat [MSFT]]

Can you run it on the original workstation and see if the symbols resolve?

 

[OvErboRed]

I can try that, but symbols aren't found in binaries, right? (The system
doesn't run a debug/checked version of Windows.) Also, what might be
preventing me from downloading the symbols/images from Microsoft's public
server (is it something I can fix)?

 

[OvErboRed]

I'll try to get ahold of a complete memory dump, then.

Again, I'm not interested in debugging, just failure analysis. If I have
all the computers error-reporting to the server with complete memory dumps,
our network would be very congested. Also, what's life debugging?

 

[Calvin Guan]

our network would be very congested. Also, what's life debugging?
Oops, I meant live-debugging. Live-debugging means debugging a running
target.

Calvin Guan Software Engineer
ATi Technologies Inc. (905) 882-2600x8654

 

[Pat [MSFT]]

The symbols are separate files, but there is information in the binary that
helps identify the correct symbol. A symbol is build specific, so we need
to pull the checksum out of the binary to identify the correct symbol.

Pat

 

[Andre Vachon [MS]]

start the debugger with -n (stands for "noisy") . That will give you more
information about the image and symbol load operations, and might give you
an idea why ntoskrnl.exe is failing to be loaded by the debugger. The image
ntoskrnl.exe should be in the symbol server.

-Andre