Microsoft security bulletin MS11-100 breaking our site RRS feed

  • Question

  • User441907706 posted

    After applying the updates from the Microsoft security bulletin MS11-100 certain forms on our site stopped working. The exception says "Operation is not valid due to the current state of the object." It also says "[HttpException (0x80004005): The URL-encoded form data is not valid.]" We haven't changed any code??

    Friday, December 30, 2011 5:20 PM

All replies

  • User-2010311731 posted

    If you back out the update, does it fix your site?  I would recommend opening a support ticket with Microsoft.



    Friday, December 30, 2011 5:38 PM
  • User-1039473202 posted

    Yo daddy-oo,

    Does your page contain > 1000 form elements? Check this page for a solution


    Basically, add this appsetting to your web.config, where 1001 is some big enough number.

      <add key="aspnet:MaxHttpCollectionKeys" value="1001" />

    Take care ace,


    Friday, December 30, 2011 6:15 PM
  • User-1999379906 posted

    Also check out http://kreelbits.blogspot.com/

    Friday, December 30, 2011 8:08 PM
  • User-352234141 posted

    Basically, add this appsetting to your web.config, where 1001 is some big enough number.

      <add key="aspnet:MaxHttpCollectionKeys" value="1001" />

    I saw this solution and tried it on my application, it works fine. But if I increase the value of this key, does that mean that my application can be easily attacked?

    Wednesday, January 4, 2012 7:48 AM
  • User1412441395 posted

    After applying this update, all of my AJAX enabled sites fail as soon as an AJAX postback is performed.  All of these sites have a large number of fields.  I tried the appSettings value mentioned here, but it didn't resolve the issue.  I even set the value to 200000 and tried uninstalling the patch to no avail.  The error that I get is listed below.  Any help is appreciated.  My next step is to restore the server from tape which I really don't want to do.

    Exception information:

    Exception type: MissingMethodException

    Exception message: Method not found: 'Int32 System.Web.Util.AppSettings.get_MaxJsonDeserializerMembers()'.

    at System.Web.Script.Serialization.JavaScriptObjectDeserializer.ThrowIfMaxJsonDeserializerMembersExceeded(Int32 count)

    at System.Web.Script.Serialization.JavaScriptObjectDeserializer.DeserializeDictionary(Int32 depth)

    at System.Web.Script.Serialization.JavaScriptObjectDeserializer.DeserializeInternal(Int32 depth)

    at System.Web.Script.Serialization.JavaScriptObjectDeserializer.BasicDeserialize(String input, Int32 depthLimit, JavaScriptSerializer serializer)

    at System.Web.Script.Serialization.JavaScriptSerializer.Deserialize(JavaScriptSerializer serializer, String input, Type type, Int32 depthLimit)

    at System.Web.Script.Serialization.JavaScriptSerializer.Deserialize[T](String input)

    at Telerik.Web.UI.RadComboBox.LoadPostData(String postDataKey, NameValueCollection postCollection)

    at Telerik.Web.UI.RadDataBoundControl.System.Web.UI.IPostBackDataHandler.LoadPostData(String postDataKey, NameValueCollection postCollection)

    at System.Web.UI.Page.ProcessPostData(NameValueCollection postData, Boolean fBeforeLoad)

    at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

    Wednesday, January 4, 2012 2:26 PM
  • User1509580295 posted

    Same problem here. appSettings-solution worked.

    Thanks for sharing this.

    (no thanks from our productive instances failing over the holidays fly to Microsoft, how many such breaking changes delivered by security patches are we going to see yet?)

    Thursday, January 5, 2012 7:09 AM
  • User1412441395 posted

    My only solution was to restore the server from tape.  Once restored prior to the patch install, everything is working.  Now I'm afraid to ever install this patch on any of my servers.  Anyone?

    Thursday, January 5, 2012 8:53 AM
  • User1509580295 posted

    this looks as if symptom 3 of MS KB2661403 would apply to you (add key "aspnet:MaxJsonDeserializerMembers" with a value greater than 1000),

    but your IIS/ASP config has a version conflict since your exception call stack shows that the method which is supposed to actually read the setting from the web.config is missing in the framework dll. I'd suggest you check your setup of framework version, asp.net version, application pool framework setting, DLL versions in the ASP binaries directory (aspnet_regiis etc.)

    Once this is settled, the fix as described above is likely to work in your scenario as well.

    this could be helpful as well:
    (search for KB2656351 on the page)

    Thursday, January 5, 2012 9:05 AM
  • User1412441395 posted

    Thanks for your reply.  Can you please help me understand the version conflict?  This is a Win2003 server with .NET1.1,2.0,3.5 & 4 installed.  This particular site is using .NET 4 with Telerik AJAX controls.  I'm not sure why you think the versions are mixed.


    Thursday, January 5, 2012 2:03 PM
  • User-1039473202 posted

    I saw this solution and tried it on my application, it works fine. But if I increase the value of this key, does that mean that my application can be easily attacked?

    Well, the "attack" is that someone can more easily run a denial of service against your site by forcing the hashtable that contains submitted form elements to be inserted in the most sub-optimal way possible. So someone can make your site run slow and chew up 100% CPU just by throwing a few hundred KB of data at it.

    It is hard to say whether this is a real concern or not. Someone who wants to DOS your site can simply throw enough traffic at it, no matter what. Or they can find any other page on your site that takes a long time to calculate.

    I would suggest turning up the value and not worrying about it. However, reconfiguring your web application to use fewer form fields would be the ideal solution. If having that many form fields at once is truly necessary, then some sort of AJAX partial submits would be a good solution - not only for site performance, but for your users.

    Thursday, January 5, 2012 4:56 PM
  • User-1350451820 posted

    This appears to me to be a case where the cure is worse than the disease.

    The patch broke our applications as well and the MaxHttpCollectionKeys fix worked.  Thanks! 

    If this exploit was so "easy" why didn't the Internet just stop, or at least those parts using .NET.

    Reading further into the release notes I would recommend thet everyone rename your local "administrator" account so that they don't know a local account ID, or at least not that one.

    But that is a recommendation I have made for years just on general security princlples, along with moving INETPUB off of C: (I know call me old fashioned).

    If you really want to mess with them rename "NoGuest" to "administrator" so that they end up with even less access then the account that they started with.

    Thursday, January 5, 2012 5:54 PM
  • User1509580295 posted

    @tbannar: I'm currently doing some additional research. Unfortunately we no longer operate any 2003-server in our network, so the version numbers may be different on your system.

    You might try searching for files named "System.Web.dll" on your server and check their timestamps and version numbers. The one contained in the update should have a version number greater than 4.0.30319.1 and a timestamp greater than november 2011 (mine is 4.0.30319.272 from december 26th, 2011 03:54:00).

    System.Web.dll 4 before update
    System.Web.dll 4 after update

    To check in detail, open up .NET Reflector, select "file > open" from the menu, subsequently pointing to each System.Web.dll found, and navigate to "System > Web > Util > AppSettings" (as it says in the call stack in the exception you've previously posted). Then see if there's an entry called "MaxJsonDeserializerMembers". If not, probably one of these actions must be taken:

    • ensure that the system.web.dll is not shipped with your application(s) but taken from the server's GAC instead (don't ship in the bin directory)
    • it might help to actually delete the system.web.dll from the bin directories of your ASP apps and restart IIS to force it to take the version from GAC
    • if the right version is not in GAC or not present at all, then probably the security update failed altogether or is missing reboot or whatever...
    • I do not know whether Telerik uses components of the AJAX toolkit in the background. If it does, and my information is correct, then since the toolkit is not available in .net 4.0 but only up to 2.0/3.5, it might be referencing the 2.0 version of System.Web.dll (even though your application is 4.0) and this might not have been updated? To verify, check which version of System.Web.Extensions.dll is used (because that is where "System.Web.Script.Serialization.JavaScriptObjectDeserializer" is located)
    Friday, January 6, 2012 11:31 AM
  • User-965599672 posted

    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.

    What a clusterf__k.  I demand to know who was the kucklehead at MS who decided that 1000 data elements was enough!  Further, the impact of this POS was not noted in any of the release notes on the KB articles.  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.

    Friday, February 3, 2012 11:12 PM
  • User346709730 posted

    I ran into the same problem after a windows update on our servers. I had to make registry changes to get our site working again as we are running .net framework 1.1

    Friday, February 10, 2012 11:05 AM
  • User-965599672 posted

    I encourage everyone on this thread to complain to their Microsoft rep about this impact as we have.  The rep stated that not any of his other clients have expressed the same impact, but I suspect people are suffering in silence.  We need to send a message to Microsoft that there are many reasons people move to different platforms.  And on the home front, I think that I have seen my lact PC.

    Friday, February 10, 2012 11:19 AM
  • User-534001550 posted

    I fully agree with the criticisms of this "fix". Microsoft's making this arbitrary change is INCREDIBLY destructive. Web applications that worked fine suddenly stop working in a very aggressive fashion and it's been extremely time-consuming to find out why. For any complex web application the value of 1000 is too small. Indeed, their count doesn't even seem correct - I've had it throw the error with only 140 <input tags and the default value of 1000.

    Very poor, Microsoft. Why could you not default it to not use this value, or provide the capability easily to turn off this intrusive and unnecessary "security" feature by, for instance, setting it to -1?

    The main problem is that Microsoft don't appear to understand that there is a difference between public websites - which might suffer from DOS attacks - and private, application-delivering sites, which are typically either run on an Intranet or on a highly secured site running over the Internet. As "flashfearless" says, everyone ought to complain to Microsoft about this ludicrous "correction".

    Friday, September 21, 2012 8:56 AM