You are hereBlogs / rahul's blog / ASP.NET - System.InvalidOperationException: Hashtable insert failed. Load factor too high error

ASP.NET - System.InvalidOperationException: Hashtable insert failed. Load factor too high error


rahul's picture

By rahul - Posted on 14 August 2011

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

 

Thank you very much for the informative post. We have seen this issue on ASP.NET 4.0 just this past Monday (1/30/2012). Recycling the App pool resolved the issue. We do want to determine how to prevent it in the future. I am not clear on the value in installing the hot fix when we do not use 3.5. Thanks.

rahul's picture

Hi Andrea, I haven't researched on a hotfix for this issue for .Net 4, so no immediate link to share. However the only way of resolving this issue seems to be application of corresponding hotfix for MS for .Net 4 if one is available (the problem is caused due to internal issues in .Net code, so apparently no way one can address this without application of a suitable hotfix).

This has been fixed in .NET 4.5 Beta

rahul's picture

Great, thanks for sharing that Mukul!!

That's very good news, Mukul - Do you have a reference link to the fix that I can review?

Thanks!

Post new comment

The content of this field is kept private and will not be shown publicly.
Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.

Recent comments