IIS application pool crashes due to System.Threading.Tasks.Task task

Reprint: http://www.cnblogs.com/aaa6818162/p/4421305.html

Problem phenomenon

The characteristics of IIS application pool crash (Crash) are as follows:

1. From the client, the browser is connected and the Web server is unresponsive.

2. From the server side (Windows server + IIS 7.0), an event ID of 5010 error appears in the events log:

A process serving application pool ' q.cnblogs.com ' failed to respond to a ping. The process ID was ' 20080 '.

This error means that IIS has detected that the program pool ' q.cnblogs.com ' is unresponsive. Why is it not responding? Because the program pool ' q.cnblogs.com ' crashed. And then what? IIS forces an application pool to be reclaimed.

(Note: If this error occurs in the event log of your Web server, there must be some reason for the application pool to crash.) ）

Cause of the problem

The application pool we encountered this time crashed because an unhandled exception occurred while using System.Threading.Tasks.Task for asynchronous operations.

The sample code is as follows:

Task.Factory.StartNew (() =
{
    The following code is not in try: Catch catch exception
    //...
});

Note: This is an asynchronous operation that does not require callback, followed by no task.wait (or static method Task.waitall or Task.waitany) operations.

After we released the program, because the code in the task generated an exception, the entire site was not able to access, Cheng has been in a "crash----------------recovery" loop.

Workaround

Catch exceptions for all the code in the task, as shown in the example code:

Task.Factory.StartNew (() =
{
    Try
    {
        //...
}
    Catch {}
});

Problem analysis

The reasons for this problem are mentioned on StackOverflow:

If you create a task, and you don't ever call task.Wait() or try to retrieve the result of a, when Task<T> the task is collected B Y the garbage collector, it'll tear down your application during finalization. For details, see MSDN's page on Exception handling in the TPL.

The best option are to "handle" the exception.

According to the above English, my understanding is: When you create a task, no task is called. Wait () or do not get its execution result, (if an unhandled exception occurs in the task), when the task is reclaimed by GC, during the GC finalization phase, the current application crashes.

Look further at the exception handling (Task Parallel Library) in MSDN:

"Unhandled exceptions that's thrown by user code that's running inside a task be propagated back to the joining thread . ··· Exceptions is propagated when you use one of the static or instance task.wait or Task (of TResult). Wait methods "

Translation: Unhandled exceptions thrown by code running in a task are passed back to the main thread that created the task. When you call Task.wait, the exception is sent back (to the main thread).

Analysis: When we encounter the situation is not called task.wait, that is, the exception is not passed back to the main thread. The following sentence mentions this:

"If You don't wait on a task that propagates an exception, or access it exception property, the exception is escalated a Ccording to the. NET exception policy, the task is garbage-collected. "

If you do not wait for an exception to be propagated in a task, or to access its asynchronous attributes, the exception is followed when the task is reclaimed by GC. NET exception policy is progressively upgraded.

Analysis: The consequence of a gradual upgrade is that the current application process crashes, and for an ASP. NET program, the application pool crashes.

A further solution

The recommended practice on MSDN is to use Task.continuewith to observe and process exceptions thrown in a task, as shown in the following example code:

var Task1 = Task.Factory.StartNew (() =
{
    throw new Mycustomexception ("Task1 faulted.");
})
. ContinueWith ((t) =
    {
        Console.WriteLine ("I have observed a {0}",
            T.exception.innerexception.gettype (). Name);
    },
    taskcontinuationoptions.onlyonfaulted);

Summary

Application pool Crash Reason summary--system.threading.tasks.task the code throws an unhandled exception, because there is no task.wait () operation, the exception is not passed back to the main thread, and when GC is reclaimed, this unidentified exception is found. Then, this exception was escalated to the first level, until the current process of the highest leadership, the highest leadership for the sake of the overall, really decided to die with this exception, that is, the entire application pool crashes ...

IIS application pool crashes due to System.Threading.Tasks.Task task