5YrsLaterDBA
5YrsLaterDBA

Reputation: 34820

how to avoid windows crash screen

We have UnhandledExceptionEventHandler in place and unexpected exceptions were caught by that handler. But why we still see the following screen? I thought if we handled the exception, it will not go up to the OS. If no exception reach the system level, why that screen still show up?

enter image description here

Upvotes: 2

Views: 1025

Answers (4)

user530189
user530189

Reputation:

Registering an UnhandledExceptionEventHandler with AppDomain.UnhandledException does not mean that unhandled exceptions become handled. Instead, it is a mechanism to be able to log the exception and relevant program state to aid in later debugging. The exception will remain unhandled and Windows Error Reporting will be invoked.

In reality, when this event is invoked it's "too late" for the the exception to be handled. Assuming you could tell the runtime to continue execution, where would execution unwind to? Not a single frame on the call stack wanted to handle the exception. At best, the executing thread could be terminated; but what if it's on the only foreground thread? Better to propagate the unhandled exception to the operating system's default unhandled exception filter and let it invoke Windows Error Reporting.

Edit with some additional comments:
Now, certain applications you want to design to be crash-resistant, such as long-running service processes. It may make sense to add "catch-all"* exception handlers in some cases, such as a job queue that executes jobs and it doesn't matter if an individual job fails with an unhandled exception; we log the problem and move on to the next job. However, a root catch-all handler in something like Main makes little sense: your entire application is now in an unknown state. You could log the exception and terminate, but you'd be missing out on the benefits of Windows Error Reporting: post-mortem minidumps and an easy button (the "Debug" button on that dialog) to invoke the registered JIT debugger that will take you directly to the problem. For most software, my advice is to simply let your software crash; in-your-face bugs with minidumps are usually some of the easiest to fix.

*Some exceptions are inherently "uncatchable", such as a StackOverflowException. Others, such as an AccessViolationException are catchable, but are inherently indicative of a serious program state incongruity (couldn't read or write from an expected memory location). It is never a good idea to attempt recovery from such exceptions.

Upvotes: 7

Maxim Gueivandov
Maxim Gueivandov

Reputation: 2385

That's because your unhandled exception occurs in the main thread, and there is almost nothing to do about it. Check this article: What!? A .NET Application Can Die?

Almost nothing, yes, because you can still catch that exception on the Application.Run level. At this point your application is dead anyway, but at least you can "avoid windows crash screen" and implement your own crash screen instead:

    static void Main()
    {
        try
        {
            Application.Run(new Form1());
        }
        catch (Exception ex)
        {
            MessageBox.Show("Oops! Can I has " + ex.Message + "?");
        }
    }

Upvotes: 1

Tomas Voracek
Tomas Voracek

Reputation: 5914

There are cases when unhadled exceptions will not be handled by UnhandledExceptionEventHandler. For example System.Timers.Timer is swallowing exceptions, so they are not propagated to UnhandledExceptionEventHandler.

Upvotes: 0

Patrick
Patrick

Reputation: 23629

Click the Debug button to see where the exception comes from.

If you don't see it immediately, start your application in Visual Studio, go to the Debug,Exceptions dialog, and check all exceptions. Then rerun your application, investigate the code every time the debugger tells you that a first-chance exception has been encountered, and pass the exception to the application if Visual Studio asks you whether to do this.

This should help you finding the source of the problem.

Upvotes: 1

Related Questions