Nbsp;   Unhandled Exceptions

When an exception is thrown, the CLR climbs up the call stack looking for catch blocks that match the type of the exception object being thrown. If no catch block matches the thrown exception type, an unhandled exception occurs. When the CLR detects that any thread in the process has had an unhandled exception, the CLR terminates the process. An unhandled exception identifies a situation that the application didn’t anticipate and is considered to be a true bug in the application. At this point, the bug should be reported back to the company that publishes the application. Hopefully, the publisher will fix the bug and distribute a new version of the application.

Class library developers should not even think about unhandled exceptions. Only application developers need to concern themselves with unhandled exceptions, and the application should have a policy in place for dealing with unhandled exceptions. Microsoft actually recommends that applica- tion developers just accept the CLR’s default policy. That is, when an application gets an unhandled exception, Windows writes an entry to the system’s event log. You can see this entry by opening the

Event Viewer application and then looking under the Windows Logs ➔ Application node in the tree,

as shown in Figure 20-1.

FIGURE 20-1Windows Event log showing an application that terminated due to an unhandled exception.

However, you can get more interesting details about the problem by using the Windows Reliability Monitor applet. To start Reliability Monitor, open the Windows Control Panel and search for “reli- ability history”. From here, you can see the applications that have terminated due to an unhandled exception in the bottom pane, as shown in Figure 20-2.

FIGURE 20-2Reliability Monitor showing an application that terminated due to an unhandled exception.

To see more details about the terminated application, double-click a terminated application in Reliability Monitor. The details will look something like Figure 20-3 and the meaning of the problem signatures are described in Table 20-2. All unhandled exceptions produced by managed applications are placed in the CLR20r3 bucket.

FIGURE 20-3Reliability Monitor showing more details about the failed application.

TABLE 20-2Problem Signatures

* If a string is beyond the allowed limit, then some intelligent truncations are performed, like removing “Exception” from the exception type or “.dll” from a file name. If the resulting string is still too long, then the CLR will create a value by hashing or base-64–encoding the string.

After recording information about the failing application, Windows displays the message box allowing the end user to send information about the failing application to Microsoft servers.7 This is called Windows Error Reporting, and more information about it can be found at the Windows Quality website (http://WinQual.Microsoft.com).

Companies can optionally sign up with Microsoft to view this information about their own applica- tions and components. Signing up is free, but it does require that your assemblies be signed with a VeriSign ID (also called a Software Publisher’s Digital ID for Authenticode).

Naturally, you could also develop your own system for getting unhandled exception information back to you so that you can fix bugs in your code. When your application initializes, you can inform the CLR that you have a method that you want to be called whenever any thread in your application experiences an unhandled exception.

Unfortunately, every application model Microsoft produces has its own way of tapping into un- handled exceptions. The members that you want to look up in the FCL documentation are.

■ For many applications, look at System.AppDomain’s UnhandledException event. Windows Store applications and Microsoft Silverlight applications cannot access this event.

■ For a Windows Store App, look at Windows.UI.Xaml.Application’s UnhandledException

event.

■ For a Windows Forms application, look at System.Windows.Forms.NativeWindow’s OnThreadException virtual method, System.Windows.Forms.Application’s On­ ThreadException virtual method, and System.Windows.Forms.Application’s Thread­ Exception event.

■ For a Windows Presentation Foundation (WPF) application, look at System.Windows. Application’s DispatcherUnhandledException event and System.Windows. Threading.Dispatcher’s UnhandledException and UnhandledExceptionFilter events.

■ For Silverlight, look at System.Windows.Application’s UnhandledException event.

■ For an ASP.NET Web Form application, look at System.Web.UI.TemplateControl’s Error event. TemplateControl is the base class of the System.Web.UI.Page and System.Web.UI.UserControl classes. Furthermore, you should also look at System. Web.HttpApplication’s Error event.

■ For a Windows Communication Foundation application, look at System.ServiceModel. Dispatcher.ChannelDispatcher’s ErrorHandlers property.

Before I leave this section, I’d like to say a few words about unhandled exceptions that could occur in a distributed application such as a website or web service. In an ideal world, a server application that experiences an unhandled exception should log it, send some kind of notification back to the

7 You can actually disable this message box by using P/Invoke to call Win32’s SetErrorMode function, passing in

SEM_NOGPFAULTERRORBOX.

client indicating that the requested operation could not complete, and then the server should termi- nate. Unfortunately, we don’t live in an ideal world, and therefore, it may not be possible to send a failure notification back to the client. For some stateful servers (such as Microsoft SQL Server), it may not be practical to terminate the server and start a brand new instance.

For a server application, information about the unhandled exception should not be returned to the client because there is little a client could do about it, especially if the client is implemented by a

different company. Furthermore, the server should divulge as little information about itself as possible to its clients to reduce that potential of the server being hacked.

NoteThe CLR considers some exceptions thrown by native code as corrupted state excep- tions (CSEs) because they are usually the result of a bug in the CLR itself or in some native

code for which the managed developer has no control over. By default, the CLR will not let managed code catch these exceptions and finally blocks will not execute. Here is the list of native Win32 exceptions that are considered CSEs.

EXCEPTION_ACCESS_VIOLATION EXCEPTION_STACK_OVERFLOW EXCEPTION_ILLEGAL_INSTRUCTION EXCEPTION_IN_PAGE_ERROR EXCEPTION_INVALID_DISPOSITION EXCEPTION_NONCONTINUABLE_EXCEPTION EXCEPTION_PRIV_INSTRUCTION STATUS_UNWIND_CONSOLIDATE.

Individual managed methods can override the default and catch these exceptions by ap- plying the System.Runtime.ExceptionServices.HandleProcessCorruptedState­ ExceptionsAttribute to the method. In addition, the method must have the System. Security.SecurityCriticalAttribute applied to it. You can also override the default for an entire process by setting the legacyCorruptedStateExceptionPolicy element in the application’s Extensible Markup Language (XML) configuration file to true. The CLR converts most of these to a System.Runtime.InteropServices.SEHException object except for EXCEPTION_ACCESS_VIOLATION, which is converted to a System.Access­ ViolationException object, and EXCEPTION_STACK_OVERFLOW, which is converted to a System.StackOverflowException object.

Date: 2016-03-03; view: 747