IIS application pool crash caused by system. Threading. Tasks. Task

Symptom

The IIS application pool crash (crash) has the following features:

1. From the client, the browser is always in the connection status, and the Web server does not respond.

2. From the server side (Windows Server 2008 + IIS 7.0), an error with event ID 5010 will appear in the event log:

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

This error indicates that IIS detects that the program pool 'q .cnblogs.com 'has no response. Why is there no response? The program pool 'q .cnblogs.com 'crashed. What then? IIS forcibly recycles the application pool.

(Note: If this error occurs in the event log of your Web server, it must be caused by the application pool crash .)

Cause

The application pool crash we encountered this time is caused by Unprocessed exceptions when using system. Threading. Tasks. task for asynchronous operations.

The sample code is as follows:

Task. Factory. startnew () =>
{
// The following code does not catch an exception using try .. catch
//...
});

Note: This is an asynchronous operation that does not require callback. There will be no task. Wait (or static method task. waitall or task. waitany) subsequent operations.

After we released the program, the entire site could not be accessed due to exceptions in the code in the task, and the program pool remained in the "crash-> recycle-> crash-> Recycle" loop.

Solution

Capture all code exceptions in the task. The sample code is as follows:

Task.Factory.StartNew(() =>
{
try
    {
//...
 }
catch { }
});

Problem Analysis

The reason for this problem is mentioned in stackoverflow:

If you create a task, and you don't ever calltask.Wait()Or try to retrieve the result ofTask<T>, When the task is collected by the garbage collector, it will tear down your application during finalization. For details, see msdn's page on exception handling in the TPL.

The best option here is to "handle" the exception.

According to the above English, I understand that when you create a task, no task has been called. wait () or does not get its execution results (if an unhandled exception occurs in the task), when the task is collected by GC, in the GC finalization stage, will cause the current application to crash.

For more information, see Exception Handling (task parallel Library) in msdn ):

"Unhandled exceptions that are thrown by user code that is running inside a task are propagated back to the joining thread. · exceptions are propagated when you use one of the static or instance task. wait or task (of tresult ). wait Methods ···"

The unprocessed exception thrown by the code running in a task will be returned to the main thread that creates the task. · When you call task. Wait, exceptions will be returned (to the main thread ).

Analysis: when we encounter a situation where task. Wait is not called, that is, the exception is not returned to the main thread. The following sentence mentions this:

"If you do not wait on a task that propagates an exception, or access its exception property, the exception is escalated according to the. NET exception policy when the task is garbage-collected ."

If you do not wait for an exception to be transmitted in a task or access its asynchronous feature, the exception will be gradually upgraded following the. NET exception policy when the task is recycled by GC.

Analysis: the consequence of gradual upgrade is that the current application process crashes. for ASP. NET programs, the application pool crashes.

Further solutions

On msdn, we recommend that you use task. continuewith to observe and handle exceptions thrown by the task. The sample code is as follows:

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

Summary of causes of application pool crash -- system. threading. tasks. the code in the task throws an unhandled exception because there is no task. wait () operation. The exception is not returned to the main thread. During GC collection, the unidentified exception is found. Then, the exception was reported by the level-1 level, until the current highest leader of the program process, the highest leader in order to take care of the overall situation, and indeed decided to end with this exception, that is, let the entire application pool crash...