Background

Viewstate is the process used by an ASP.NET Web page to persist changes to the state of a Web Form across postbacks e.g when a page post's back (such as after a submit button or asp.net server control is clicked), when the page reappears the various form fields still contain their data. This is because ASP .NET maintains the page (or view) state via the use of a hidden field placed on each page with a control.

DotNetNuke has viewstate enabled by default, so module developers should take care to not use unnecessary server controls, or to disable viewstate at the control level, to ensure viewstate does not get too large and impact performance.

Issues with Viewstate

Viewstate issues can occur if a site is hosting in a webfarm and each webserver does not share the same viewstate keys (i.e. the machinekey validationkey and decryptionkey values). If this is the case an error such as the following can occur:
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm

By default DNN does not use autogenerate keys, so to rectify this the machinekey node from web.config simply needs to match on other machines. Note, you will still need to ensure your webfarm is using the relevant Caching Providers

This message can occur for a few other reasons:

• DNN implements cross-site request forgery protection via the viewstatekey setting in asp.net. This means that any postbacks to a site are checked to ensure they come from that site, and are not "cross" posted from another website. As these checks use the viewstate key's, if the application recycles and the values change this can cause the error. This most commonly manifests when a user has left the site idle for a period of time greater than the app recycle (by default 20 minutes), or an operation on the site has caused an app recycle (e.g. installing a module, or the hosting provider automating a recycle). This protection was added in 5.5.0 so if your site has started to see these more regularly this is the likely case and not something to worry about. Unfortunately as the failed viewstate is caught early in the asp.net event cycle, DNN cannot catch and distinguish it from other viewstate events. Note: this exception also commonly occurs when automated security scanners are used against a DNN site as they will test posting content to pages. This is safe to ignore.
  

• If a postback event occurs whilst a slow-loading page is still loading this can happen e.g. if a page containing a gridview is only partially loading, clicking a sort header can cause this. This is caused as the viewstate value was added as the final value in the page in earlier versions of .net (1.0-3.5). Upgrading to .net 3.5sp1 or higher changes this so the viewstate is loaded first, maximising the chances it is fully loaded when a postback event occurs. It's also recommended that page sizes are kept as small as possible.
  

• If the DotNetNuke 6 Login Dialog causes this error, it might be the IIS Application must run in Integrated Pipeline Mode, not in Classic. Occured in DNN 6.1.4.
  

• On rare occasions the viewstate issues are isolated to a internet explorer browser. As IE can cache webpages, a cached copy of a page may contain an "old" viewstate key. This is not a correct behaviour in the browser, but typically it can be resolved by asking the client to press CTRL+F5 to force a fresh load. Alternatively, clients can set their IE browser to pull fresh copies of the page by going to tools->internet options, clicking settings and selecting "Every Time I visit the web page"
  

• Attempts to use website's as spam relays can cause this issue, see here for more.
  

• Microsoft lists a number of other possibilities
  

Note: the 6.0.1 release added some code to catch some of the harmless instances of this and supress the error messages.

Further references

• Truly understanding viewstate
• Understanding viewstate
  

Encryption

Viewstate encryption is a best practice and a good way to provide an additional level of security (a defence in depth approach). This was enabled as the default for the 5.6.1 release, but is a recommended practice for all versions, to make this change add the viewStateEncryptionMode attribute to the pages node in web.config and set it to Always i.e.

<pages validateRequest="false" enableViewStateMac="true" enableEventValidation="true" viewStateEncryptionMode="Always">

Viewstate optimization

As part of the DNN 7.3 changes viewstate was optimized in the 7.3.0 release and is now only 92 bytes for anonymous users, and significantly smaller for logged in users.