how to avoid windows crash screen

Question

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?

Answer 1

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.

Answer 2

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.