Process crash info
Bob Altman
I'm looking for a way to get some insight into why a program is crashing. When
the program dies, it simply disappears from the system leaving no trace of what
its problem was. I've figured out (thanks to help from another newsgroup) how
to install Dr. Watson, so now I can get its cryptic log and an associated
process dump file, but I'm hoping that I can wire up something a little more,
uh, "user friendly".
I wrote a simple test program that calls routine X which calls routine Y which
divides by zero, and used that program to play around with Dr. Watson.
There are a couple of problems with the way I have things set up now. For
starters, the stack dump in the Dr. Watson log file doesn't give me line
numbers, making it really tough to figure out where in my source code the
problem is. (Yes, there is a pdb file in the same folder as the failing exe
file.)
What other options might I have for logging fatal program errors in a format
that non-system programmers can easily decode?
Kellie Fitton
Hi,
You can use the following APIs to create a minidump file:
//* Load the library file DBGHELP.DLL *//
GetModuleFileName()
LoadLibraryEx() "dbghelp.dll"
//* Work out a place for the dump file *//
char szDumpPath[_MAX_PATH];
char szTempFile[_MAX_PATH];
GetTempPath() szDumpPath
GetTempFileName() szTempFile
//* Create the dump file *//
CreateFile() szDumpPath,
FILE_ATTRIBUTE_NORMAL | FILE_FLAG_WRITE_THROUGH,
//* Write the dump file *//
MINIDUMP_EXCEPTION_INFORMATION eInfo;
eInfo.ThreadId = GetCurrentThreadId();
eInfo.ExceptionPointers = p_ExceptionInfo;
eInfo.ClientPointers = FALSE;
GetCurrentProcess()
GetCurrentProcessId()
MiniDumpWriteDump(hProcess,
ProcessId,
hFile,
MiniDumpNormal,
&eInfo
NULL,
NULL);
CloseHandle(hFile);
http://msdn.microsoft.com/en-us/library/ms683197(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms684179(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa364992(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa364991(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms683183(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms683179(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms683180(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms680360(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms724211(VS.85).aspx
Kellie.
Waleri Todorov
You can open this file with Visual Studio and it will take you to the crash location. Usually, pdb file is used automaticaly.
"Bob Altman" <r...@nospam.nospam> wrote in message news:esiy4Kxq...@TK2MSFTNGP03.phx.gbl...
Jeffrey Tan[MSFT]
For security reason, the source code line information is not contained in
the application Exe/Dll files, so when the application crashes the
debugger(drwtsn32 in this scenario) has no way of knowing which source code
line should be associated with the crash address.
To help debugging, these source code mapping and other source code
symbolic/type information are stripped by the compiler/linker and stored in
a separate symbol files -- .PDB files. So we need the PDB symbol files to
get the source code<--->binary address mapping information(That is mapping
a stack function to its source code line).
As other community members pointed out, a simple way is using a debugger
like windbg to open the crash dump generated by drwtsn32. Once we set the
symbol file path to the debugger, it will show the stack trace with the
matching source code line for us. I have written a basic tutorial of
setting up windbg to debug crash in the link below:
"How to debug application crash/hang in production environment?"
http://blogs.msdn.com/msdnts/archive/2006/11/24/how-to-debug-application-cra
sh-hang-in-production-environment.aspx
For non-experienced windbg users, you may simply input "!analyze -v"
command in the windbg. This automation command will dump a detailed report
including stack trace, source code, and exception information for us which
is very convenient. Sure, you must set the symbol path and source file path
correctly.
If you need more information or help, please feel free to tell me, thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Jochen Kalmbach [MVP]
> As other community members pointed out, a simple way is using a debugger
> like windbg to open the crash dump generated by drwtsn32. Once we set the
> symbol file path to the debugger, it will show the stack trace with the
> matching source code line for us.
Of course, this is only true for native-only apps...
For native apps with managed components only the native lines can be
displayed...
Maybe the CLR-team can be blamed for this "bug"... hopefully they will
update sos to enable source-line infos...
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Jeffrey Tan[MSFT]
As I tested, the windbg build-in commands(k*) will show the source line
information for managed methods frame as long as you have the private
symbol. While the SOS extension stack trace commands will not show source
line information by intention because some people believe source
information is distracting.
Anyway, if you really want to get source line information, using "k*"
commands should be good. For individual frame, we can use `ln` to report
the source line information on the addresses. And those addresses are easy
enough to get from !clrstack.
Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
Jochen Kalmbach [MVP]
> As I tested, the windbg build-in commands(k*) will show the source line
> information for managed methods frame as long as you have the private
> symbol.
WHat version doyou have? The official answer from WinDbg team is: this
is not possible. It was a mistake that it had worked in version
6.7.5.0! So please use the current version of WinDbg!
Or show me, how you had done this! I was not able to get this to work...
> While the SOS extension stack trace commands will not show source
> line information by intention because some people believe source
> information is distracting.
!?
> Anyway, if you really want to get source line information, using "k*"
> commands should be good.
What did you do?
I am not able to repro this with the current WinDbg version...
Jeffrey Tan[MSFT]
Oh, sorry, I am using the internal version of windbg.
I just downloaded and installed the latest public version(6.9.3.113):
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
However, it seems that I can still get the source code information from the
"k*" commands once I got the private symbol files for the .Net assemblies.
Note: Microsoft public symbol server only contains the public symbol files.
So I assume the latest public version of windbg also supports source line
information for managed methods now. Thanks.
Jeffrey Tan[MSFT]
Oh, sorry, please ignore on my last reply to you. I am not authorized to
provide the offiicial answer about windbg, it is just my test information.
Windbg team is investigating for this issue now, I think they may provide
the official answer in future.
Jochen Kalmbach [MVP]
> I just downloaded and installed the latest public version(6.9.3.113):
> http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
I did not know about this new version... sorry I will try...
Jochen Kalmbach [MVP]
> Oh, sorry, please ignore on my last reply to you. I am not authorized to
> provide the offiicial answer about windbg, it is just my test information.
> Windbg team is investigating for this issue now, I think they may provide
> the official answer in future.
I don't know what you did... but from my testing it does not work....
(small app which throws an null-pointer exception):
Here is the output from v6.9.3.113:
0:000> .ecxr
Unable to get exception context, HRESULT 0x8000FFFF
0:000> k
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012f490 79e7c6cc 0xd600cc
0012f510 79e7c8e1 mscorwks!CallDescrWorkerWithHandler+0xa3
0012f64c 79e7c783 mscorwks!MethodDesc::CallDescr+0x19c
Output from v6.7.5.0:
0:000> .ecxr
Unable to get exception context, HRESULT 0x8000FFFF
0:000> k
ChildEBP RetAddr
0012f490 00d60095
ConsoleApplication_2008!ConsoleApplication_2008.Program.Test1()+0x1c
[F:\Test\ConsoleApplication_2008\Program.cs @ 13]
0012f490 79e7c74b
ConsoleApplication_2008!ConsoleApplication_2008.Program.Main(System.String[])+0x25
[F:\Test\ConsoleApplication_2008\Program.cs @ 18]
0012f490 79e7c6cc mscorwks!CallDescrWorker+0x33
0012f510 79e7c8e1 mscorwks!CallDescrWorkerWithHandler+0xa3
Bob Altman
> You can open this file with Visual Studio and it will take you to the crash
> location.
Ok, I've got a user.dmp file. When I double-click on it Visual Studio opens it
and shows me a blank screen. Now what? How do I tell VS to associate the
user.dmp file with an exe and pdb file (and, ultimately, with source code)?
Bob
Ben Voigt [C++ MVP]
You should put the .pdb in the same directory with the dump. The exe and
dlls aren't strictly necessary, I don't think.
After you open the dump in VS, use the Debug Window to open the Threads
list, Call Stack, etc. When you double-click a stack frame for any thread,
it should try to take you to the source code. If it can't find the source
code it may prompt you.
Also pay attention to the output window, it will tell you for each module
loaded whether it found a matching debug database, public symbols, or
nothing.
>
> Bob
Jochen Kalmbach [MVP]
> After you open the dump in VS, use the Debug Window to open the Threads
> list, Call Stack, etc.
You first need to press "Go" (F5, F10 or F11) to "activate" the dump...
Bob Altman
Ahhh... that's the magic. Thanks!