Handling rude application aborts in .NET

Question

I know I'm opening myself to a royal flaming by even asking this, but I thought I would see if StackOverflow has any solutions to a problem that I'm having...

I have a C# application that is failing at a client site in a way that I am unable to reproduce locally. Unfortunately, it is very difficult (impossible) for me to get any information that at all helps in isolating the source of the problem.

I have in place a rather extensive error monitoring framework which is watching for unhandled exceptions in all the usual places:

• Backstop exception handler in threads I control
• Application.ThreadException for WinForms exceptions
• AppDomain.CurrentDomain.UnhandledException

Which logs detailed information in a place where I have access to them.

This has been very useful in the past to identify issues in production code, but has not been giving me any information at about the current series of issues.

My best guess is that the core issue is one of the "rude" exception types (thread abort, out of memory, stack overflow, access violation, etc.) that are escalating to a rude shutdown that are ripping down the process before I have a chance to see what is going on.

Is there anything that I can be doing to snapshot information as my process is crashing that would be useful? Ideally, I would be able to write out my custom log format, but I would be happy if I could have a reliable way of ensuring that a crash dump is written somewhere.

I was hoping that I could implement class deriving from CriticalFinalizerObject and have it spit a last-chance error log out when it is disposing, but that doesn't seem to be triggered in the StackOverflow scenario which I tested.

I am unable to use Windows Error Reporting and friends due to the lack of a code signing certificate.

I'm not trying to "recover" from arbitrary exceptions, I'm just trying to make a note of what went wrong on the way down.

Any ideas?

Answer 1

You could try creating a minidump file. This is a C++ API, but it should be possible to write a small C++ program that starts your application keeps a handle to the process, waits on the process handle, and then uses the process handle to create a minidump when the application dies.

Answer 2

If you have done what you claim:

• Try-Catch on the Application.Run
• Unhandled Domain Exceptions
• Unhandled Thread Exceptions
• Try Catch handlers in all threads

Then you would have caught the exception except perhaps if it is being thrown by a third party or COM component.

You certainly haven't given enough information.

• What events does the client say leads up to the exception?
• What COM or third party components do you use? (Do you properly instance and reference these components? Do you pass valid arguments to COM function calls?)
• Do you make use of any un-managed - un-safe code?
• Are you positive that you have all throw-capable calls covered with try-catch?

I'm just saying that no-one can offer you any helpful advice unless you post a heck of lot more information and even at that we probably can only speculate as to the source of you problem.

Have a set of fresh eyes look at your code.

Some errors cannot be caught by logging.

See this similar question for more details:

http://stackoverflow.com/questions/107735/stackoverflowexception-in-net

Here's a link explaining asynchronous exceptions (and why you can't recover from them):

http://www.bluebytesoftware.com/blog/PermaLink.aspx?guid=c1898a31-a0aa-40af-871c-7847d98f1641