Cannot read .dmp log. Symbols not loading.

I am currently trying to read a .dmp file for a crash we had a couple days ago. I'm running a Dell Poweredge 2950, Windows Server 2003 R2 SP 1. Every time I try to read the file it tells me "Unable to load image \Windows\system32\ntkrnlpa.exe, Win32 error 0n2"

Then it tells me that I don't have the correct symbols loaded.

I am using this path to open windows debugger, "windbg -y c:\windows\symbols -i c:\i386 -z c:windows\minidump\mini092409-01.dmp"

I have tried using the following symbol files with no luck.
Who is Participating?

Try the following:

Open Windbg from the Start menu programs shortcut

Goto File menu and Symbol file path and input there the symbolf file path for the symbols you have downloaded.

Goto File menu open crash dump and open the minidump.

What is the result?

Because i am guessing that as you are specifing the -i switch pointing to i386 and the kernel image there is diffrent from the one actually running it fails.

This way the debugger will look for the image on the System32 folder and should be able to find it.
Let me know how it goes...

point the debugger to

If you need help with the memory dump post the minidump file here I have symbols for it for sure.

The location is:

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

nstd-stsAuthor Commented:
Ah, I forgot to mention this is on a system with no internet access for security reasons.
You need to use Symchk then:

Copy the Windows\system32 binaries from that system into a temp forder on a system with internet access.

Then use symchk on that folder to download the symbols and bild the symbol cache that you will then use with the debugger by setting the debugger symbol path to that symbol cache folder.

Using the SymChk.exe utility to download symbols
You can use the SymChk.exe utility to verify symbols and to build a local symbol cache in a convenient, noninvasive way. The SymChk.exe utility is included with the Debugging Tools for Windows package. SymChk.exe is a command-line tool. You may want to add the folder of the Debugging Tools for Windows package to the PATH environment variable on your system so that you can access this tool easily from any command prompt.

To use the SymChk.exe utility to download symbol files for all of the components in the Windows\System32 folder, use the following command-line command:

symchk /r c:\windows\system32 /s SRV*c:\symbols\*

In this example: " /r c:\windows\system32 finds all symbols for files in the System32 folder and any subfolders.

" /s SRV*c:\symbols* specifies the symbol path to use for symbol resolution. In this case, c:\symbols is the local folder where the symbols will be copied from the symbol server.

To obtain more information about the command-line options for SymChk.exe, type symchk /? at a command prompt. Other options include the ability to specify the name or the process ID (PID) of an executable file that is running.

nstd-stsAuthor Commented:
That sounds like it would be a pretty good solution. However the problem is I can't copy any information from this system to one with an internet connection due to the fact that this system is classified and copying anything from it to an unclass system is not going to happen. Blarg!!! All I want to do is look at this log file and see why the system crashed!!!!!!!!!

Any other ideas?
And that includes the memory dump it self right ?

Then you can try Remote Debugging if you can connect to that server internaly from a workstation:

Remote Debugging
Doing remote debugging using WinDbg is easy and can be done in one of a number of ways. In the following, debugging server is the debugger running on the machine where youd like to debug; debugging client is the debugger controlling the session.

Using the debugger: You need CDB, NTSD or WinDbg on the server. A WinDbg client can connect to any of CDB, NTSD and WinDbg, and vice versa. The server and client have choices of TCP and named pipes for communication protocol.
To start a server:
WinDbg server npipe:pipe=pipename (note: multiple clients can connect), or
from within WinDbg: .server npipe:pipe=pipename (note: single client can connect)
You can start multiple server sessions using multiple protocols. You can password-protect a session.

To connect from a client:
WinDbg -remote npipe:server=Server, pipe=PipeName[,password=Password]
from within WinDbg: File->Connect to Remote Session: for connection string, enter npipe:server=Server, pipe=PipeName [,password=Password]
Using remote.exe: remote.exe uses named pipes for communicating. If you use a console-based application like KD, CDB or NTSD, you could use remote.exe to do remote debugging. Note: use @q (not q) to quit the client without quitting the server.
To start a server:
Remote.exe /s cdb p <pid> test1
To connect from a client:
Remote.exe /c <machinename> test1
test1 above is the arbitrary named pipe name we chose.

Server will display who all are connected from which servers and commands executed. You can quit the server by issuing qq; or quit the client using File->Exit. Youd need to belong to the Debugger Users user group and the server has to allow remote connectivity if you want to remote-debug.

Post the version of the missing symbol and the exact binary name. Maybe I can retrive it from the public cache.
nstd-stsAuthor Commented:
How would I find the missing symbol and binary name? This is the first time I've ever had to deal with this stuff.
A side note...

A minidump file does not contain as much information as a full crash dump file, but it contains enough information to perform basic debugging operations. To read a minidump file, you must have the binaries and symbol files available for the debugger. The binaries are the binaries from the system that actually created that minidump and obviously the binaries that were in execution at that point in time.

nstd-stsAuthor Commented:
In the end I was able to open it straight from the debug program without using all the command line stuff. Looks like a driver issue that can be fixed with either a hotfix or installing SP2.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.