Should I ignore the occasional Invalid viewstate error?

Question

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?

Answer 1

There's not much you can do about the former - I trap such exceptions and bounce the user to an error page with a message along the lines of "The page you were on has expired. This normally happens when you try to revisit a page where you had already entered data."

I see the latter most on a fairly large pages that use UpdatePanels. I think it's when the user posts back (or possibly calls back) before the page has finished loading, so not all the javascript that gets tagged on the end of the page has run yet.

Again, there's not much you can do about them except show a suitably friendly message on your error page.

Answer 2

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

1. 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
2. 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.
3. 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.
4. 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.

Answer 3

One issue can be to do with users routers truncating form fields. The way around this is to set the MaxPageStateFieldLength to a smallish number (like 100) in web.config and the ViewState gets broken up into small chunks. It's very simple to do, and this article explains it fully.

Answer 4

Exceptions don't "just happen" from time to time. They always occur for valid reasons, some of which are already listed in the other answers.

However, to alleviate problems with ViewState consider disabling it altogether. As ASP.NET developers we often tend to use ViewState in all sort of places where it isn't needed because its the default. I usually think about using static html before I consider using a control. If you do decide to use a control think about if it really needs ViewState to be enabled. Disabling it often lead to better page load times, so if you can, do it.

I wish it were disabled by default so people were forced to think this way, but it isn't.

Update to answer comment:

Of the top of my head I come up with 3 opportunities to turn off ViewState.

1. Disable ViewState if data is loaded on every postback. This will often be the case if you're building AJAX enabled sites (that's real AJAX not that UpdatePanel kind ;) ), where you usually load data on the first load and then reload/update data using AJAX requests. In some cases you might even load data on every visit for the sole purpose of disabling ViewState, and then cache the data on the server instead.

2. You can also consider disabling ViewState if you databind to content which is really static. Sometimes I find a list which is databound to a small static basedata table in the database or something like that. Now, this can be dangerous, but if I'm convinced that the data wont change I might move the data into the page as static content (you could wrap it in a separate control so you won't have several static copies of the data). But if the data then DO change, you will have to change it manually.

3. Simple controls such as Labels are often good candidates for disabling ViewState.

Finally you could switch to ASP.NET MVC framework and wave goodbye to these problems forever, that's what I'm planning to do even if I will face some other problems. ;)

Answer 5

It's probably not a good idea to ignore this error. In addition to all the above answers you may want to consider looking into how large your viewstate is. A large viewstate can be truncated by a proxy server.

If your view state is large then it might be a good idea to use a ASP.net trace to see what controls are using viewstate, and where you can turn this off.

Answer 6

BlowDart has the right answer for the Invalid Viewstate problem. It's probably your app pool being recycled and changing the encryption key.

See these posts for support:

http://stackoverflow.com/questions/728513/erratic-invalid-viewstate-issue-in-net-application/728539#728539

http://stackoverflow.com/questions/682788/how-do-i-use-persistant-cookies-with-asp-net-membership/1049555#1049555

Answer 7

According to Wayne Walter Berry in this blog post another culprit can be using the XHTML doctype in IE8 without having XHTML compliant markup on the page. This can cause IE8 to send scrambled parameters to scriptresource.axd and throw the invalid viewstate exception.

He recommends making sure all javascript blocks are wrapped with // <![CDATA[]]> or simply changing the doctype (which could cause other css/styling problems on your page).

Answer 8

Update: Microsoft announced that the following bug fix for IE 8 fixes this problem:
http://blogs.msdn.com/ieinternals/archive/2010/04/01/IE8-Lookahead-Downloader-Fixed.aspx