ASP.NET: Unable to validate data

Question

What is the cause of this exception in ASP.NET? Obviously it is a viewstate exception, but I can't reproduce the error on the page that is throwing the exception (a simple two TextBox form with a button and navigation links).

FWIW, I'm not running a web farm.

Exception

Error Message: Unable to validate data.

Error Source: System.Web

Error Target Site: Byte[] GetDecodedData(Byte[], Byte[], Int32, Int32, Int32 ByRef)

Post Data

VIEWSTATE:

/wEPDwULLTE4NTUyODcyMTFkZF96FHxDUAHIY3NOAMRJYZ+CKsnB

EVENTVALIDATION:

/wEWBAK+8ZzHAgKOhZRcApDF79ECAoLch4YMeQ2ayv/Gi76znHooiRyBFrWtwyg=

Exception Stack Trace

   at System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError)
   at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
   at System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState)
   at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState)
   at System.Web.UI.HiddenFieldPageStatePersister.Load()
   at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
   at System.Web.UI.Page.LoadAllState()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest()
   at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
   at System.Web.UI.Page.ProcessRequest(HttpContext context)
   at ASP.default_aspx.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

~ William Riley-Land

Answer 1

The most likely cause of this error is when a postback is stopped before all the viewstate loads (the user hits the stop or back buttons), the viewstate will fail to validate and throw the error.

Other potential causes:

• An application pool recycling between the time the viewstate was generated and the time that the user posts it back to the server (unlikely).
• A web farm where the machineKeys are not synchronized (not your issue).

Update: Microsoft article on the issue. In addition to the above they suggest two other potential causes:

• Modification of viewstate by firewalls/anti-virus software
• Posting from one aspx page to another.

Answer 2

In .NET 3.5 SP1 the RenderAllHiddenFieldsAtTopOfForm property was added to the PagesSection configuration.

Web.config

<configuration>

    <system.web>

        <pages renderAllHiddenFieldsAtTopOfForm="true"></pages>

    </system.web>

</configuration>

Interestingly, the default value of this is true. So, in essence, if you are using .NET 3.5 SP1 then the ViewState is automatically being rendered at the top of the form (before the rest of the page is loaded) thus eliminating the ViewState error you are getting.

Answer 3

I've experienced the issue with certain specific versions of Safari 3. My solution was to move the ViewState to the top of the form (extended the Page class and overwrote the Render method for pre-3.5 SP1, or .Net 3.5 SP1 and later does this by default), and to split up the ViewState to several different fields instead of one monster file. See ViewState Chunking in ASP.NET 2.0 (maxPageStateFieldLength)

Answer 4

This free online tool: http://aspnetresources.com/tools/machineKey generates a machineKey element under the system.web element in the web.config file. Here is an example of what it generates:

<machineKey validationKey="1619AB2FDEE6B943AD5D31DD68B7EBDAB32682A5891481D9403A6A55C4F91A340131CB4F4AD26A686DF5911A6C05CAC89307663656B62BE304EA66605156E9B5" decryptionKey="C9D165260E6A697B2993D45E05BD64386445DE01031B790A60F229F6A2656ECF" validation="SHA1" decryption="AES" />

---

Once you see this in your web.config, the error itself suddenly makes sense. The error you are getting says

"ensure that configuration specifies the same validationKey and validation algorithm".

When you look at this machineKey element, suddenly you can see what it is talking about.

---

By "hard coding" this value in your web.config, the key that asp.net uses to serialize and deserialize your viewstate stays the same, no matter which server in a server farm picks it up. Your encryption becomes "portable", thus your viewstate becomes "portable".

I'm just guessing also that maybe the very same server (not in a farm) has this problem if for any reason it "forgets" the key it had, due to a reset on any level that wipes it out. That is perhaps why you see this error after an idle period and you try to use a "stale" page.

Answer 5

"a postback is stopped before all the viewstate loads"

I've had this exact problem before, and this was the cause.

Initially we disabled the ViewStateMac property (enableViewStateMac="false" in the page directive) to solve it, but this is not a true solution to the problem and can threaten data integrity. We ultimately resolved it by disabled our submit button until the page had completely loaded, and trimming the size of our viewstate by disabling it on some controls.

Answer 6

I've found the root of this problem in my web site and I finally managed to solve it. This is not a direct answer to your question, but I wanted to share this little piece of information.

In the past I tried everything (including the solution proposed by Jeffaxe, above) but with no result, and I didn't want to set enableViewStateMac="false" (as Raelshark mentions above) to my page, because this just hides the problem.

What caused the problem in my case? The problem was caused by the use of the Intelligencia.UrlRewriter (Version 2.0 RC 1 build 6) module in certain pages of my web site. I was using some SEO friendly links and that was causing the ViewState validation failure. When I used "normal" links (instead of the SEO-friendly links) the problem disappeared!

I reproduced the problem a few times to make sure it was not a false alarm (I use ASP.NET 3.5).

I know that some of you may not use the above module, and still get this error, which implies that the cause is something else. At least, sharing this experience might be helpful to some.

Answer 7

I got this error when I had a form tag setup on my page without an action attribute, and then in the code-behind, I changed the form's action attribute to "Action.aspx".

And in JavaScript, I submitted the form (theForm.submit();)

I think in my case it was a security issue, and that you can't change this after it's already been set on the page... ?

Answer 8

Not sure if this would help anyone, but my solution was the exclusion of the machineKey in my webconfig for my cookie to get passed.