Question

Yes I know this problem has been reported many times, but my case doesn't seem to fit any proposed solutions (unless I miss something).

The ASP.NET page setup (simplified) is: user clicks a link (technically a node of Infragistics WebDataTree) and this action binds a grid (Infragistics WebHierarchicalDataGrid) located in an UpdatePanel.

Now this works fine in a local test system. When deployed to a production server - it also works - most of the times, but sometimes this throws error:

Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request

This seems to happen more if the production system under heavier load (more users accessing it). Again, I am not building any dynamic controls, just a button and a grid that is populated on button click.

What could be causing this? Why this doesn't happen always, but sometimes? Any idea how to fix it?

UPDATE

Here's confirmed scenario

  1. If one user accesses and uses the page - error doesn't happen
  2. If two user doing the same (can even be 2 browser sessions from the same client) - error happens.

How could one session affect viewstate of another?

UPDATE 2

Application is deployed to a single Windows 2008/IIS7 server (no web farms/web gardens, no load balancers). No updates rolls out during runtime.

Application works fine if a single users accesses it, but when multiple users hit the server - eventually some of them are getting ViewState error (while others still work fine). They're all doing the same thing - clicking tree nodes that trigger grid rebind inside of UpdatePanel. They use different browser - IE(9-11), FF, Chrome - error could happen to a random user/browser

Oh and we are not encrypting ViewState either.

UPDATE 3

Stack Trace:

at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState at System.Web.UI.Control.LoadChildViewStateByID(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Page.LoadAllState() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

UPDATE 4

It seems if I reduce size of the data returned with each click (e.g. 20 rows instead of 100) the issue either disappears or appears a lot less often.

I've tried manipulating ViewState - e.g. splitting it into chunks, using session as a ViewState storage to reduce actual posted page size - nothing has effect.

Was it helpful?

Solution

After following this advice on how to debug things outside of my code and gaining access to debug symbols for the Infragistics WebHierarchicalDataGrid DLL as well as its source code - turned out exception is thrown by the control - and its not related to the viewstate. Internally in a 1-element array code tries to access second element, throwing "IndexOutOfBound" exception which undergoes magical transformation to "Failed to load viewstate" thrown to the user.

Infragistics is looking into the error and ways to fix it, but since we're really pressed for time we used following workaround: If "view state" error is detected at the end of async postback - we simple reload the page:

Sys.Application.add_load(appLoaded);

function appLoaded(sender, eventArgs) {
   Sys.WebForms.PageRequestManager.getInstance().add_endRequest(EndRequest)
}

function EndRequest(sender, args) {
    if (args.get_error() != undefined) {
        if (args.get_error().message.indexOf('Failed to load viewstate') != -1) {
            setTimeout(function () { location.reload(true) }, 100)
        }
    }
} 

Yes I do realize this is as elegant as hammering a nail with a screwdriver, but since the error is sporadic and refresh gets rid of it - this will have to do.

OTHER TIPS

How many servers do you have in production? If there is more than one are you setting the machineKey in your web.config so that all servers will be using the same key to sign/validate the ViewState value?

As Michael Liu pointed out in a comment, it's unlikely you would get the control tree error for the machineKey problem. I would still like to know if you have multiple servers in production though because it could still be possible that you are running into an issue where ServerA served up newer version of the code and then the POST back occurred to ServerB which doesn't yet have the new code, so the control trees wouldn't match. This could technically happen even with a single server if you rolled out changes while there are active users on your site.

The viewstate are not related with the session state. But, if you try the websiste with 2 instance of the same browser software, the browsers have the same session. This appends for IE>=8, firefox and chrome. Try with 2 different browsers (sorry for my bad english)

If you host this in production using Load balancing, the problem could occur when a user changes from one server to another. The solution here is often to specify the machineKey in web.config. Read more about it here at msdn.

<machineKey  
    validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B"           
    decryptionKey="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F"
    validation="SHA1" decryption="AES" />

It seems the UpdatePanel is causing a problem with the viewstate.

Update:

To debug, I would try to log the view states that are being sent out to each client and those that are being received back from the client during the partial post back.

You can store them temporariliy on your db server associated with a session, and clear them when the session is over if there was no exception. Then if you encounter this exception mark it in the db and you can compare what your server sent to the client and what was received back on postback. You can also manually load these values in your browser and replay them to see what happens.

Either the view state is being currupted client side or your server is sending out invalid view states.

At least this will help you get some data to debug.


Here is an article about update panels and some alternative ajax methods that might help solve the problem:

http://msdn.microsoft.com/en-us/magazine/cc163413.aspx

Some other possible helps:

http://lachlankeown.blogspot.com/2008/04/firefox-refresh-viewstate-updatepanel.html?m=1

http://weblog.west-wind.com/posts/2005/Jul/16/Invalid-ViewState

http://support.microsoft.com/default.aspx?scid=kb;EN-US;829743

Are your users actually reporting the problem or are you just seeing it in error logs? I've seen this error before when the user cancelled a request on the browser, causing ASP.NET to error when attempting to parse a partially transmitted request. If the viewstate happened to be partially transmitted, you could see this error. The larger your viewstate & the more users you have the more likely you are to see this error. You can safely ignore this error.

You could test this by loading up a page with lots of viewstate and cancelling a postback.

I experienced similar issue sometime back in one of my project. The reason for the problem was that we were adding dynamic controls to a table control, and then on submitting the page the table would be populated by different set of controls. On looking deeply into the issue we found that mostly for the dropdown controls on the previous page if there is some other control at the same location the viewstate would fail.

The solution was extremely simple for us, since we were creating the controls dynamically they were anyways being created everytime, so we simply turned the ViewState=false for the control (in your case a grid control).

Based on your comment I think you need to identify what for you is spanning across the sessions. It may very well be the data that changes for the first user when another user is logged in. In that case also you should consider setting the ViewState=false, or binding the grid at page_Oninit, that way the ViewState would not conflict.

Hope this helps.

Try decompiling the dll with ILSpy, save the project, build it, than link that project instead of the dll. This way you will get the full stack trace, and maybe get closer to the exception.

I had the same problems when for example: clicking on a button that would redirect me, then press the back button on IE with the "old" viewstate, while some content had changed. On IE, Chrome, Firefox, i had that problem due to caching.

To avoid browsers from caching your pages, you can use a random parameter in your url : for ex : "&ran=54921356" that would randomely be generatad. See if this helps

I don't know how your WebHierarchicalDataGrid is binded, your updatepanel wraping it shouldn't be viewstate enabled if data can change between a post-back and then going back.

I hope this helps !

PS: Also, i think that storing the viewstate in session is a bad idea...

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top