Validation of ViewState MAC Failed when posting 'too quickly' by joteke

Thank you for your feedback. We are investigating this issue.

Thank you, VS2005 Product Team

Thank you for your feedback. We are investigating this issue.

Thank you, VS2005 Product Team

What's the status with this (almost 2 motnhs since submission)? There's been quite a lot of concerns & issues on ASP.NET Forums related to this one: http://forums.asp.net/thread/1173230.aspx (also in other type of scenarios) so in this light I might suggest this to be a bug instead of originally being a suggestion.

Many thanks for your feedback. We are investigfating.

The Web Platform and Tools Team.

Is this issue still being looked into? It would be nice to have a 'fix' at soon!

Almost the end of June and still no solution to this problem?????

What a huge letdown, when I converted my perfectly working 1.1 website to the new 2.0 website, only to find out in the first ten minutes that it has a major bug that Microsoft can't figure out for months.

Didn't anyone betatest this? Surely you didn't rush the product out the door cause you needed the money.

Let me know if you are close to fixing this. If not, I will throw 2.0 in garbage can and reinstall 1.1

Tony
CoralSpringsTony@hotmail.com

Guys and gals,

what's the status with this one? Are you going to a) provide this workaround as proposed solution for now and/or b) are you going to change something for example in vNext to overcome this?

Thanks,

Teemu

i have the same thing happen to me

