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

5

9

If you open a web page on one of the websites hosted 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?

Arbutus answered 14/1, 2011 at 16:31 Comment(0)
A
12

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
Arbutus answered 20/1, 2011 at 14:19 Comment(3)
Glad you got that working, I never thought about the idle timeout and assumed it would have been a sensible value. Anyway do I get an upvote for effort? :)Halcomb
Hmmm can you try editing your answer please? It states its locked until its edited, then I can vote :SArbutus
@Curt if we set it to 0, doesn't that increase the risk of CSRF?Ytterbia
H
13

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.

Halcomb answered 15/1, 2011 at 1:30 Comment(7)
Hi Kev, thanks for your indepth response. However, we have already manually specified machine keys. I don't believe the 'action' value is an issue for us, as we don't explicity set this, and we are having this issue in ASP.NET 2.0 also. Also, as we are not actioning the form for 20+ minutes, I don't believe the page not having enough time to load is relevant. Cheers.Arbutus
Can you think of any other possible reason as to why this could be? Your helps much appreciated as we are struggling to resolve this!Arbutus
@Curt - hmm that's a head scratcher. Are you seeing anything interesting in the Event logs around the time his happens?Halcomb
Sorry to sound like a complete noob, but how would I go about checking this on IIS7?Arbutus
Sorry, found out where to do this! Will check now!Arbutus
Hi Kev, I think your link to Web Farm Deployment considerations is wrong, it points to Tess's blog again?Elgin
@RalphWillgoss - spotted and fixed. Thanks.Halcomb
A
12

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
Arbutus answered 20/1, 2011 at 14:19 Comment(3)
Glad you got that working, I never thought about the idle timeout and assumed it would have been a sensible value. Anyway do I get an upvote for effort? :)Halcomb
Hmmm can you try editing your answer please? It states its locked until its edited, then I can vote :SArbutus
@Curt if we set it to 0, doesn't that increase the risk of CSRF?Ytterbia
Y
3

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+

Ytterbia answered 2/7, 2018 at 9:34 Comment(0)
G
2

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.

Garnishment answered 29/10, 2012 at 17:52 Comment(1)
I enthusiastically second Diego's best option suggestion. :-) I hate the long auto-generated HTML element ID's in an ASP.Net webforms page. I found that JQuery datatables has issues when HTML element ID's get longer than 50 or so characters. With webforms, it is not uncommon for me to have HTML element ID's with 70+ characters, especially if I end up using nested repeaters, and ascx control pages.Riker
T
0

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.

Thomasthomasa answered 20/10, 2012 at 2:30 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.