Occurs when an exception is thrown in managed code, before the runtime searches the call stack for an exception handler in the application domain.
Assembly: mscorlib (in mscorlib.dll)
This event is only a notification. Handling this event does not handle the exception or affect subsequent exception handling in any way. After the event has been raised and event handlers have been invoked, the common language runtime (CLR) begins to search for a handler for the exception.provides the application domain with a first chance to examine any managed exception.
The event can be handled per application domain. If a thread passes through multiple application domains while executing a call, the event is raised in each application domain that has registered an event handler, before the CLR begins searching for a matching exception handler in that application domain. After the event has been handled, a search is made for a matching exception handler in that application domain. If none is found, the event is raised in the next application domain.
You must handle all exceptions that occur in the event handler for theevent. Otherwise, is raised recursively. This could result in a stack overflow and termination of the application. We recommend that you implement event handlers for this event as constrained execution regions (CERs), to keep infrastructure-related exceptions such as out-of-memory or stack overflow from affecting the virtual machine while the exception notification is being processed.
This event is not raised for exceptions that indicate corruption of process state, such as access violations, unless the event handler is security-critical and has the HandleProcessCorruptedStateExceptionsAttribute attribute.
The common language runtime suspends thread aborts while this notification event is being handled.
The following example creates a series of application domains named AD0 through AD3, with a Worker object in each application domain. Each Worker object has a reference to the Worker object in the next application domain, except for the Worker in the last application domain. The event is handled in all application domains except AD1.
In addition to this example, which demonstrates first-chance exception notifications in multiple application domains, you can find simple use cases in How to: Receive First-Chance Exception Notifications.
When the application domains have been created, the default application domain calls the TestException method for the first application domain. Each Worker object calls the TestException method for the next application domain, until the last Worker throws an exception that is either handled or unhandled. Thus, the current thread passes through all the application domains, and TestException is added to the stack in each application domain.
When the last Worker object handles the exception, the event is raised only in the last application domain. The other application domains never get a chance to handle the exception, so the event is not raised.
When the last Worker object does not handle the exception, the event is raised in each application domain that has an event handler. After each event handler has finished, the stack continues to unwind until the exception is caught by the default application domain.
To see how the stack display grows as the event is raised closer and closer to the default application domain, change e.Exception.Message to e.Exception in the FirstChanceHandler event handlers. Notice that when TestException is called across application domain boundaries, it appears twice: once for the proxy and once for the stub.
Requires full trust for the immediate caller. This member cannot be used by partially trusted or transparent code.
Available since 4.0