Welcome Sign in
Visual Studio 2008 Developer Center
Click to Rate and Give Feedback
MSDN
MSDN Library
Visual Studio 2008
Visual Studio
Threading
 Exceptions in Managed Threads
This page is specific to
Microsoft Visual Studio 2008/.NET Framework 3.5

Other versions are also available for the following:
.NET Framework Developer's Guide
Exceptions in Managed Threads

Updated: November 2007

In the .NET Framework version 2.0, the common language runtime allows most unhandled exceptions in threads to proceed naturally. In most cases this means that the unhandled exception causes the application to terminate.

Note:

This is a significant change from the .NET Framework versions 1.0 and 1.1, which provide a backstop for many unhandled exceptions — for example, unhandled exceptions in thread pool threads. See Change from Previous Versions later in this topic.

The common language runtime provides a backstop for certain unhandled exceptions that are used for controlling program flow:

  • A ThreadAbortException is thrown in a thread because Abort was called.

  • An AppDomainUnloadedException is thrown in a thread because the application domain in which the thread is executing is being unloaded.

  • The common language runtime or a host process terminates the thread by throwing an internal exception.

If any of these exceptions are unhandled in threads created by the common language runtime, the exception terminates the thread, but the common language runtime does not allow the exception to proceed further.

If these exceptions are unhandled in the main thread, or in threads that entered the runtime from unmanaged code, they proceed normally, resulting in termination of the application.

Note:

It is possible for the runtime to throw an unhandled exception before any managed code has had a chance to install an exception handler. Even though managed code had no chance to handle such an exception, the exception is allowed to proceed naturally.

When threads are allowed to fail silently, without terminating the application, serious programming problems can go undetected. This is a particular problem for services and other applications which run for extended periods. As threads fail, program state gradually becomes corrupted. Application performance may degrade, or the application might hang.

Allowing unhandled exceptions in threads to proceed naturally, until the operating system terminates the program, exposes such problems during development and testing. Error reports on program terminations support debugging.

The most significant change pertains to managed threads. In the .NET Framework versions 1.0 and 1.1, the common language runtime provides a backstop for unhandled exceptions in the following situations:

  • There is no such thing as an unhandled exception on a thread pool thread. When a task throws an exception that it does not handle, the runtime prints the exception stack trace to the console and then returns the thread to the thread pool.

  • There is no such thing as an unhandled exception on a thread created with the Start method of the Thread class. When code running on such a thread throws an exception that it does not handle, the runtime prints the exception stack trace to the console and then gracefully terminates the thread.

  • There is no such thing as an unhandled exception on the finalizer thread. When a finalizer throws an exception that it does not handle, the runtime prints the exception stack trace to the console and then allows the finalizer thread to resume running finalizers.

The foreground or background status of a managed thread does not affect this behavior.

For unhandled exceptions on threads originating in unmanaged code, the difference is more subtle. The runtime JIT-attach dialog preempts the operating system dialog for managed exceptions or native exceptions on threads that have passed through native code. The process terminates in all cases.

Migrating Code

In general, the change will expose previously unrecognized programming problems so that they can be fixed. In some cases, however, programmers might have taken advantage of the runtime backstop, for example to terminate threads. Depending on the situation, they should consider one of the following migration strategies:

  • Restructure the code so the thread exits gracefully when a signal is received.

  • Use the Thread..::.Abort method to abort the thread.

  • If a thread must to be stopped so that process termination can proceed, make the thread a background thread so that it is automatically terminated on process exit.

In all cases, the strategy should follow the design guidelines for exceptions. See Design Guidelines for Exceptions.

Application Compatibility Flag

As a temporary compatibility measure, administrators can place a compatibility flag in the <runtime> section of the application configuration file. This causes the common language runtime to revert to the behavior of versions 1.0 and 1.1. 

<legacyUnhandledExceptionPolicy enabled="1"/>

In the .NET Framework version 2.0, an unmanaged host can use the ICLRPolicyManager interface in the Hosting API to override the default unhandled exception policy of the common language runtime. The ICLRPolicyManager::SetUnhandledExceptionPolicy function is used to set the policy for unhandled exceptions.

Other Resources

Managed Threading Basics
Tags What's this?: Add a tag
Community Content   What is Community Content?
Add new content RSS  Annotations
Application Compatibility Flag legacyUnhandledExceptionPolicy setting      Michael Freidgeim   |   Edit   |  

According to MS feedback https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=264618&wa=wsignin1.0:

Some of these configuration settings are not very well documented. The setting that you would like to change is only valid in the aspnet.config file. The file is passed to CorBindToRuntimeHost when ASP.NET loads the CLR. If you make a change similar to the one below and restart the worker process, everything should work as expected.

C:\>type %WINDIR%\Microsoft.NET\Framework\v2.0.50727\aspnet.config
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
<runtime>
<legacyUnhandledExceptionPolicy enabled="true" />
<legacyImpersonationPolicy enabled="true"/>
<alwaysFlowImpersonationPolicy enabled="false"/>
<SymbolReadingPolicy enabled="1" />
</runtime>
</configuration>

Tags What's this?: Add a tag
Flag as ContentBug
Processing
© 2008 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Page view tracker