Error : /ScriptResource.axd : Invalid viewstate.

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.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
To This:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
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}

Comments

  1. So what is the root of this problem? And why does it happen only with IE8? Will there be an update to ASP.NET AJAX to fix this?

    ReplyDelete
  2. 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. :)

    ReplyDelete
  3. 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.

    ReplyDelete
  4. Im gonna try this out, and if it works - you are the king.
    I'm busting my brains for weeks on this problem.

    ReplyDelete
  5. There are other reasons also for this as I understand :
    1. That your HTML is not correct.
    2. Dynamic server controls which alter the control tree of your aspx page.

    ReplyDelete
  6. anybody tested for
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 1.0 Transitional/EN">

    instead of
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 ransitional//EN">

    the problem solve with HTML 1.0 as well? If i change to HTML 4.0 the styles seem to be mess up so just wondering anybody try with HTML 1.0

    ReplyDelete
  7. This fixed my Invalid Viewstate errors but broke my css. Am I missing something?

    ReplyDelete
  8. lol, nope, you are not missing anything. It broke mine as well. I'm gonna live with the errors instead of trying to figure out each and every CSS rule change I'd have to handle.

    ReplyDelete
  9. HTML 1.0? Old school shlong bags!

    ReplyDelete
  10. So that means problem exists as it is there is no one who can provide the right solution...

    ReplyDelete
  11. I suggest looking here:

    http://blogs.msdn.com/ieinternals/archive/2009/07/27/Bugs-in-the-IE8-Lookahead-Downloader.aspx

    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.

    ReplyDelete
  12. Exactly what I was looking for

    Thanks =)

    ReplyDelete
  13. Hi,

    Is this problem related to the "the 4kb bug"?
    Is this fixed in the IE8 Cumulative Update (KB980182)?

    Thanks,
    Ariel

    ReplyDelete
  14. Thanks man it worked.

    ReplyDelete

Post a Comment

Popular posts from this blog

Yet once more into the breech (of altered programming logic)

Simple WP7 Mango App for Background Tasks, Toast, and Tiles: Code Explanation

How to convert SVG data to a Png Image file Using InkScape