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
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
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:
Erratic Invalid Viewstate issue in a .NET application
Making user login persistant with ASP .Net Membership
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).
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.
I had this kind of exception being thrown in my logs and had a very different cause from the others listed here. I did have a very large ViewState, which is part of the problem. But that was combining with another issue to cause these exceptions (and possibly occasional bad responses from IIS).
The code base I'm working on has some fancy code to avoid double clicks, and as part of that it adds some stuff to the javascript of every button's click event that disables the button after the first click, and then does the usual postback. But calling the postback like that was a problem because some of my buttons already had a postback call generated by .NET automatically. So I was ending up with double postbacks, one of which had an invalid ViewState. Removing the extra postback stopped the exceptions for me.
I know I should really be drastically decreasing the size of the ViewState, but this is a large legacy code base and a change like that would be very invasive.
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.