Thursday, January 16, 2014

Windows update crashes ASP.NET web application using EnableEventValidation and EnableViewStateMac

I recently got woken up due to a production web application I am responsible for being down.  Most of the reports indicated the users were not getting .net errors, it simply was not responding to their requests for data.

When I logged onto the site, and navigated to the problem area, I was greated with this error: "A potentially dangerous Request.Form value was detected from the client"; along with the recommendation to disable EnableEventValidation if the error were incorrect.

In an effort to just get the site back up and running I flipped the switch on that page variable.  I'm not sure why the clients never saw the error, but as soon as I flipped that variable I started seeing the same problem that they were reporting; no errors, just no response to requests for data.

Since my development server was functioning perfectly I had to use Response.Write 's on the production server to start tracking down what was going on.  I was shocked to learn that the Page.IsPostBack variable was always returning true.  I got the site functioning again by finding an alternative variable I could use in its place.

With the problem under control efforts were redirected to figuring out what triggered my bad morning.

My co-worker discovered that windows updates had been applied by our hosting company to our production server.  Through the good old fashioned method of uninstalling until things started working again, he discovered that KB2894842 and KB2894843 were the culprits.  Apparently Microsoft had found a security flaw in pages that had EnableViewStateMac turned off and the fix had resulted in some rather odd results for our site.

EnableViewStateMac was turned off for our site because we were using javascript to submit data from one page to another.  It was necessary to avoid the postback mac validation error "Validation of viewstate MAC failed".  A better option might have been to use strictly .NET controls to handle postback, however it was an old site that originated in classic ASP and the javascript has always worked very well.

Later versions of .NET now have the ability to post to other pages on the site using the PostBackUrl attribute built into some controls.  I was hoping to capture the javascript generated by such a control and use it to modify my stand alone javascript to enable it to perform a successful post to the next page.

I was disappointed to discover that using the PostBackUrl attribute not only generated additional .NET javascript, but also created a __PREVIOUSPAGE hidden field with a hash value for the next page to validate.  However, I was pleasantly surprised to find out that as long as any control was rendered with that attribute then my original javascript was able to submit the page successfully with no errors.  In fact my site was now able to function with EnableViewStateMac turned on giving me back that additional piece of security.

The compromise I finally settled on was adding a button with a PostBackUrl to my master page and hiding it with CSS.

I am still not sure why the Page.IsPostBack variable stopped functioning correctly and that is part of what prompted this post.  Hopefully if I, or anyone else, runs into a similar problem in the future there will be a place to start looking due to this.


  1. Really very good informative blog.It is a most beneficial writing.I got more information by go through this content.

  2. I got your compromise which you settled on adding a button with a PostBackUrl to your master page and hiding it with CSS. But it need a conclusion for this same with think better to go for some research on it....Thank you for such a idea..

  3. Hello,

    Did you find out why post back is functioning incorrectly?.

  4. No, I turned view state Mac on, and haven't had time to look into it more.

  5. Just to make sure. You don't need to turn on the MAC, this patch will enable that automatically. your application running by using postbackurl so that it will create __Previouspage which will make sure that your post back is working corrently in page 2.

    1. In my case my application did not work correctly unless I did turn Mac on once the patch was applied.

      Post back url was how I got my post back to be accepted once Mac was turned on.

  6. but the PostBackUrl attribute is used for cross-page posting!

  7. A hotfix was released which contained the fix of IsPostback issue. You may want to install the hotfix. Here are the KBs.

  8. Very nice, thank-you for posting. It's always nice to see someone from Microsoft taking care of our problems.

    We are upgrading our entire production environment to Windows 2012 and the latest and greatest of everything, so those hotfixes should be part of my new system.

  9. Hi Jereme:

    Thank you very much for this post. It was really helpful

    We found same error today in our production environment "Page.IsPostBack variable was always returning true" and we was modifying our code using additional variables like you did. But thanks to your post we identified the Windows Update (KB2894844) that it causes issue, we un-installed it and everything works fine again.

    Thank you!

  10. That is great Ruben.
    According to a post above yours, by Fei from Microsoft, an additional hotfix was released to fix what this hotfix broke. If you are in the middle of playing on production anyway you might try installing that to see if it correctly solves the security issue Microsoft was trying to patch without introducing errors into your site.


Please leave your thoughts, I love hearing what you got out of the post. Spam comments will be removed.