Last post Feb 07, 2012 05:16 AM by anilmaddala
Dec 30, 2011 10:44 PM|TomPinColo|LINK
I have some code running as a Web Application on an IIS 7/Server 2008 box written in VB that has been fine for years, suddenly it's blowing up with an exception I've never heard of before:
I did a google search on ThrowIfMaxHttpCollectionKeysExceeded and it returned a single hit, a post on social.technet.microsoft.com's Korean site, posted less than 24 hours ago. Address of that post:
Contents (translated from Korean):
I'm using ASP.NET 2.0
Windows Server 2003 and Windows XP x86 Microsoft. NET Framework 2.0 SP2 Security Update for (KB2656352)
Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008 x86 on the Microsoft. NET Framework 3.5 SP1 Security Update for (KB2657424)
Windows Server 2003 and Windows Server 2003 R2 x86 Microsoft. NET Framework 1.1 SP1 Security Update for (KB2656358)
I headed to patch an existing site after issuing an error bout Is it any problem?
Server Error in '/' Application has
Because of the current state of the object, the operation is not valid
description: during the execution of the current web request an unhandled exception has occurred. Review the stack trace the error and where it originated in the code can find more information about the location.
Exception Details: System.InvalidOperationException: Because of the current state of the object, the operation is not valid.
During the execution of the current web request an unhandled exception was generated. Using the exception stack trace below information regarding the origin and location of the exception can be found.
[InvalidOperationException: object's current state is not valid because the job.]
System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded () +2692302
System.Web.HttpValueCollection.FillFromEncodedBytes (Byte  bytes, Encoding encoding) +61
System.Web.HttpRequest. FillInFormCollection () +148
[HttpException (0x80004005): URL-encoded form data is invalid.]
System.Web.HttpRequest.FillInFormCollection () +206
System.Web.HttpRequest.get_Form () +68
System.Web.HttpRequest.get_HasForm () +8735447
System.Web.UI.Page.GetCollectionBasedOnMethod (Boolean dontReturnNull) +97
System.Web.UI.Page.DeterminePostBackMode () +63
System.Web.UI.Page.ProcessRequestMain (Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +133
Version Information: Microsoft. NET Framework version: 2.0.50727.3625; ASP.NET Version: 2.0. 50727.3634
These errors do not smell.
I applied updates to my server last night. To me, these errors DO smell.
Anybody else seeing anything fishy with their .Net 2.0 Asp.Net code as of the new updates?
Dec 31, 2011 12:06 AM|mbanavige|LINK
Please read this as it likely relates to your error:
How many form fields did you expect to be posted from your page that threw the error?
Dec 31, 2011 12:15 AM|mbanavige|LINK
note that the default number of fields posted may be limited to 1000 if you have installed the latest patch.
Jan 11, 2012 06:15 PM|btsrajkumar|LINK
I face similar issues in one of my applications. Did you find any solution for this issue yet? Thanks.
Jan 11, 2012 06:29 PM|mbanavige|LINK
If the stack trace contains this:
Then somebody posted quite a few form fields to your page. The new default max introduced by the recent security update is 1000.
If you were expecting more than 1000 values to be posted, then you can alter that max to allow more. Please read through that link i had previously posted: http://stackoverflow.com/questions/8684049/asp-net-ms11-100-how-can-i-change-the-limit-on-the-maximum-number-of-posted-for
Jan 11, 2012 07:23 PM|btsrajkumar|LINK
Thanks mbanavige, adding the below element in the web.config fixed the issue.
<appSettings> <add key="aspnet:MaxHttpCollectionKeys" value="2001" /> </appSettings>
Jan 12, 2012 08:15 PM|andy_universital|LINK
I have added the setting, but still am getting the error. I set mine to 10000, but still does not seem to help. I have an application that is completely dynamic for the number of items that show, basically it is a workflow and all items that need to process
show on the page. The user will check off those that should move to the next phase. I use a number of hidden fields to keep the data I need when it submits without having to call the database again. This is a horrible feature. I am now possibly going to have
to rewrite the application, but it just went live for my customer. What is the deal MSFT????
Jan 12, 2012 08:45 PM|mbanavige|LINK
I have added the setting, but still am getting the error. I set mine to 10000, but still does not seem to help
How may form inputs are you posting when you receive the error?
Jan 12, 2012 08:54 PM|andy_universital|LINK
I have a listview and it may have several hundred items, actually there is a nested listview in a listview to have a parent child details. Each of the line item details may be checked off to note it has been processed. So it is completely dynamic. In my
error logging, seems the actual number of bytes is not being logged, so I will enhance that. If I have 200 orders and estimated at 5 items per order, then that would be what posts, however I do have a number of hidden fields per. So lets say 10, so I come
up with 10000 for the number, which others are saying 2001 helps them.
This app is actually ASP.Net 4.0 not 2.0, so if that matters.
Jan 13, 2012 12:22 AM|andy_universital|LINK
I have a dev machine I can point to the production SQL and found the page giving me fits has 1234 form elements posted back. I found my development server did not have the patch, so I will apply it and see if I can rework the pages to not use the hidden
form elements and just query SQL for the data I need each time (seems more chatty, than look up once and pass it around).
Jan 13, 2012 01:07 AM|andy_universital|LINK
My appologies, I had copied the code from another posting, but this one says
aspnet:MaxHttpCollectionKeys and I only had MaxHttpCollectionKeys
which was on another page I found. to have aspnet: in front seems to use the values and gets me past my issue. Hope this helps someone else.
Jan 24, 2012 06:08 PM|shairag|LINK
Did you have any solution yet? I am having the exact same problem as you are having since everything is dynamically created.
Thanks for your help in advance.
Jan 24, 2012 07:22 PM|andy_universital|LINK
I did have a solution refer to
Just add a AppSettings in your web.config and put a number that is appropriate, I used 10000.
<add key="aspnet:MaxHttpCollectionKeys" value="10000" />
Jan 26, 2012 01:28 PM|sandy.misra|LINK
I think the max number of viewstate and postback objects have been limited to 1001. I guess there is a typo in the above reply where it is mentioned 10000.
Jan 26, 2012 05:46 PM|sandy.misra|LINK
Sorry, I read it wrong. The trick is that you have to set it to a limit which suits you. I did an approximate cound of the number of viewstate and postback elements and set the threshold in the config file and it works for me.
Jan 26, 2012 08:38 PM|johnwm|LINK
I found the prescribed solution worked in my dev environ, but not my test. Then I noticed I the dev environ was accidently running the .Net 2 version engine for my .Net 1.1 app! I reconfigured the test environ IIS to run the app under .Net 2 and found
success there as well.
Perhaps the prescribed solution doesn't work for .Net 1.1.
Jan 30, 2012 01:33 PM|johnwm|LINK
A solution for .Net 1.1 is a registry entry, descibed at
Jan 30, 2012 11:59 PM|andy_universital|LINK
Feb 04, 2012 03:19 AM|flashfearless|LINK
Mike, I was wondering if you have some insight as to who is the knucklehead who decided that 1000 was enough data elements and also decided to not tell Customers of Microsoft about the impact up front?
I spent a day in hell yesterday due to the POS known as MS11-100. I had to change 50 machine.configs on 15 servers and even reboot two of them in production because they had a .Net 1.1 app on it and the only way to set it for 1.1 is to make registry setting.
So, I can't even blame it on our testers who did regression test before allow the tests to make it into production.
I have been in the IT field for 27 years and I would never treat my Customers the way Microsoft does by issueing patches that they had to know would break some people's production servers. If they didn't know, then they are more stupd than I thought.
Feb 07, 2012 05:16 AM|anilmaddala|LINK
I am running 1.1 ASP.NET application in a 2.0 ASP.NET environment and I am also facing the same problem. There are a lot of clients waiting for the fix. Any change to 'Web.Config' needs testing and redeployment, which takes time.
Is there any fix we can make in the local machine to make the code unaffected by this patch update?
Please Help. Thank you.