Udostępnij za pośrednictwem

Web server deadlocks - aspnet_isapi.dll

  • Artykuł

There are various reasons for a deadlock can occur on the web server. In this blog post, I would be pointing out the various ways to resolve aspnet_isapi.dll related deadlocks on web server. If the deadlock has occurred on the web server, you should notice a warning or error on Event Viewer.

In one of the Apps I was working on the following was the warning message noticed on Event viewer.

“ISAPI ‘C:\windows\Microsoft.Net\Framework\v2.0.050727\aspnet_isapi.dll’ reported itself as unhealthy for the following reason: ‘Deadlock detected’.

One of the reason, a dead lock can occur on the web server is due to usage of COM Interop cross-context infertace in .NET 1.1 or .NET 2.0. However, this was not the problem on the application I was working. In case, your application is facing deadlock due to COM Interop cross-context interface, this KB articles would be helpful in resolving them.

https://support.microsoft.com/kb/921217/

https://support.microsoft.com/kb/915808/

Finally, after doing a bit of research here and there, I found the correct KB article that defines my problem. Here is the cause of this deadlock.

This problem might occur because ASP.NET limits the number of worker threads and completion port threads that a call can use to execute requests. Typically, a call to a Web service uses one worker thread to execute the code that sends the request and one completion port thread to receive the callback from the Web service. However, if the request is redirected or requires authentication, the call may use as many as two worker and two completion port threads. Therefore, you can exhaust the managed ThreadPool when multiple Web service calls occur at the same time.
For example, suppose that the ThreadPool is limited to 10 worker threads, and all 10 worker threads are currently executing code that is waiting for a callback to execute. The callback can never execute because any work items that are queued to the ThreadPool are blocked until a thread becomes available.
Another potential source of contention is the maxconnection parameter that the System.Net namespace uses to limit the number of connections. Generally, this limit works as expected. However, if many applications try to make many requests to a single IP address at the same time, threads may have to wait for an available connection.

This excellent KB article “Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications” https://support.microsoft.com/kb/821268 clearly defines this problem and gives out solutions.

If the above solutions haven’t resolved your deadlock, than you can generate a dump about your deadlock, which might reveal inner characteristics of it.

How to generate a dump file when ASP.NET deadlocks in IIS 6.0

IIS 6.0 has a new feature that is named Orphan Worker Process. This feature lets you inspect a process that is scheduled to be recycled before the process is terminated. The Orphan Worker Process can be used to attach a debugger to the process and to generate a dump file for investigation.

OrphanWorkerProcess tells IIS not to shutdown the worker process. IIS will leave the process running but won't send the worker process any more requests to execute. This setting lets the process stay in memory so you can jump in with tools like a debugger and see where the deadlock is occurring.

For more details on this technique, read on the following KB article https://support.microsoft.com/kb/828222/

Comments

  • Anonymous
    September 20, 2008
    PingBack from http://www.easycoded.com/web-server-deadlocks-aspnet_isapidll/

  • Anonymous
    December 02, 2010
    javascript:WebForm_DoPostBackWithOptions(new%20WebForm_PostBackOptions("ctl00$content$ctl00$fragment_32172$ctl01$ctl00$ctl00$ctl05$bpCommentForm$ctl05$btnSubmit",%20"",%20true,%20"BlogPostCommentForm-ctl00_content_ctl00_fragment_32172_ctl01_ctl00",%20"",%20false,%20true))