A deadlock issue in the SQL Server network library occurs after a call to the ExitProcess function

When you use ASP.Net to retrieve data from Microsoft SQL Server, the Web server may acquire an accumulation of aspnet_wp processes that are not using the CPU and that have only a few remaining threads.

During ASP.NET process recycling, an aspnet_wp worker process may deadlock with the Dbnetlib.dll file on shutdown after a call to the ExitProcess function. If such a deadlock occurs, the aspnet_isapi cannot kill the old aspnet_wp process, and therefore the process continues to consume memory resources. Repeated occurrences result in performance degradation.

If you connect to a SQL Server database from ASP.NET, it is possible for Dbnetlib.dll to cause a deadlock during process recycling. In a debugger, there will be only a few remaining threads, one of which will contain the following calls in its stack trace:

To work around this issue, take any action that lessens the frequency of process recycling. It may help if you disable proactive process recycling in the processModel configuration section. To do this, set the following parameters as follows: To reduce process recycling, confirm that your application is free of memory leaks, access violations, and so forth.

If a fix for this problem is required, please contact Microsoft technical support.

During process termination, the LoaderLock is taken by the Ntdll.dll file so that it can begin unloading DLLs. When Dbnetlib.dll is being unloaded, it calls WS2_32!WSACleanup from its DLLMain() routine, which, in turn, attempts to unload additional DLLs. This process deadlocks, because the thread already owns the LoaderLock and can execute in only one DLLMain() routine at a time.