A Solution to: Validation of viewstate MAC failed

Original post address: http://forums.asp.net/1173230/ShowPost.aspx

Validation of viewstate MAC failed / The state information is invalid for this page and might be corrupted

hey folk,

maybe you can help me with the following prob:
i developped a "job search application" in asp.net 2.0 beta. it compiled and ran without any problems. now, with the new asp.net 2.0 final version, i'm getting a lot this error message:

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.

this error is only generated if you navigate quickly through the web application. that means, if you press an <asp:Button> before the whole page is loaded/rendered, then you get this posted error. if you wait until the whole page has finished rendering, then the postback generates no errors.
 
i've read a lot of articles and forum posts, and nothing figured out the problem:
- NO, i'm not running a Web Farm.
- page property "EnableViewStateMac" set to false does not solve the problem, it just changes the error message in same navigation behaviour:

The state information is invalid for this page and might be corrupted.

the second error could be solved with hotfixes/updates in asp.net 1.0/1.1
is there also a solution available for asp.net 2.0 final version?

thanks for helping!

further information about my problem:

i've done a lot of test cases in recently past hours, following i found out concerning my problem:
it depends on which webcontrols you have in use in an asp.net 2.0 final application. my reported problem only occurs if you've nested a gridview, a detailview or a formview within the *.aspx page. and it does not even matter if they are bound to a datasource control. they fail in both cases (bound / unbound) if you navigate too quickly (have a look at first post for its explanation).

conclusion:
my problem has too be a general one in asp.net 2.0 final framework. i'm working in a small developping team for web solutions. and we've figured out that all our asp.net applications (which were running fine in asp.net beta 2.0) have this problem :-( error message "Validation of viewstate MAC failed" occurs in simple page architecture (no masterpages, no callbacks etc.) even!
i'm sure other developers are also hit, aren't they?

special remark:
although we have NO webfarm in use, i've also tried to use a self-generated <machinekey> in web.config. no success as expected ;-) 

What a 'tiny' bug...

today, i found out under which exact circumstances the reported error raises.
it all belongs to the DataKeyNames property!

if you don't use this property, you will never get that "Validation of viewstate MAC failed" error by navigating quickly (do postback before whole page has finished rendering).
so, all you need on an *.aspx page for generating this error:

1. SqlDataSource
2. GridView bound to SqlDataSource
3. Using DataKeyNames in GridView
4. Something on the *.aspx page which takes a while till rendered (as for example banners, external pictures etc.)
5. Button*

* you can also do a postback with the GridView's sorting command.


final conclusion:
that must be a bug in the .net framework! MVP users or others... what do you think about? 

hey joteke,

thanks for taking time! i've spent the morning for reproducing a small sample page that points out the reported bug. i used a <asp:XmlDataSource> instead of <asp:SqlDataSource> for make it independent of any configuration ressources. you can download the source here: http://www.espace.ch/viewstateProblem.rar

you have to click very quickly (serveral times) in doing the postback for reproducing the bug in the sample page!!!

for those guys who think the navigation behavior strange... yeah, you're right: in the given sample page, it is really silly n' difficult navigating so quickly (pressing button before page has finished rendering!!). but if you look at the final application (http://adv.espace.ch/einsteigerprofil), you'll see that reported navigation behavior is common: the standard shape/design of espace.ch takes an amount of time for loading - and i don't think users are gonna wait until page has finished rendering each time.

last but not least i have to correct my observations!
so, all you need on an *.aspx page for generating this error:

1. Any DataSource Control (SqlDataSource, XmlDataSource...) 
2. GridView bound / unbound to DataSource
3. Using DataKeyNames in GridView
4. Using <asp:BoundField> elements
5. Something on the *.aspx page which takes a while till rendered (as for example banners, external pictures etc.)
6. Button

Ok,

if you guys add this to web.config, does it still reproduce?

<pages validateRequest="false" enableEventValidation="false" viewStateEncryptionMode ="Never" />

E.g note the viewStateEncryptionMode.

Hi Joteki,

The error is ever present in my case. I get the typical "Invalid postback or callback argument.  Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page.  For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them.  If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation." whether enableEventValidation is set to true or false.

One thing worth noting:  My page actually has three different controls, all seperate and none linked or nested - 1 Gridview and 2 datalists. If I take a new aspx, create a simple gridview bound to the same view in SQL, and try sorting (my problem occurs on the sort), everything rolls fine. But in my original .aspx, I get the error.

So I removed the controls in order to slowly start "removing possible conflicts" and suddently, the sort in my Gridview worked without a hitch. I put the datalist back and the error returned.

Thinking I was on to something, I removed all datalists and gridview from my original .aspx as well as SqlSources. I then proceeded to add my Gridview and the error returned WITHOUT the datalists.

This REALLY appears to be a bug in .Net 2.0, and I've yet to figure out why exactly it happens. Isolating it appears impossible.

The only workaround I can suggest is to "think outside of the box" and try placing your controls in other ways, or redo the page altogether.

I have had other bugs where a simple bound dropdownlist would not function properly until I literally "Deleted" the Usercontrol (.ascx) from my project, created a new one and the DDL functioned properly moving forward.

Servicepack anyone?

/JD

Hi everyone,

The error that's happening (as has been mentioned earlier) is caused by an ASP.net 2.0 feature called Event Validation. This is a security feature that ensures that postback actions only come from events allowed and created by the server to help prevent spoofed postbacks. This feature is implemented by having controls register valid events when they render (as in, during their actual Render() methods). 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, ASP.net 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.

The problem you're seeing happens specifically when you postback before the EventValidation field has been rendered. If EventValidation is enabled (which it is, by default), but ASP.net 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, and thus ASP.net cannot validate your click.

One work around is of course to just disable event validation, but you have to be aware of the security implications. Alternatively, just never post back before the form has finished rendering. Of course, that's hard to tell your users, but perhaps you could disable the UI until the form has rendered?

Unfortunately there's no "perfect" solution for this just yet.

Thanks,

Eilon