An interesting change which you might have missed in .NET 2.0 is about the autoConfig setting for the <processModel> element. The customer was running out of available connections while accessing a remote web service and was trying to apply what’s suggested in Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications but apparently the change had not effect: a memory dump shown still 12 available connections even if he set MaxConnection=96. Interesting to note that reverting the application to .NET 1.1 the problem disappeared. The different behavior is determined by the autoConfig value, which affects only ASP.NET applications and not Console, WinForm etc… (while the <processModel> threading configuration in .NET 1.x affected all .NET apps running on the machine): Specifies whether to automatically configure the following settings to achieve optimal performance based on the machine configuration:The maxWorkerThreads attributeThe maxIoThreads attributeThe minFreeThreads attribute of the httpRuntime element.The minLocalRequestFreeThreads attribute of the httpRuntime elementThe maxConnection attribute of the <connectionManagement> Element (Network Settings) element. The values are set according to the KB article at http://support.microsoft.com/?id=821268.  This attribute does not affect the .NET Framework client applications; only ASP.NET applications. The autoConfig attribute can be one of the following values. True: Indicates that ASP.NET automatically configures…

Things have gone a bit crazy lately, we’ve been under a huge workload and the time left for blogging was virtually non existent… but the good thing is that I’ve been working on a few interesting cases I hope I’ll have time to blog about, and this is the first one. The problem The application was running on a Windows 2003 cluster and the well known solution to avoid session problems in a multi server environment is to store user sessions out-of-process, either using a State Server or Sql Server, and in this case we were using Sql Server; this is also the right approach if you are using Web Garden for your application pool and this is the situation we were in (web garden + state on Sql Server). But some session-wide arrays the customer was using were suddenly empty as soon as the customer increased the number of worker processes above 1 for the application pool, which is exactly what is not supposed to happen with <sessionState mode=”SqlServer” … />. At the beginning I thought to a configuration problem on the affected servers but the usual quick check on the metabase shown that was not the case, so…