Validation of viewstate MAC failed when on page for 20+ minutes

If you open a web page on one of the websites hos开发者_运维问答ted on our server, leave it for 20 minutes and then submit a form, a Validation of viewstate MAC failed. error occurs.

What possible reasons could there be for this?

There's a few reasons this can happen:

Auto-Generated Machine Keys:

If your application pools have the default idle timeout of 20 minutes AND you're using auto-generated validation and decryption keys then each time the pool starts it will generate a new set of keys. This invalidates the browser's encrypted viewstate. You'll also find that forms authentication tickets for persistent tickets will also become invalid.

To overcome this set these keys to fixed values in:

`c:\%systemroot%\microsoft.net\framework\v2.0.50727\CONFIG\machine.config`

You need to add the <machineKey> configuration element to the <system.web> section. There's a pretty good article here that explains how to do this:

How To: Configure MachineKey in ASP.NET 2.0

Scroll down to the section on "Web Farm Deployment Considerations" and Generate Cryptographically Random Keys.

If you're running a load balanced web farm you also need to set each server's machine key to exactly the same value.

Incorrect form action value (3.5SP1):

There's also a case (post 3.5SP1) where if you set the action attribute of your ASP.NET form to something other than the page being posted back to and you're not using crosspage postbacks then you will get this error. But you'd see this right away:

Validation of viewstate MAC failed after installing .NET 3.5 SP1

Timing/Long Running Pages:

There's also an edge case for pages that take a long time to render where if the page is partially rendered and a postback occurs:

Validation of viewstate MAC failed error

Root Cause This exception appears because Controls using DataKeyNames require Viewstate to be encrypted. When Viewstate is encrypted (Default mode, Auto, is to encrypt if controls require that, otherwise not), Page adds field just before closing of the tag. But this hidden field might not have been rendered to the browser with long-running pages, and if you make a postback before it does, the browser initiates postback without this field (in form post collection). End result is that if this field is omitted on postback, the page doesn't know that Viewstate is encrypted and causes the aforementioned Exception. I.E. page expects to be fully-loaded before you make a postback.

It's taken us a while to find the answer to this as I had been informed that another IIS7 server I was comparing it to had been setup in the same way, by the same person.

It turns out the server with the websites which were receiving this error had been setup using Plesk, whereas the other server had not been.

It seems Plesk sets the Idle-Timeout to 5 minutes on the application pools, which is what was causing this error.

To change this do the following:

1. Open IIS
2. Click on application pools node
3. Locate your web application's application pool
4. Right-Click and select Advanace Settings
5. Set the Idle Time-out(minutes) property to 0 or increase it to 30+ minutes

For me, this solved the problem:

I've set LoadUserProfile = True in the application pool to make HKCU registry hive be available to the application.

Note: This is compatible with IIS 7.0+

I ran into this problem, and the scenario was a single web server hosting a very basic ASP.Net application. After struggling a lot I found this post, and that helped me to understand that the problem was the worker process getting recycled.

I find this quite harsh, as it's a scenario that an application might face and such a core error prevents you to handle it properly. As far I could see, this is originated because the default configuration for handling this keys will use the machine.config that states that keys are automatically generated and isolated per application. I think in this cases ASP.Net a temporary key and store it at the worker process level, and when that worker process is gone the issue arises and can't be handled.

The alternative of configuring the machine key solves the problem, clearly is better to set it on the web.config file rather the whole machine.config to keep it at the lowest granularity level.

Another option is to disable the view state MAC check, also through web.config. It will depend on the security level of your application and the risk of having the view state tampered with.

And the best option is to avoid using view state with a MVC application.

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. AutoGenerate cannot be used in a cluster As I found out, there was a <base .... tag in header part of my master page, that I added in last tie and before publishing. This tag specify a default URL and a default target for all links on a page. This was the main cause of the fault, this time.