Validation of viewstate MAC failed

I receive this error periodically on my web server when visiting an 2.0 website that communicates with a separate MS SQL 2005 on the same network, also I am using out of process session state stored in MS SQL 2005 (it is not part of a server farm and some pages do not contain gridviews):

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

I have tried the following in the Web.config, but this still happens:

<pages enableViewStateMac=“false” />

Also tried the following on the page (although not keen on this due to security concerns):

<pages validateRequest=“false” enableEventValidation=“false” viewStateEncryptionMode =“Never” />

Any ideas?

I have posted a query regarding MachineKey and ValidationKeys but no joy so far…

Translation: someone posted back before your page fully loaded, so ASP.NET couldn’t validate the viewstate.

If it isn’t happing extremely frequently or on a specific page, then don’t worry about it.

Thanks wwb, happens infrequently but I do not have particularly large numbers of visitors so I am concerned how this will scale.
I am using the Telerik RAD controls (AJAX tool in particular) for users completing a questionnaire, so I especially concerned that this will occur during this process and their scores (or at least the process) will be lost…

A lot is written on this error, but as far as I know there is not a definite solution. However, this does works for me:

<pages enableEventValidation=“false” enableViewStateMac=“false” viewStateEncryptionMode=“Never” >

this error also happened to me - i’m thinking of adding a screen loader so that users won’t be able to click any buttons while the page isn’t finished loading

Since I can’t post a link:

"Validation of viewstate MAC failed / The state information is invalid for this page & might be corrupted…
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey & validation algorithm. AutoGenerate cannot be used in a cluster.

You’d be astonished if you’d get this weird error all of a sudden on a working ASP.Net web application, I was
This error infact is a bug in the ASP.Net Framework which has troubled most of the web development masses !

Viewstate usually represents the state of the page when it was last successfully processed / executed on the server… The contents of the page are stored in a container & moved to & from the server on each request. By default, ASP.NET validates the contents of viewstate to ensure that it has not been tampered. If this validation test fails, an invalid viewstate exception is thrown.

This common errors results specifically from an 2.0 web application when using forms or rather a postback method or from the feature called Event Validation… When you postback before the EventValidation field has been rendered, this will throw the exception. If EventValidation is enabled (it is by default), but doesn’t see the hidden field when you postback, you also get the exception… If you submit a form before it has been entirely rendered, then chances are the EventValidation field has not yet been rendered, & thus cannot validate your click & throws the error. This is a security feature that ensures that postback actions only come from events allowed & created by the server to help prevent spoofed postbacks… This feature is implemented by having controls register valid events when they render. The end result is that at the bottom of your rendered <form> tag, you’ll see something like this:

<input type=“hidden” name=“__EVENTVALIDATION” id=“__EVENTVALIDATION” value=“AEBnx7v…tS” />

When a postback occurs, uses the values stored in this hidden field to ensure that the button you clicked invokes a valid event… If it’s not valid, you get the exception that you’ve been seeing all along…

There are a few ways to avoid MAC mismatch mishaps:

Don’t use the ViewState if you don’t need to. Not only will it avoid the whole MAC issue, but your pages will run faster to boot…
Turn off MAC generation by setting enableViewStateMac=false in the page or web.config… This isn’t recommended, since the MAC helps prevent people from tampering with your viewstate data. But if tampering with viewstate data isn’t a concern (& it may not be for some applications where there’s no risk of fraud or security breaches), you can turn it off.
Prevent your application pool from restarting by disabling the auto recycle & idle timeout settings in the application pool. This isn’t a 100% guarantee that the pool won’t restart, but it does help…
Hard-code the MAC validation key so that it’s always the same. I recommend this approach for web farms &/or if your application pool keep restarting for whatever reason (overzealous admins, memory leaks, etc). The biggest risk is now your key is hard-coded in a file, so you need to make sure your server is secure so that people don’t get that key (otherwise they could hack your viewstate). You can hardcode the key in the <machineKey> tag in the machine.config or web.config, like this:
<!-- validation=“[SHA1|MD5|3DES]” –>

If you’re using ASP.NET 2.0, your machineKey tag should also have the decryption attribute:


Server Farms or Server Clusters: Applications running in a server cluster must have all the machineKey configurations set to the same validationKey. The default AutoGenerate key cannot be used in a cluster environment. The registry keys responsible for auto generation of these values are listed here:


When the machineKey is set to AutoGenerate, the key information is stored in the HKEY_CURRENT_USER hive for the account running the process. For W2k3 servers, this is the Network Service account… Otherwise, the account is ASP.NET machine account. When the process launches, ASP.NET will use the HKEY_CURRENT_USER registry key if it is available. If this key is not available, the HKEY_LOCAL_MACHINE key will be used. If neither registry key exists, the process creates the key in the HKEY_LOCAL_MACHINE hive. If these conditions fail, the process creates a brand new set of keys…

When the application pool is running under a user account, the above keys are not generated leading to an intermittent invalid viewstate error.

The workaround is to use a specific key in the machine.config to prevent automatic key generation on each process start. The key must be exactly 128 bits made up of random characters & inserted into the configuration file on each web server experiencing the problem.

