One possible reason for “The state information is invalid for this page…” exception

By Akbar

One of our client was randomly having the “The state information is invalid for this page and might be corrupt” error on the pages. The weird thing was that it seems to be random. After some testing, we finally found a pattern and ultimately were able find the root cause of the bug. Though there are various reason for this issues (including some reported bugs), but one we found doesn’t seems to be documented anywhere. This only happens during in Microsoft AJAX callback and if you have ViewState chunking feature enabled.

Please note that sending ViewState in chunks is a new feature in 2.0 and let web administrator control how much information is stored in a single view-state variables. This helps keep site running on some of the old proxy and web-browsers (which have a maximum limit for the hidden field length).

After I found a pattern of the problem, we run the HTTP packet analyzer to view the
AJAX response and found something interesting. It seems that there is a problem with the code handling the ViewState chunked fields on the client-side. It’s not the case that AJAX programmers forgot to handle this (come on, they are Microsoft’s programmers, how can they miss so obvious thing), but rather you need a little more complex cycle to break this working. I found that as long as the AJAX call returns the larger or same size of ViewState hidden fields it keep working, the problem arises when the page send the smaller number of ViewState than the previous call (which is quite possible specially on last page of the Repeater or Grid results).


Here is how I found this. In the client web.config, the maximum length of the ViewState is set to 8K using following attribute maxPageStateFieldLength=8192“. Now I went to the application search page, and here is a snapshot of the initial headers.

<input type=”hidden” name=”__EVENTTARGET” id=”__EVENTTARGET” value=”” /><input type=”hidden” name=”__EVENTARGUMENT” id=”__EVENTARGUMENT” value=”” /><input type=”hidden” name=”__VIEWSTATE” id=”__VIEWSTATE” value=”/wEPDwUKMjEwNzE…S4=” /></div>

As you can see, there is just a single view-state field on the page-load. When I performed a search on that page, page generated an
AJAX call to get the results from the server. Server found the first page of result set (containing 100 items) and this increased the response ViewState size to around 12 KB. Here is how the AJAX response looked like (I captured this using a packet viewer tool):


As you can see that this time there were two ViewState fields, but the page rendered correctly and I was able to make another
AJAX calls. So clearly the AJAX handles this growing field scenario very nicely. Now when I navigation to the next page (again using AJAX call), that page has less items (as it was last page) and thus ViewState size was decreased. Here is what was returned as ViewState:


As you can see that though the size of view-state is decreased correctly to just one hidden field (enough to have the data), but didn’t returned the ViewState maximum size info as the first
AJAX call has. So it seems here is a some problem in the AJAX client implementation and it leaves the ViewState value of existing higher ViewState fields. So when you submit that page or make any other calls, browse sends all the ViewState (including the one related to previous AJAX
call) and thus it invalidate the state and throw the exception. Looking at the post data confirmed my assumption. Here is what was being sent to the server:





As you can that view-state is still communicating that it has 2 fields hidden fields, while only the first field has a valid and complete data. Of course, the validation routine will treat this as a view-state corruption and will throw the error.


In short, though I can dig deep into AJAX client library to fix the issue, but I will leave this off to Microsoft programmers (they get big bucks to do this job). For now I have just disabled the ViewState size limit in the client website and things seems back to normal.

Tags: , , ,