Should I ignore the occasional Invalid viewstate error

asp.neterror handlingviewstate

Every now and then (once every day or so) we're seeing the following types of errors in our logs for an ASP.NET 3.5 application

Invalid viewstate
Invalid postback or callback argument

Are these something that "just happens" from time-to-time with an ASP.NET application? Would anyone recommend we spend a lot of time trying to diagnose what's causing the issues?

Best Answer

Well it depends. Invalid viewstate can happen for a variety of reasons.

Viewstate is too big and has not finished rendering before a user causes a postback on the page. The fix is generally to disable all controls that trigger postbacks and enable them client side once the page has finished loading - see http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx
You are using viewstate MACs (and you should be, for security reasons) but you have not set a machine key and the application pool has recycled generating a new one. Don't forget to set a ViewStateUserKey.
Someone is using an old version of IE on the mac where it truncates hidden form fields. In this case you'll need to move viewstate out of the page into session state.
Viewstate MAC issues generally indicate you're on a web farm and have forgotten to set a machine key in web.config. However if you have done this then it is probably someone trying to do bad things (bots posting comments, someone trying to trigger events for disabled controls etc.) The cause of these should be tracked down if only to rule out potential security issues.

Whatever you do do not turn off viewstate or event validation.

Related Solutions

ASP.NET Viewstate validation – ASP.NET 1.1 vs. ASP.NET 3.5

Use sticky sessions as mentioned in this similar post. This will keep users on the same machine for a period of time.

I don't think it wise to allow a single user to hit three different versions of the framework in a single session.

ASP.Net: Why aren’t the changes I make to Viewstate in a control event available to subsequent postbacks

You're right that it's OK for it to be in an UpdatePanel - this shouldn't make any difference.

I suspect that the ViewState is disabled either for your control or for one of its parents: if it's disabled for any parent (all the way up to the page), it'll be disabled for your control.

To get round this, you can use the page's ViewState dictionary instead of the one on your control.

I.e. instead of saying:

this.ViewState[ "Expandedness" ] = ListState.Expanded;

say:

this.Page.ViewState[ "Expandedness" ] = ListState.Expanded;

If it's possible that there's more than one instance of your control on the page, you'll need to ensure the ViewState key is unique, perhaps like this:

this.Page.ViewState[ this.ClientID + "Expandedness" ] = ListState.Expanded;

As an alternative (that will work even if ViewState's disabled for the page), you could consider storing the Expandedness in the ControlState. It's a bit trickier, but google it and you'll find a code sample pretty quickly. It's recommended you store only an absolute minimum of information in the ControlState, but a single flag like this is fine (and actually what it's designed for, really).

Best Answer

Related Solutions

ASP.NET Viewstate validation – ASP.NET 1.1 vs. ASP.NET 3.5

ASP.Net: Why aren’t the changes I make to Viewstate in a control event available to subsequent postbacks

Related Topic