Anyone else experiencing this error? It happens upon a postback. Here's the details: 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. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.Web.HttpException: 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.
Try disabling ViewstateMac by setting 'enableViewStateMac' in your web.config file to false. Another way to handle this is to configure your .Net application to use a predefined key rather then using an auto generated key.
Thank you Ray. I'll look into this and provide a follow-up when I get it resolved. Wayne Larimore http://www.Waynester.net/blog
This seemed to have resolved the problem overall. However, it did come up once post-change. It doesn't occur consistently though. I'll monitor it and report any additional findings / resolutions. Wayne Larimore http://www.Waynester.Net/blog
Can you confirm you disabled viewstate rather than set a key and that it has permanently fixed the issue? Thanks.
I have this error too after I moved my client's app to Winhost last week. I am confused because I put in a ticket and they said it is because my app pool was recycled which happens when: 1) More than 20 minutes of idle time (no http request in 20 minutes) 2) The application uses more than 100 MB memory 3) The application uses more than 75% of CPU time 1 is not the case. I find it really hard to believe 2 or 3 are happening. It just does a simple select from an Access database, hardly any logic at all. I added enableviewstatemac = "false" to the aspx file and at the moment I'm not seeing it, but it is intermittent so I don't know if it is really gone. If anyone has more info on this I would greatly appreciate it. I am compiling with VS2005 - would it be any better if I was compiling with 2008? -Harriet
They are right - it is because the app pool is recycling but it is not 1,2 or 3. It is 4 Remove the reference you added in your aspx file and then go to http://aspnetresources.com/tools/keycreator.aspx and then add the code generated at that site to your web.config file in the <system.web> section. It fixed the problems I was having.
Thanks so much for responding. So is the idea that if I generate my own key, it can't become invalid? Can you help me understand the big picture here - this app has been fine for years on IIS 6. Then when I migrated it to Winhost this error started appearing intermittently. Does it mean that my app is really doing something that is recycling the app pool?
The big picture is about all I can give you I'm afraid. Winhost uses IIS 7 and there are changes between the two that matter Probably the most important as far as we are concerned is security. Also, in a shared host environment (as in Winhost - and probably your previous provider as well) there is obviously a security implication and hence the need for keys to ensure one application doesn't connect to another application without authority. If you like - IIS7 behaves a bit like the UAC I suppose. As usual with web servers - no individual really understands all of their workings and if you are an expert in any of the specifics you are probably a nerd and can't express yourself in a written language other than code anyhow. If there is what IIS7 sees as a possible security breach then it is logical for a recycle of the app pool to occur so we can call that 'trigger number 72'. I'm sure 4 thru 71 will become clear in the fullness of time I know I'm ranting but I can't help myself BTW - What do you mean by 'it can't become invalid?'. No one's supposed to be able to access your web.config file except you so if you accept that as gospel then no - 'it' can't become invalid. I'm not certain if anything of this will 'fix' whatever is happening to your application but it fixed my problems and that's all I can help with I'm afraid. If it doesn't fix it then please post again with some more details of how your app does what it does and I'll see if there's some flaw in the methodology you have employed that is creating trigger number 42. Good luck.
Sorry if I'm saying things oddly, I'm trying to get used to the terminology here. Since the error was: Validation of viewstate MAC failed I thought that meant the server determined that it didn't think my viewstate was still valid for some reason (as though it had been tampered with). That's what I meant by "now it can't become invalid". I was thinking that since your suggestion would force a static key, the key can't have been wiped out by recycling the app pool. Both suggestions seem to work for me: 1. putting enableviewstatemac="false" in the page or 2. adding the generated key to web.config I'm mostly just trying to wrap my head around how you move older IIS 6 based apps to IIS 7 with the least problems. I have many client's apps to move - this is the first so I'm learning everything on this one. Other fun things I've learned in the last week are how ISAPI Rewrites can mess up paths in response.redirects and not having trust level=full makes it hard to move apps that use resources from other apps. Today was "viewstate MAC" day
Have a look at this post http://learn.iis.net/page.aspx/624/application-pool-identities/ It will start you on the way if you have nothing better to do for a few hours. I'm only guessing but I think there are considerably more triggers for the Application Poll to be recycled apart from the 3 mentioned by Winhost support In all fairness though, very few ISP's are going to debug your web application for you and at Winhosts prices I really can't expect them to have suitably qualified experts on hand 24/7 to help us mere mortals
Try checking out this link. You should be able to easily generate a machine key using the IIS 7 Manager/Machine Key Module. http://technet.microsoft.com/en-us/library/cc755177(WS.10).aspx
hi, After trying all solutions, I solved this problem by adding in the web.config <system.web> <pages maxPageStateFieldLength="30" enableEventValidation="false" enableViewStateMac="false" viewStateEncryptionMode="Never"></pages> </system.web> maxPageStateFieldLength="30" is very important
This works perfect! Thank you! <system.web> <pages maxPageStateFieldLength="30" enableEventValidation="false" enableViewStateMac="false" viewStateEncryptionMode="Never"></pages> </system.web> what is maxPageStateFieldLength for?
Actually, the error is caused by a security violation not a config error Actually, the error is caused by a security violation not a config error, normally a man-in-the-middle-exploit. Disabling the enableViewStateMac just turns off the built in .Net security feature that detects such security violations. Generating a static validationKey/decryptionKey lets the intruder copy the key and set it up on their man-in-the-middle proxy so they are not detected by .Net. So these steps will make the site work again, but with zero security.
IIs 7 Manager actually has a tool to gnerate a machine key for you. If you connect to the web server using IIS 7 manager, go to the Machine Key module. On the left hand side click on Generate Key and will generate it. You'll have a choice of different hash models from SHA1 to AES
