IndexOutOfRangeException After ApplicationPool Recycle

Feb 19, 2012 at 9:34 PM

Hi All,

Last Friday morning we had a very unusual ocurance.  We deployed a small change to our website, after which we performed an application pool recycle for it to pick up these changes.  Immediately our ASP.Net 4.0 site had issues with one particular section (the rest of the site was performing perfectly).  We were getting thousands of these exceptions in the logs.

Exception is: IndexOutOfRangeException - Index was outside the bounds of the array.       
       At the time of the exception, the container was:

         Resolving Fred.Services.Person.ViewListing,ServiceHost        (mapped from Fred.Services.Person.IViewListing, ServiceHost)
 ---->        System.IndexOutOfRangeException: Index was outside the bounds of the array.
          at System.Collections.Generic.List`1.Add(T item)
         at Microsoft.Practices.ObjectBuilder2.ConstructorSelectorPolicyBase`1.CreateSelectedConstructor(IBuilderContext context, IPolicyList resolverPolicyDestination, ConstructorInfo ctor) in e:\Builds\Unity\UnityTemp\Compile\Unity\Unity\Src\ObjectBuilder\Strategies\BuildPl...)." time="2012-02-16T21:14:59.0249474Z">


To resolve the issue all we did was recycle the application pool again (however it took us a about 30 minutes to realise this was happening).

What is strange is we have a farm of 9 web servers all which were recycled around the same time.  We also recycle app pools nearly twice a day (for deployments and other changes) and we have never seen this problem before in the 18 months of using Unity.

We are using Microsoft.Practices.Unity version 2.0.414.0.

I've also noticed someone else having a very similar problem but with no resolution.


Is there a bug in Unity that occurs randomly when handling application pool recycles or is there something else we need to know of?




Feb 20, 2012 at 10:16 AM
Edited Feb 20, 2012 at 11:04 AM

Hi Rick,

Could you have multiple threads simultaneously resolving dependencies from the same container ? It looks like a concurrency issue. As I see it, if a thread preemption happens in List`1.set_Capacity, the list can end up with an undersized internal array, which could explain the lot of IndexOutOfRangeExceptions. The only two calls to List`1.Add under ConstructorSelectorPolicyBase`1.CreateSelectedConstructor seem to be in DependencyResolverTracker.AddResolverKey and in SelectedMemberWithParameters.AddParameterKey. It appears we can rule out the latter because the stack will own the only reference to the list at that time. On the contrary, the former does not look very thread safe.

I'm not in any way a parallel programming specialist, so this should be considered as a mere hypothesis.

Feb 20, 2012 at 9:46 PM

Hi SFence,

Agree with your conclusions.  It does look like the List within DependencyResolverTracker.AddResolverKey could possibly not be thread-safe.

It is very possible that we have multiple threads simultaneously resolving these dependencies.  Is this something we should be guarding against in our code when we're resolving the dependencies or is this an issue with Unity itself?

It appears that during the AppPool startup somehow this List got corrupted and thus ongoing resolution of only one type was causing us a problem in an isolated part of our website.



Feb 21, 2012 at 11:53 AM

The issue seems to be with Unity itself, as resolution methods are supposed to be thread safe.

I can only recommend that you register an issue in the issue tracker.


Aug 2, 2012 at 9:54 PM

Fixed in the latest release of Unity (2.1.505.2). Get it via NuGet.