views:

429

answers:

3

We occasionally get a dr watson crash dialog on process exit. The process is .NET 2.0. The dialog is not very helpful. It says that the process stopped working and in the details I can see that it was about System.NullReferenceException, great but where is the traceback?

Normally when there is an error in .net process a traceback is printed to the standard error. But not in this case, probably because of the process exiting. Could anyone give me pointers on how to get more information about the cause of the crash when this dialog has appeared?

A: 

Attach using WinDBG. In all likelihood the exception is being raised in un-managed code.

Will Charczuk
even though it says System.NullPointerException?
luntain
that was from experience; when w3wp crashes outside the process request call (i.e without managed exception handling) dr watson usually takes over and creates a dump (this, like smacl mentioned, depends on machine config). windbg is just a better debugger in general than visual studio though.
Will Charczuk
A: 

If the crash is reproducible, it might be worth setting the debugger to break on all exceptions (perhaps both native and CLR) before you shut down the application. Often a crash can be due to an earlier error so this might give you a clue.

Have you looked into the Dr Watson dump files? These should normally tell you at least which module has caused the problem. If you were dealing with native code you would be able to load the minidump file provided by Dr Watson into Visual Studio, and providing you have debug symbol files and source code on that machine you'd be able to see the state of your application at the time of the crash, call stack of the offending thread, and line of code that was causing the crash. I have no idea what happens with managed code, but it might be worth trying out.

This link should give you some more information about analysing minidump files Link to CodeProject

John Sibly
where do I find this minidump?
luntain
They are generally created around the time you click send error report to Microsoft. There should be the option to view the files it is about to send, one of which should have the .dmp extension. Copy this file somewhere else as I think it gets deleted automatically after the results are sent to MS
John Sibly
Could also be *.mdmp This link gives some information about analysing minidumps: http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx#_Creating_a_Minidump
John Sibly
+1  A: 

I tend to disable Dr Watson on dev machines and use Visual Studio as the just it time debugger that gets fired up when an application bombs. I find this way more useful in terms of root cause analysis, particularly if you have debugging information available.

Shane MacLaughlin