Got this error sometimes ago and, today in another application, it appeared again. This occurred when I had a relatively large number of rows of data to be posted back in a web form, said, 178 rows, in this case. Before the Postback event handler even got hit, the IIS already complained and threw this at me:

DotNetNuke.Services.Exceptions.PageLoadException: Operation is not valid due to the current state of the object. ---> System.InvalidOperationException: Operation is not valid due to the current state of the object. at System.Web.HttpRequest.FillInFormCollection() at System.Web.HttpRequest.get_Form() at System.Web.HttpRequest.get_HasForm() at System.Web.UI.Page.GetCollectionBasedOnMethod(Boolean dontReturnNull) at System.Web.UI.Page.DeterminePostBackMode() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) --- End of inner exception stack trace --

There was no much explicit information to derive more useful details from; but it is obvious that this must have something do with the number of data post back to server since in an earlier upload, with rows less than 30, the same Postback event did not have any problem. I remembered last year I had done some research on this issue after I got this error first time while posting back a large data grid, so I dug out that application’s web.config file, and copied one line from that file and pasted it to the AppSettings in the web.config under the DotNetNuke portal root (where my app was running as a Module), and that fixed the Postback error. This time, I want to share this out loud and also it will help myself in search for solution if I will encounter the same issue again later.

So all I had to do was to add this line anywhere in the appSettings section in a web.config that is in the root of the website:

 <add key=”aspnet:MaxHttpCollectionKeys” value=”1000″/>

The number here is the maximum number of rows of a server data-bind control such as a GridView or a Repeater control. In general, however, it is not a very good practice to have a large number of rows post back over wire and that’s probably why IIS has this implicit cap on this at first place.