Form Posts: Viewstate can only be posted back to the same page. Attempting to post an aspx form to another page will fail with a viewstate invalid exception. This behavior is by design.

The remedy involves into disabling the Machine Authentication Check, unless you implement a back up authentication mechanism, you should refrain from this approach. Machine Authentication Checks are important in reducing the attack surface of ASP.NET applications as described above.
You have to be aware of the security implications. Alternatively, just never post back before the form has finished rendering…

Adjust the settings on the application pools so that recycling is less likely to occur at peak periods.
Use a specific key in the machine.config to prevent automatic key generation on each process start.
Only post to the same ASPX page.
You can disable the UI until the form has rendered, it can be done in the following way:

<%@ Page Language=“vb” AutoEventWireup=“false” Codebehind=“Text.aspx.vb” Inherits=“TestAssembly.TestPage” enableViewStateMac=“False” %>

Or through the web.config in the following manner:

<pages enableViewStateMac=“false” />

You’d also want to try including the following in the header of your .aspx pages to overcome the error:
<meta http-equiv=“Page-Enter” content=“RevealTrans(Duration=0,Transition=0)” />

Including this tag in the header of your page disables the use of the page until it has completely downloaded to the user’s browser. This also reduces the “flicker” effect that occurs on postbacks…

Unfortunately there’s no “perfect” solution for this error as yet. Disabling the enableViewStateMac is ok but in addition to this solution you must store the ViewState somewhere else i.e. Session, Cache so that it won’t get transmitted to the browser & get played around.
The best way is to not use critical information in viewstate or not use components which use viewstate for saving their data. If you need dynamic queries build them every time page refreshes to gain maximum security. Use StateServer or Sessions to store the session/cached data & to maintain sessions on a server farm…

Best luck… "

i have the same problem, i tries what u suggested but it didn’t work. i walso tried the solution given on. Please help me.

this is error details.

The state information is invalid for this page and might be corrupted.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Web.HttpException: The state information is invalid for this page and might be corrupted.

Source Error:

[No relevant source lines]

Source File: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
avis\e7c0bd67\433be85f\App_Web_wfoe-3tw.16.cs Line: 0

Stack Trace:

[FormatException: Invalid character in a Base-64 string.]
System.Convert.FromBase64String(String s) +0
System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) +67
System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState) +4
System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState) +37
System.Web.UI.HiddenFieldPageStatePersister.Load() +136

[ViewStateException: Invalid viewstate.
Client IP:
Port: 1542
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100401 Firefox/3.6.3
ViewState: /wEPDwUENTM4MQ9kFgJmD2QWAgIDD2QWBgIDD2QWAgIDDzwrAA0BDBQrAAUFDzA6MCwwOjEsMDoyLDA6MxQrAAIWDB4EVGV4dAUOR2nhu5tpIHRoaeG7h3UeBVZhbHVlBRBnaW9pLXRoaWV1LWNodW5nHgtOYXZpZ2F0ZVVybAURfi9HaW9pLVRoaWV1LmFzcHgeB1Rvb2xUaXAFJUNodW5nIEtob2FuIE5hbSBWaWV0IC0gR2nhu5tpIHRoaeG7h3UeBlRhcmdldGUeEVNlcGFyYXRvckltYWdlVXJsBRJ+L2ltYWdlcy9wdF8zMy5naWZkFCsAAhYMHwAFDlR1eeG7g24gZOG7pW5nHwEFCnR1eWVuLWR1bmcfAgUffi9EZWZhdWx0LmFzcHg/Y2F0aWQ9dHV5ZW4tZHVuZx8DBSVDaHVuZyBLaG9hbiBOYW0gVmlldCAtIFR1eeG7g24gZOG7pW5nHwRlHwUFEn4vaW1hZ2VzL3B0XzMzLmdpZmQUKwACFgwfAAULTGnDqm4ga+G6v3QfAQUJTElTVF9MSU5LHwIFEH4vTGlzdC1MaW5rLmFzcHgfAwUiQ2h1bmcgS2hvYW4gTmFtIFZpZXQgLSBMacOqbiBr4bq/dB8EZR8FBRJ+L2ltYWdlcy9wdF8zMy5naWZkFCsAAhYMHwAFEcSQxINuZyBrw70gdGh14bq/HwEFDERhbmcta3ktdGh1ZR8CBSF+L0RlZmF1bHQuYXNweD9jYXRpZD1EYW5nLWt5LXRodWUfAwUoQ2h1bmcgS2hvYW4gTmFtIFZpZXQgLSDEkMSDbmcga8O9IHRodeG6vx8EZR8FBRJ+L2ltYWdlcy9wdF8zMy5naWZk…]

[HttpException (0x80004005): The state information is invalid for this page and might be corrupted.]
System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) +267
System.Web.UI.HiddenFieldPageStatePersister.Load() +218
System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +83
System.Web.UI.Page.LoadAllState() +35
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +7350
System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +213
System.Web.UI.Page.ProcessRequest() +86
System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +18
System.Web.UI.Page.ProcessRequest(HttpContext context) +49
ASP.home_aspx.ProcessRequest(HttpContext context) in c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +358
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64