Thanks for your feedback on the .NET Framework! S. Somasegar, the Developer Division VP recently wrote in his blog (http://blogs.msdn.com/somasegar/archive/2006/05/18/601354.aspx) on how the next release of the .NET Framework (codename “Orcas”) requires a high degree of backward compatibility and therefore, how we are being very strict about the number and scope of bugs that are fixed and features that are added in the “Red Bits” during Orcas. Unfortunately, this bug falls into the red bits category, and so we are not able to address it in Orcas due to the potential for it to introduce compatibility issues.

However there are some work arounds that can mitigate the problem. These are throughly discussed at http://forums.asp.net/1173230/ShowPost.aspx.

We recognize you submitted this bug because of a specific problem you are experiencing with the product. If you submitted this bug because of a blocking problem you’re experiencing and continue to experience, you may want to contact Microsoft Professional Services http://support.microsoft.com. Alternatively you may find additional information by searching or posting to the ASP.NET forums (http://forums.asp.net) . Finally, if you submitted this bug because of a blocking problem you’re experiencing and continue to experience, you may want to also open a support call with Microsoft Professional Services (http://support.microsoft.com/?LN=en-us&scid=gp%3Ben-us%3Bofferprophone&x=8&y=14), which is a better support option when you’re experiencing business impact for your problem and are unable to resolve it in a timely manner on forums or other support channels.

Before starting work on the next full release of the .NET Framework, we will review the Connect data to help us identify and address the top customer reported issues. We’ll broadly review all bugs submitted to date at that time.

Mir Tariq
UI Frameworks Team

I really need this to be resolved, there are multiple sites on the 2.0 framework and this is a huge issue. Please advise.

Well... this is not the most perfect answer, but I have a workaround to post:

(solves the problem in IE, anyways... isn't that all anyone ever uses??) =o)

<meta http-equiv="Page-Enter" content="RevealTrans(Duration=0,Transition=0)" />

Essentially, including this tag in the header of your page disables the use of the page until it has completely downloaded to the browser. Our users don't seem to mind, in fact, they prefer it over the old way because it reduces the "flicker" effect they were getting on postbacks.

Tweak the web.config

set in web.config

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

Just note the security implications of these!

I was getting this message because of a reference to a web control that had a nested form tag in the html.

If using master pages, try the same code without a reference to the master page. If it works, try taking all of the web controls/parts off and see if you can isolate the piece of code that is causing this.

We have a working .NET 1.1 Visual Studio 2003 web site http://www.working.com/_2006 which I copied to http://www.newlocation.com/events/relicensure/_2006 and then began upgrading to .NET 2.0 Visual Studio 2005 with a sitemap and master page as part of the redesign. Registration for the event was located in a subdirectory path just as a way of organizing the various pages; though this site has few pages in general: http://www.newlocation.com/events/relicensure/_2006/events/default.aspx

When I went to this registration page I got the Validation error when I clicked the "Add Registrant" button which would have run btnAddRegistrant_OnClick, except the error shows before the code is entered. I tried all the various fixes mentioned in this forum all to no avail.

What I also noticed was the the error occurred on page http://www.newlocation.com/events/relicensure/_2006/default.aspx and not on page http://www.newlocation.com/events/relicensure/_2006/events/default.aspx where it should have been occuring. My masterpage is using the <base/> tag (which I would prefer to avoid, but...), so I figured this might be the cause of the problem, but without it I have to hard-code many of the otherwise relative links, and the site will also be dual hosted at http://events.working.com/relicensure/2006/ so hard coded links would be bad.

Since I had a default page in both locations I decided to rename the /events/default.aspx to /events/addRegistrant.aspx which eliminated the Validation error, but caused an error saying /events/relicensure/_2006/addRegistrant.aspx could not be found. Which made sense in light of my previous observations but is totally confusing as to how the system was making this error.



The "obvious' solution was to move the files to the root instead of leaving them in the /events/ subdirectory. As soon as I move the files, the errors went away. I'll be picking up the problem here this morning; but I figured that some of you might be strugglng against a similar set of circumstances and find this work-around useful.

When using a GridView control on a default.aspx I am receiving the error message. My GridView is not visible until a subroutine is called when clicking a button. At that time I establish a database connection, populate my datareader and bind to the control. The error message appears on loading the page, not when calling the subroutine.

If I renamed the page to anything other than default.aspx, the error didnot appear and the page loaded.

I checked my [Virtual Directory] > Properties > Documents > Default Documents and noticed default.aspx was not listed (default.asp was). I added default.aspx and it worked like a champ.

I simply added 'default.aspx' to the Default Documents of my Virtual Directory.

Hi Guys,
I got the solution of this problem.
The cause of this problem is multiple form tag in page.
if you have any query please feel free to mail me.

Mahesh


Hi Guys,
I got the solution of this problem.
The cause of this problem is multiple form tag in pages.
if you have any query please feel free to mail me.

Mahesh

Override Page.Render and intercept the HTML output. Then you can use basic string manipulation techniques to find the VIEWSTATE (and any other hidden fields you want to move), remove them from the output stream, find the opening <form> tag, and insert it there.

-Josh Beall, jbeall (circlea) heraldic (smalldot) us

This is from DNN, and I haven't actually tested this myself. But it gives you the idea.

        Protected Overrides Sub Render(ByVal writer As System.Web.UI.HtmlTextWriter)
            Dim stringWriter As System.IO.StringWriter = New System.IO.StringWriter
            Dim htmlWriter As HtmlTextWriter = New HtmlTextWriter(stringWriter)
            MyBase.Render(htmlWriter)
            Dim html As String = stringWriter.ToString()
            Dim aspnet_formelems(2) As String
            aspnet_formelems(0) = "__EVENTTARGET"
            aspnet_formelems(1) = "__EVENTARGUMENT"
            aspnet_formelems(2) = "__VIEWSTATE"
            For Each elem As String In aspnet_formelems
                'Response.Write("input type=""hidden"" name=""" & abc.ToString & """")
                Dim StartPoint As Integer = html.IndexOf("<input type=""hidden"" name=""" & elem.ToString & """")
                If StartPoint >= 0 Then 'does __VIEWSTATE exist?
                    Dim EndPoint As Integer = html.IndexOf("/>", StartPoint) + 2
                    Dim ViewStateInput As String = html.Substring(StartPoint, EndPoint - StartPoint)
                    html = html.Remove(StartPoint, EndPoint - StartPoint)
                    Dim FormEndStart As Integer = html.IndexOf("</form>") - 1
                    If FormEndStart >= 0 Then
                        html = html.Insert(FormEndStart, ViewStateInput)
                    End If
                End If
            Next
            writer.Write(html)
        End Sub

Seeking to find out whether VS 2005 SP1 and/or .NET Framework 3.0 fixes this bug. In Microsoft's new versions and updates, has this bug now been fixed?

This is a class 1 bug threatening most ASP.NET applications. It is both unpredictable and fatal. Applications will crash on event validation with the diagnostic "Validation of viewstate MAC failed" if a user action causes a postback before a page has been fully interpreted. After the lapse of more than a year, Microsoft refused to fix the bug in then-current releases of the Visual Studio tools and .NET Framework.

The bug can be addressed by disabling event validation, but that is very risky because it is likely to expose other, even less predictable errors. It can be overcome by adding Jscript to hide all the controls that can cause troublesome postbacks until browser processing reaches the end of a page.

Well... this is not the most perfect answer, but I have a workaround to post:

(solves the problem in IE, anyways... isn't that all anyone ever uses??) =o)

<meta http-equiv="Page-Enter" content="RevealTrans(Duration=0,Transition=0)" />

Essentially, including this tag in the header of your page disables the use of the page until it has completely downloaded to the browser. Our users don't seem to mind, in fact, they prefer it over the old way because it reduces the "flicker" effect they were getting on postbacks.