Hi:

We are seeing this error recently on a page containing both listview and a datalist control since upgrading to Net3.5 SP1. The machine key is correctly set in the webconfig and all other pages are working correctly. The webserver is not on a web farm, nor in a web garden. And I will repeat, a machine key is set correctly in the web.config.

Enable or disable viewstate at the page level did not help. Disable viewstatemac at the page level did not help. We do not want to disableviewstatemac in web.config for security reasons. EnableEventValidation is set to false at the page level.

We are seeing an encryptedviewstate with "" as a value in the page source. We have tried putting the listview inside an update panel. That did not help. We also tried naming the DataKeyField and leaving it out of the datalist control.

We are using URL rewriting, and also use a Form.Browser that overwrites the page action attribute because of the url rewriting and all is well on the entire website, except this one page.

Thoughts?

TIA,

Bill

From.. http://blogs.msdn.com/tess/archive/2009/04/14/validation-of-viewstate-mac-failed-after-installing-net-3-5-sp1.aspx

This will happen if you have specified an action on the forms element, and if the action is different than the page you are browsing to..

Vijay:

I am familiar with that link, unfortunately it does not apply. The form action attribute is the same as the page url that is being posted back to, because of the form.browser rewritting the action attribute.

Cheers,

Bill

Bill,

We are also using .NET 3.5 Service Pack 1, but never came across that error. Even post made by asp.net team, mentions action attribute as the reason for that error.

If you belive it's a bug, report it here..

http://connect.microsoft.com/

Vijay:

The  asp.net team has several "fixes" posted all semi-related to each other. Some proffer an empty __viewstateencrypted as the cause, other asp.net team posts believe the issue  is somehow related to asp.net dropping off chunks of viewstate and thus not decrypting correctly, others find the "post" attribute to blame. We have seven major retail websites running just fine on SP1, and all pages of the website under discussion run just fine under SP1, it is only this page that is having a problem - and I think that is because it contains a listview with an embeded repeater.

If you examine the server application log, the error message is usually "Padding is invalid and cannot be removed". Googling that little gem will lead you to a disagreement between the asp.net and the IE teams as to the root cause. Take a look at related for "Padding is invalide and cannot be removed". Note, this message will only be seen in the server application log. 

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997&wa=wsignin1.0

After over a week of chasing the proverbial tail, I am under the distinct impression that Redmond knows this is a BUG (not an issue) and really does not know how to deal with it.

Cheers,

Bill

Vijay;

FWIW, removing the action attribute from the page directive entirely has no effect at all. Rather shoots that first aspnet team link in the ole url.

Cheers,

Bill

Bill_H:

If you examine the server application log, the error message is usually "Padding is invalid and cannot be removed". Googling that little gem will lead you to a disagreement between the asp.net and the IE teams as to the root cause. Take a look at related for "Padding is invalide and cannot be removed". Note, this message will only be seen in the server application log. 

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997&wa=wsignin1.0

After over a week of chasing the proverbial tail, I am under the distinct impression that Redmond knows this is a BUG (not an issue) and really does not know how to deal with it.

wow, That's really bad!! Lets hope IE team fixes this issue in the next update.

Vijay:

There are a lot of related "issues" that will appear on the top end, such as webresource.axd issues, ajax failed to load, invalid viewstate, viewstatemac failure when the underlying problems are more systemically complex. The usual bandaids are machine key,  turning off viewstatemac (instead of getting to the cause) there are even some recommendations from MS to remove http-equiv="Content-Type"content="text/html; charset=UTF-8 from the page head as that seems to be sometimes causing fixed amounts of viewstate to lop off at random times and thus viewstate either fails or does not decrypt. We see these problems appear, disappear, and reappear at bizarre times when no code changes have occured. Logic would then blame the server or the server OS, but other websites are running on the same environment flawlessly.

The ONLY real consistant parameter is that this seems to occur on websites that have been converted from Net 1.0 up. New websites built are not having these issues. I suspect somewhere therein is the rub, and most of the developers I have spoken with have the same feeling.

I hope this will eventually get somebody to resolve this, but I suspect that MS is far too interested in moving us to MVC etc to devote much resources to regression testing of "legacy" code bugs. Most of MS "stuff" seems to work fine in "Hello World" test scenarios, but when you get into multiples of millions of lines of code, then the seams seem to show.

Sincerely,

Bill

just add the following in your web.config

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

<machineKey
validationKey="3D4AD683962FB6FB0117A6A09A97FDFEC87F8803F08BB2828F71D599AFF9D70D9A4E93DFCD2A27A1E9DB0DE135AA2ACAE1BFC3BBD8598385E95F06A4229ED7BE"
decryptionKey="23956661B77D4ED1C865B6998EC6CE9DF5E75C8BA5A6B1793BD071213CA434A3"
validation="SHA1" decryption="AES"
/>

hi,

check this

http://support.microsoft.com/default.aspx?scid=kb;en-us;555353

Owaisyahya:

Please read the starting post. Bluntly put, neither of your suggestions are relevant. I stated TWICE that a machine key is already  in place, and enableeventvalidation is not relelvant to the issue and has been in place since Net 2.0 release.

Bill

KDevendra:

That link is from 2005, long before Net 3.5 SP1 and the changeds that SP caused, and basically implicates the machine key point, of which I stated twice, a machine key is in place.

Best,

Bill

Anyone found a decent resolution to this issue? I have spoken with tech support at a number of server farms, since 3.5 SP1 they are seeing tons of these errors on working websites that already have machine keys installed, with no server farm or garden. Some speculate it has to do with how SP1 changed handling the "action" attribute of web forms. This will also be found in the application logs as "Padding is invalid and cannot be removed". Anyone found a solution?

TIA,

Bill

As I said in the intial post, we already use URLrewriting, applicaltion wide, which has nothing whatsoever to do with this issue. But I hope this is a nice plug for your book.... 

Rick:

I wanted to do some regression testing to explore your thoughts before I replied in further detail. We tested on a whitebox development server, as well as using VS development server. As I mentioned earlier, we thought we started to see this issue appear not long after the lastest patch to 3.5 SP1.

We moved the white box forward applying MS updates and testing between updates. The basic configuration is a large commercial retail website running sqlserver and net 3.5 with URL rewriting. Clean fast code, compression and white space removal.  Everything was fine until the last patch of Net 3.5. Bank, the app log was once again full of "Padding is invalid and cannot be removed" and upper level errors were viewstate mac.

So, we pulled the URL rewriting handler out and the problem stopped. There is obviously a conflict between what we use for url rewriting and the lastest SP1 and at the moment I suspect it the treatment of the "action' attribute in the form. We have used a method call in App_Browser to handle the action attribute so at to achieve the "actionless" form used by most URL rewriting handlers.

Thats as far as we have gotten to date, other production issues have consumed considerable time since my last post.

Best,

Bill