Thursday, April 30, 2009

This issue is caused when the ScriptResource.axd querystring parameters can not be decoded on the server. This error can be caused from multiple issues with server configuration or the Browser's interaction with the server.
The ScriptResource.axd contains all of the clientside javascript routines for Ajax. Just because you include a scriptmanager that loads a script file it will never appear as a ScriptResource.AXD - instead it will be merely passed as the .js file you send if you reference a external script file. In other words it is what the Microsoft Ajax libraries inject into your HTML to allow them to access their javascript functions they need for page manipulation.
ASP.NET will use the machine key to encrypt the ScriptResource.axd (and webresource.axd) url's parameters(in querystring), and by default the machinekey is a randomly generated one which may involve the current time. By default there is a different machinekey on every machine, and it changes when the application (w3svc.exe process) is recycled.
If you are running a web farm you need to "hard code" the machinekey to be the same for every server. This way a response from one web server can be decrypted on another server. Like in the case one of your servers goes down for maintenance and the users traffic is routed to another server.
You also need to "hard code" the machine key if you want to "survive" application recycles.
Here is instructions for "hard coding" the machine key:
http://msdn.microsoft.com/en-us/library/ms998288.aspx
BUT WAIT....
This error can be caused from a number of different issues. One of which is having the wrong DOCTYPE for the style of page you are writing. Especially with Internet Explorer 8.
This error can be caused from having a DOCTYPE of XHTML. This is because with XHTML all special characters should be encoded or all content should be wrapped inside a CDATA section. In other words if you don't have prefect XHTML in some cases the browser will not parse your XHTML correctly and the request to /ScriptResource.axd will have scrambled parameters
Converting the DOCTYPE to HTML can solve the Viewstate issue.

Why does this solve the issue? The browser uses a different parsing algorithm which is "looser" and can handle the non-compliant XHTML that you might be outputting.
One trick mentioned on the Internet to prevent the "Error : /ScriptResource.axd : Invalid viewstate." without having to change the DOCTYPE is to wrap your javascript in CDATA tags like this:

<script>
mycode;
</script>

would become:

<script>// <![CDATA[
mycode;
// ]]></script>

Which is an attempt to get XHTML compliant. However, I have found that while this is good practice, there are probably other issues what will cause your HTML not be XMHTL compliant and changing DOCTYPES are the best policy.
{6230289B-5BEE-409e-932A-2F01FA407A92}

Thanks for this post, this problem has been driving me insane and its great to see a workaround. But I've checked my XHTML against the W3C checker and it says it's compliant. So, it appears to be a bug in IE 7/8. You're implying that it's our fault, not IE. :)

I wasn't really thinking fault. Just solution. There are many things to get mad at IE about -- how IE renders differently then other browsers for example. However, in the end, I need to find solutions with the things I can change, live with the ones I can't change and know the difference between the two.

End of the day, the fix mentioned above isn't a global solution for anyone. Yes, you will have to rollback your CSS and retro-fit, but in addition, this doesn't cover all the possible conditions where the IE 8 parser will restart.

For example, if you have added an out of the box Master Page to your .Net application you have the vanilla namespace:

xmlns="http://www.w3.org/1999/xhtml"

most likely, well this will cause the parser to restart as well. There is still no exhaustive list from MS that covers all parser restart scenerios.

So I'd advise reviewing all resources and taking suggestions with a grain of salt, because there is no 100% answer to this problem and frankly, large scale applications which are already completed, DO NOT have a solution, you can't retro fit backwards when you are in production.