What causes ViewState Errors
Since I work for a web host with a high percentage of ASP.NET sites (www.orcsweb.com), I'm frequently asked what causes ViewState errors and how to solve them.
There are a number of causes for ViewState errors. First, let's define ViewState.
ASP.NET version 1.0 introduced ViewState which is a set or string of data passed through a hidden form field to maintain state while moving between pages. For example, if you have a calendar control on your page, ViewState is used to remember which date was selected when you click a submit button or follow a hyperlink to another page. John Peterson explains this in more detail: http://www.asp101.com/lessons/viewstate.asp
ViewState doesn't rely on session variables, cookies, caching or anything on the server side except for the ASP.NET machineKey which is used to encode the viewstate. This means that even if a web server is rebooted, ViewState will still exist because it lives on the webpage and not on the server.
That said, why do people get ViewState errors? The most common reasons are:
- The site is on a webfarm and during a browsing session, the user is served up a page from a different web server. If the machineKey isn't the same on the servers, it can cause ViewState errors. Microsoft explains this in more depth. http://support.microsoft.com/default.aspx/kb/831150
- Someone views a page, uploads a change to the page and then refreshes the page or posts to the next step. This change midstream can cause ViewState errors. This occurs because ViewState checks to see that it appears valid on each page. If it appears to be have been messed with, it will throw an error. The check is done by "Message Authentication Code" or ViewStateMAC. I'll cover this below and how to disable this check if needed.
- The other common cause of ViewState errors is from doing a Server.Transfer. If the ViewStateMAC doesn't match on the two pages, a ViewState error can be thrown. If you run into ViewState errors when doing a Server.Transfer, you can consider disabling ViewStateMAC on the transferred page. Bipin Joshi explains how to set EnableViewStateMAC to false if needed: http://www.dotnetbips.com/Articles/displayarticle.aspx?id=183 This can be done at the page level, site level or server level. Note: ViewStateMAC should only be disabled if required. It is used as a security check so setting EnableViewStateMAC to false is beating the default security setting.
- The final cause that I see regularly is when someone uses ASP.NET security. After a period of inactivity a session will time out. The default is 20 minutes. If someone doesn't use their page for 20 minutes and then clicks on a link or button, they will be redirected to the login page. If the ViewState MAC check on the login page doesn't match the originating page, a ViewState error can be thrown. Again, the solution is either to tweak the two pages so that ViewState matches or set EnableViewStateMAC to false as described above. It is possible to remove some controls on the login page causing the ViewStateMAC check to be more forgiving. This will take extensive testing under different situations but it is a possible solution.
While there are other obscure causes like a known issue is early versions of ASP.NET V1.0 (http://support.microsoft.com/default.aspx?scid=kb;en-us;324488) these four points I've listed sum up the situations that I have commonly seen occur.