One of my most important ASP.NET application in production last week saw a very confusing error. The client reported the following error when they came back to use the application on a fine Thursday morning:

Hashtable insert failed. Load factor too high.

Description: An unhandled exception occurred during the execution of the
current web request. Please review the stack trace for more information
about the error and where it originated in the code.

Exception Details: System.InvalidOperationException: Hashtable insert
failed. Load factor too high.

Source Error:

An unhandled exception was generated during the execution of the current web
request. Information regarding the origin and location of the exception can
be identified using the exception stack trace below.

Stack Trace:

[InvalidOperationException: Hashtable insert failed. Load factor too high.]
  System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean
add) +7486570
  System.Collections.Hashtable.set_Item(Object key, Object value) +11
System.ComponentModel.ReflectTypeDescriptionProvider.ReflectGetAttributes(Ty
pe type) +193
  System.ComponentModel.ReflectedTypeData.GetAttributes() +583
System.ComponentModel.DefaultTypeDescriptor.System.ComponentModel.ICustomTyp
eDescriptor.GetAttributes() +58
  System.ComponentModel.TypeDescriptor.GetAttributes(Type componentType)
+32
  System.Web.UI.ViewStateModeByIdAttribute.IsEnabled(Type type) +110
  System.Web.UI.Control.SaveViewStateRecursive() +242
  System.Web.UI.Page.SaveAllState() +168
  System.Web.UI.Page.ProcessRequestMain(Boolean
includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1099

I had seen this issue for the first time, and as I researched into the problem, I got lots of links but nothing definitive. So I thought of writing this blog post. This post itself is not a definitive solution to the issue, but would give you enough information on the cause of the issue and links you might want to read further.

To start with, I had this error on an ASP.NET application running on .Net 3.5 SP1. You would find links on the web where Microsoft acknowledges the issue to be present in .Net 1.1 and a hotfix available for the same. I was seeing the issue on .Net 3.5 and have found comments on the web which make me believe that the issue is present on all versions of .Net 1.1 through .Net 3.5 SP1 (I haven’t found anyone reporting this for .Net 4.0 though).

Now to provide a quick answer, the issue seems to have no sure-shot solution in the first place. The Knowledge base article 968432 seemed to exacty describe the problem I was facing. According to that article, the issue is caused by unsafe concurrent multi-threaded access to .Net’s core HashTable class’ Insert method. One thing you might think immediately is that you do not use HashTable class anywhere in your code, so this issue should not show up in your app. But recall, .NET (and ASP.NET) itself uses this class under the hood, so inadvertently any issue with that class can show up in your application at some point.

I read another related comment on this MD Forum thread, where Peter Mourfield (a MS Partner) mentioned: We’ve been working with PSS and there is a HotFix pending for this issue. It turns out that the HashTable.set_Item wasn’t threadsafe and under a heavy load the HashTable could get corrupted.

Now what I was really interested in was a fix to this issue. The KB article 968432 (referenced above) pointed to another KB article 981145 for a Hotfix. And as I hopefully browsed to that article (which related to re-hosting Workflows in .Net 2.0) for a hotfix I can apply, I saw these dreaded lines for the hotfix:

A supported hotfix is now available from Microsoft. However, it is intended to correct only the problem that this article describes. Apply it only to systems that are experiencing this specific problem.

To resolve this problem, contact Microsoft Customer Support Services to obtain the hotfix. For a complete list of Microsoft Customer Support Services telephone numbers and information about support costs, visit the following Microsoft Web site:
http://support.microsoft.com/contactus/?ws=support

Oh no, not a bureaucratic process for a hotfix that should be available openly with so many people facing the same issue and Microsoft already having established the validity of the issue being present. But MS has its own ways.

So, the short answer of it is if you are facing the same issue, you need to contact MS Support and request the hotfix from them. The server where we saw this issue gets regularly patched with Windows Update I believe. So one thing I cannot understand is if the issue exists, and MS has a hotfix (privately) available, why hasn’t the same been rolled out through regular Windows Update (again MS’ incomprehensible way of doing some things).

The immediate remedy you have at hand is to reset IIS. We did that on our server and it came back fine (which should obviously make sense as the issue relates to a multithreading problem with .Net HashTable class which gets corrupted on concurrent insertions, resetting IIS flushes every .Net App Domain which means the corrupted HashTable gets washed away). However some people have reported that the issue went away for them only after they reset IIS and emptied out ASP.NET’s Temporary Internet Files Folder (%SystemDrive$\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files).

You might find these links related to this issue interesting:
Todd Carter’s (from MSFT) blog post on the issue
A MSDN Forum thread on the issue
A KB article referenced by many people who faced this issue
A Hotfix for this issue from MS but does not have any downloadable file
.Net 1.1’s KB article for the same issue