MSDN Magazine - September 2008 - (Page 22)

Unhandled Exception Processing Windows exposes the mechanism of registering a process-wide callback called the UEF that will be invoked by the OS whenever any thread that is in the process has an exception of any type that goes unhandled. This callback can be registered using the SetUnhandledExceptionFilter Windows API. When a component in the process registers its callback, the OS returns the address of the last callback that was registered with it (or NULL if there was none). Note that this means that the OS tracks only the most recently registered UEF callback. The UEF registers a processwide callback when it becomes aware of an unhandled exception. If the callback determines it cannot process the exception, it is expected that the component that got the callback will invoke the previously registered callback using the pointer the OS returned when SetUnhandledExceptionFilter was used. Similarly, that callback is expected to call into its predecessor, and so on. This process of invoking the previously registered callback is known as the chaining back of unhandled exception filters. By nature, this chain is weak since it can be easily broken if one of the components in the chain does not chain back (or, for instance, terminates the process). This has an important implication for the CLR’s unhandled exception processing. When the CLR is initializing, it registers its UEF callback with the OS as well, in the hope that it will be invoked when a managed exception goes unhandled on a thread that was created outside the CLR. Under normal circumstances, this will work as expected and the CLR’s unhandled exception processing will be triggered. However, in certain instances this may not happen. One such case is when the managed code makes a P/Invoke call into a native component Figure 5 Register for Notification class Program { static void Main(string[] args) { AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException); throw new Exception("This will go unhandled"); } static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e) { Exception ex = (Exception)e.ExceptionObject; Console.WriteLine("Observed unhandled exception: {0}", ex.ToString()); } } that registers its UEF callback with the OS. Assuming the CLR was the last one to register a UEF callback prior to the native component, this component will get the address of the CLR’s callback. Now, when an exception goes unhandled on the thread, the OS will invoke the UEF callback of the native component (since it is the latest registration). If this component does not call back into the CLR’s UEF callback (using the pointer the OS gave it), then the CLR’s unhandled exception processing will not be initiated. Another case in which the CLR’s unhandled exception processing will not be triggered is when a native component registers its UEF callback and then loads the CLR (either via COM interop or explicitly via CLR hosting). In that case the CLR will register its UEF callback and save the original one. When an exception goes unhandled and the OS invokes the topmost UEF, it will end up invoking the CLR’s UEF callback. When this happens, the CLR will behave like a good citizen and will first chain back to the UEF callback that was registered prior to it. Again, if the original UEF callback returns indicating that it has handled the exception, then the CLR won’t trigger its unhandled exception processing. Thus, if you see that the CLR’s unhandled exception processing is not being triggered, you have likely encountered one of these two scenarios. So far, you have seen how the base of the thread executing managed code influences how the CLR’s unhandled exception processing is triggered. But what happens during the CLR’s unhandled exception processing? There are essentially three parts to that process, which I’ll explain next. At a high level, though, the process notifies the crashing application about the exception that went unhandled and the CLR triggers some mechanisms to log details about the crash. The AppDomain class exposes an event that is known as UnhandledException. This event is triggered when an exception goes unhandled on a thread executing managed code and the CLR’s unhandled exception processing is triggered (“and” is the key word here since there are scenarios in which it may not be triggered at all, as I explained earlier). This event is always raised for the default domain. Additionally, if the thread was created in the CLR and in a non-default AppDomain, this notification will be delivered to that AppDomain as well. When the CLR’s unhandled exception processing is triggered, the process is close to termination since the exception has gone unhandled all the way up the thread’s stack. Thus, this is the last chance to do some sort of logging about what went wrong. The event handler gets the exception object pertaining to the unhandled exception so that it can be used for the diagnosis of the failure. The code in Figure 5 registers for and uses this notification. Next, the CLR will collect the managed bucket details pertaining to the unhandled exception and write them to the event log (under the Application Log), as shown in Figure 6. Bucketing is the process that groups crashes of applications based upon the point of crash. In case of unhandled managed exCLR Inside Out AppDomain.UnhandledException Event Notification 22 msdn magazine

Table of Contents Feed for the Digital Edition of MSDN Magazine - September 2008

MSDN Magazine - September 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Cutting Edge Hierarchy ID New Features for Microsoft SQL Server 2008 Prism Data Services Advanced WPF Test Run Security Briefs Foundations { End Bracket }

MSDN Magazine - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.