A Case of Invalid Viewstate


Last week I was helping a colleague of mine with a viewstate case that turned out to be pretty interesting…


Scenario


The customer was getting events similar to the following in the eventlog and needed to know why they occurred

Event Type: Information
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1316
Date: 2007-06-11
Time: 09:48:02
User: N/A
Computer: MYMACHINE

Description:


Event code: 4009
Event message: Viewstate verification failed. Reason: The viewstate supplied failed integrity check.
Event time: 2007-06-11 09:48:02
Event time (UTC): 2007-06-11 07:48:02
Event ID: 14cc57c05e834de98c7df506a013a706
Event sequence: 10
Event occurrence: 1
Event detail code: 50203


Application information:

Application domain: /LM/w3svc/1/root/MyApp-3-128260216693527710
Trust level: Full
Application Virtual Path: /MyApp
Application Path: c:\inetpub\wwwroot\MyApp\
Machine name: MYMACHINE


Process information:

Process ID: 3640
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE
Request information:
Request URL: http://mymachine/MyApp/MyWebForm.aspx
Request path: /TestBadViewstate/WebForm1.aspx
User host address: 127.0.0.1
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\NETWORK SERVICE


ViewStateException information:

Exception message: Invalid viewstate.
Client IP: 127.0.0.1
Port: 14644
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; WOW64; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04324.17; InfoPath.2)
PersistedState:
dDwxOTM2NzUxODMzO3Q8O2w8aTwxPjs+O2w8dDw7bDxpPDE+Oz47bDx0PHA8bDxfX0hlYWRpbmc7PjtsPENvdXJzZSBTZWFyY2g7Pj47bDxpPDE+Oz47bDx0PDtsPGk8MT47aTwzPjs+O2w…
Referer: http://SomeThirdPartySite.com/SomePage.htm
Path: /MyApp/MyWebForm.aspx


Custom event details:

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

 


And the callstack reported was:

[HttpException (0x80004005): 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.]

System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) +119
System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) +252
System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState) +5
System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState) +37
System.Web.UI.HiddenFieldPageStatePersister.Load() +222
System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +80
System.Web.UI.Page.LoadAllState() +35
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +9041
System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +217
System.Web.UI.Page.ProcessRequest() +85
System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +20
System.Web.UI.Page.ProcessRequest(HttpContext context) +110
ASP.MyPage_aspx.ProcessRequest(HttpContext context) +30
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +405
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +65


 




 


Troubleshooting


If you get viewstate errors on 1.1. and dont get events like the above, make sure that you have SP1 installed or at least a version of 1.1 later than http://support.microsoft.com/?id=831150  since this hotfix introduced the type of logging above, which is crucial to troubleshooting most viewstate errors.


Viewstate, as most of you know, is a Base64 encoded string containing information about the state of the controls on the webform.  To avoid tampering the viewstate is validated against the machine key, pagename etc. and if the string is either corrupt in some way such that it cant be Base64 decoded or such that it doesn’t pass validation you will get an error like the above.


Typically viewstate errors will occur if



  • You’re on a web farm and the machine keys are not consistent on all nodes

  • You’re on a web farm and the page is slightly different on one node than ot the others, for example if one node is upgraded to 2.0 and the other is still 1.1 or if some controls used on the page are built differently

For a more comprehensive list see: http://support.microsoft.com/?id=829743


 


In this particular case they had just upgraded to 2.0 from 1.1, they were not running on a web farm.  The error occurred intermittently and only on two specific pages, but most of the time these pages were served just fine without viewstate errors.


Since it is very unusual for errors like this to occur in a non-web farm scenario, especially intermittently, this issue was very curious.   I have seen that happen sometimes when the client was a mobile device and the viewstate was very large as some mobile devices will only send x kb of data so the issue there would be that the viewstate was corrupted because not all the viewstate was sent.   In this case the client was IE 7.0 so no such luck…


I used Fritz Onion’s viewstatedecoderr to decode the viewstate to verify that it wasn’t corrupted and sure enough the viewstate was just fine, the contents seemed to be fairly standard textboxes etc.


Lucky break


Lucky for me, and for them:)  I have seen enough encoded viewstate to know what viewstate is supposed to look like, so when i took another look at the eventlog entry i noticed that the persisted state started with dDw…    to most people this probably just looks like mumbojumbo but I happen to know that viewstate on 2.0 is supposed to start with /wE…  in fact when I browsed their site on the internet I could indeed see that the typical viewstate for these affected pages (from the hidden viewstate field in view source) was perfectly normal 2.0 viewstate while the dDw… that was sent to the page is typical for 1.1 viewstate.


Knowing this, the question is now, where does this 1.1. viewstate come from?   This is where the eventlog entry comes in handy again… and if you have jumped ahead a bit you have probably noticed by now that the referer is a htm page http://somethirdpartysite.com/SomePage.htm, in other words. there is nothing wrong with the site itself, the problem is that somehow this 3rd party site is posting 1.1. viewstate to the page, and of course that won’t validate well against the new 2.0 page.


Browsing to the 3rd party site and looking at the source for the htm file we can see what we already suspected… the page contains a form, with a hidden viewstate field and the post action for the form is our aspx page, so this 3rd party site apparently did a bit of a hack, copying the viewstate while this site was still 1.1. and posting that viewstate to the form… 


Technically, noone but the aspx page itself should really be allowed to post to the aspx page, so anytime the referer of a post to the aspx page is someone other than itself that is bad, and again, to guard against things like this the viewstate validation exists, but of course it might prove to cause a bit of a troubleshooting headache for you.


 


Conclusion


The solution in this case was to talk to the 3rd party site, let them know about the upgrade and ask them to avoid posting to the site but rather link to the site or redirect to it since there is no way of knowing how long viewstate will be valid as it can change with any type of upgrade to the page.


If there is a benefit to having the 3rd party site being able to post data and show the results in their proprietary format, a web service would be a pretty good solution.


 


Until next time


Tess








Comments (40)

  1. Steve says:

    As a regular reader of your blog, I was interested in read about this viewstate problem, as we were experience a very, very similar problem last week. The more I read, the more it sounded like our problem. The funny thing is it turned out to be us, and we had contacted PSS over this exact problem.

    Anyway, much thanks for your assistance is solving this problem and for the tips on decoding viewstate and different prefixing of viewstate in different .NET versions.

  2. Tess says:

    :) that is funny,  I hope you don’t mind me sharing the story…  

    I thought it was a really interesting case and made for a good gateway to discussing other common viewstate issues.

  3. Apple Safari for Windows and Microsoft Silverlight [Via: interactive ] Refactoring Dumb, Dumber, Dumbest…

  4. Last update: June 13 , 2007 Document version 0.6 Preface If you have something to add, or want to take

  5. William Luu says:

    Hi Tess, I’ve been having a very similar issue to what you’ve posted except I have no 3rd party websites posting to a ASP.NET 2.0 page.

    The referer and the Request URL are both the same (and the Event Log entry matches this).

    It’s currently happening to two pages (as far as I can tell), and the persisted state for both don’t start with /wE. The first erroring page has ViewState starting with "sod", and the second with "47x", both of which are obviously different to the two you’ve listed for .NET 1.1/2.0.

    Any help would be much appreciated. Thanks!

  6. Tess says:

    Hi William,

    I am not sure where you are grabbing the state from, if it is from the persistedstate that does seem a bit unusual that it would start with sod and 47x…  

    It is a bit hard to say what it could be without digging into it deeper, but have you checked to see that there is no mention of clients disconnecting?  A pretty common reason for "corrupt" viewstate, is that the page takes so long to load that clients shut down their viewstate prior to sending the whole post data, causing the viewstate not to be sent through properly.  However in such cases the client will never see the error, but it is still a concern since it is usually caused by really slow pages.

    Thanks

    Tess

  7. William Luu says:

    Hi Tess, I am taking it straight from the persisted viewstate.

    On occassion there is the odd "the client has disconnected" message come up, it just doesn’t come up as often as the Invalid viewstate message.

    Other details: I’m running ASP.NET Ajax on both of those pages. And on a third page that contains ASP.NET Ajax I can generate this invalid viewstate problem just by changing the selected index for a drop down box. The DropDownBox triggers an autopostback, which updates a GridView. One of the pages has a 3rd party component compiled against ASP.NET 1.1 (http://www.carlosag.net/Tools/WebChart/Default.aspx), could this be affecting it?

  8. Tim Cartwright says:

    I am in the same boat as William, except that my viewstate does start with /wEP. It was a postback from one of my own pages. Interestingly enough, the viewstate from the error would only decode properly using the 2.0 version of fritz’s viewstate decoder.

    I too am running Ajax, but no third party control on the page in question.

    Here is my exact viewstate, there is nothing sensitive in it, so decode away:

    /wEPDwUJNjIxMzEzMTU0D2QWAmYPZBYCAgMPZBYCAgMPZBYCAgkPZBYCZg9kFgJmDw8WAh4ISW1hZ2VVcmwFKy4uL0FwcF9UaGVtZXMvZGVmYXVsdC9pbWFnZXMvbmVlZF9mbGFzaC5wbmdkZGQyhrbmsVJZRX/8lG0EOlJrO+vVYg==

  9. Tess says:

    If you have a component compiled against the 1.1 framework, storing its own viewstate that could potentially cause viewstate errors.  I would try a modified version of the page without this control and see if you still get the viewstate errors…

  10. Tim Cartwright says:

    Unfortunately I do not have one to remove. :( The only 3rd party control on this page’s control tree is an atlas scriptmanager.

  11. Tim Cartwright says:

    I just noticed. Every single error that this occurred on, was from Safari on a Mac. Not sure it is relevant. Just seems odd.

  12. Tess says:

    Hi Tim,

    The comment regarding compiled against 1.1. was based on that it was the same issue as william reported.

    The fact that it always occurrs from Safari on Mac is definitely interesting,  I’m not too familiar with the details of this browser but it might be that this page has very large viewstate and that there is a limit to how much Safari will post,  a lot of browsers have such a limit, especially on mobile devices (not saying that Mac is a mobile device though:)),  in any case i would say it is extremely relevant unless your site is specifically targeted to users on Mac so that the safari browser for Mac is highly represented amongst the clients.

  13. Tim Cartwright says:

    You are correct Tess, I think that is what I am experiencing. This is the user agent for every single error:

    Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/522.11.1 (KHTML, like Gecko) Version/3.0.3 Safari/522.12.1

    Turns out they are using the beta 3 of Safari which we did not test against. The viewstate for the page in question is quite large. I am going to try to figure out a way around this.

  14. This is a very interesting post and a good discussion.

    One more question about the logged viewstate error though… in the exception itself, what does the port number mean?

    Exception message: Invalid viewstate.

    Client IP: 127.0.0.1

    Port: 14644

    User-Agent: Mozilla/4.0…

    When I see these viewstate errors on my webfarm, I see various ports listed, all of which seem to be non-standard. Any help would be appreciated.

  15. Tess says:

    The port is the port used by the client to communicate with the server, which uniquely identifies the client.  

    For example if you have two browsers open going to the same site, each of them will open its own socket and get its own port (typically a port number over 5000) and communicate over this.

    Practically for troubleshooting viewstate errors knowing the client port is only interesting if you are grabbing network traces as well.

    The fact that the client ip is localhost is a bit curious, but I am guessing that is because you are testing from the server itself…

    Thanks

    Tess

  16. William Pierce says:

    I am encountering a strange error with viewstate on my ASP.net 2.0 app. This is running on a Windows 2003 R2 Server non-web farm environment (IIS 6.0).

    Here is the gist of it.  I have a default.aspx page that is the login page of the application.  I can login with my userid and password, click ‘submit’ and I am logged in.  Now I click on ‘Logout’ from within the app.  This logs me out and the app does a Response.Redirect to the default.aspx (which is the login page).  

    Now I do nothing on this page for (approx) 1 hour.  When I then try to login, I get the viewstate error.  This occurs deterministically.

    Any clues?

    — WP

  17. Try clearing your browsers cache / temporary internet files (especially you, William). This solved the problem for me.

    Apparently my browser cached a form containing a no longer valid vievstate. So when the form was submitted it gave this error.

    A Ctrl + F5 (tells IE to bypass all caches and proxies and go grab the latest version) on the form itself actually solved it, but clearing all temporary internet files should also do the trick.

  18. Taha says:

    Hi Tess,

    Great post, cleared a lot of concepts in my mind. I am getting a weird intermittent Invalid_Viewstate error.

    Some of our .NET 1.1 applications throw these intermittent viewstate errors and the viewstate in the exception all starts with a /we. I was able to decode the viewstate using the 2.0 decoder as well. We have no third party sites linking to our web applications. We are running on a web farm, and the machine validation keys are the same for the web servers.

    Can you suggest what else we should be looking for?

  19. Reddy says:

    To my understanding invalid viewstate could also occur if page is posted before the page is completely loaded.

    Our solution was to catch the exception and redirect to a friendly error message page asking the user to wait until the page is downloaded completely. We also implemented 4GuysFromRolla solution on graying to page until it is loaded completely.

  20. Jeff says:

    Safari will post viewstate from a previous page on a redirect.  At the suggestion of another forum, we explicitly turn off auto-fill on the hidden fields (__VIEWSTATE, etc; document element .setAttribute(‘autocomplete’, ‘off’)) and in code behind we’ve set: HttpContext.Current.Response.Cache.SetNoStore()

    But we still get viewstate content from Safari that is not the viewstate we served.  All other form fields are from the right page; it’s the content of the viewstate that is incorrect (i.e posted to page A, but clearly belonging to page B).

  21. Tess says:

    not exactly sure how that could be.  the viewstate is just a form field so unless there is a transfer or some redirect i dont see how the form fields would swithc pages.  Would be interesting to see in the eventlogs who it lists as the referrer to see if it is a different page…

  22. Sat says:

    Its not that much clear. can u tell clearly, wat to do when we get issue like Viewstate verification failed. Reason: The viewstate supplied failed integrity check.

  23. FYI: I vote no to it helping solve my problem, but I learnt something new which is more valuable. You should have a "Did this post benefit you?" rather than did resolve the issue.

  24. Santi says:

    Hi Tess,

    I am finding this problem. I now that you can’t post from one page to a different one. I notice in this log entry that the referer and the requested URL only differ in the port (the requested url uses port 81, whereas the referer comes from the implicit port (80). Will this difference cause the viewstate to fail the check?

    Event Type: 9/10/2008 4:24:52 PM

    Event Source: ASP.NET 2.0.50727.0

    Event Category: Web Event

    Event ID: 1316

    User: N/A

    Event code: 4009

    Event message: Viewstate verification failed. Reason: Viewstate was invalid.

    Event time: 9/10/2008 4:24:52 PM

    Event time (UTC): 9/10/2008 11:24:52 PM

    Event ID: 7e68e559612f408797f12d656be75dd9

    Event sequence: 67724

    Event occurrence: 14

    Event detail code: 50204

    Application information:

       Application domain: /LM/W3SVC/2/root-1-128655536206151424

       Trust level: Full

       Application Virtual Path: /

       Application Path: D:MySiteXXXXXXXXXXXWeb

       Machine name: DAA30140WWW004

    Process information:

       Process ID: 5136

       Process name: w3wp.exe

       Account name: NT AUTHORITYNETWORK SERVICE

    Request information:

       Request URL: http://xx.mysite.com:81/Evaluations/EvalLaunch.aspx?loid=dd22c304-a48e-4bc9-b59e-141784a5d9a7&evalLvl=5&redirect_url=..Viewstate verification failed. Reason: Viewstate was invalid.fLMSViewstate verification failed. Reason: Viewstate was invalid.fUserTranscriptViewstate verification failed. Reason: Viewstate was invalid.fMainView.aspx

       Request path: /Evaluations/EvalLaunch.aspx

       User host address: 100.222.222.125

       User:  

       Is authenticated: False

       Authentication Type:  

       Thread account name: DOMAINiusr1

    ViewStateException information:

       Exception message: Invalid viewstate.

       Client IP: 100.222.222.125

       Port: 48510

       User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

       PersistedState: /wEP…

       Referer: https://xx.mysite.com/Evaluations/EvalLaunch.aspx?loid=dd22c304-a48e-4bc9-b59e-141784a5d9a7&evalLvl=5&redirect_url=..Viewstate verification failed. Reason: Viewstate was invalid.fLMSViewstate verification failed. Reason: Viewstate was invalid.fUserTranscriptViewstate verification failed. Reason: Viewstate was invalid.fMainView.aspx

       Path: /Evaluations/EvalLaunch.aspx

    Custom event details:

  25. Molecules says:

    I was having a problem with the viewstate as well.  I am fairly new to .net and was having a difficult go at the viewstate error.  After attempting a few fixes I read online, I noticed that I had a warning from my form tag in my html.  

    I had forgotten that I was using a masterpage, which already had the form tag in it.  I was running the program on my pc and did not know it was a problem till I moved the app to a more formal dev server.

  26. Richard says:

    Wow, brains and beauty! two reasons while i’ll be visiting your blog again…:-)

  27. If you work with web sites in a complex/multi server environment you might be familiar with this error

  28. Sridhar says:

    The comments in here helped me to nail down my issue.

    In my case the FORM tag had the action URL to be a different one other than the current page where the postbacks meant to perform certrain actions. Once having the current page in that place, all is working fine now.

    But I still have a doubt that these changes are not required for a Windows 2003 Enterprise edition+SP2. This error was readily reproduced on a W2K3 R2 standard edition. Are there any settings that one need to look out in the R2 editions to correct this issue?

  29. Sridhar says:

    The comments in here helped me to nail down my issue.

    In my case the FORM tag had the action URL to be a different one other than the current page where the postbacks meant to perform certrain actions. Once having the current page in that place, all is working fine now.

    But I still have a doubt that these changes are not required for a Windows 2003 Enterprise edition+SP2. This error was readily reproduced on a W2K3 R2 standard edition. Are there any settings that one need to look out in the R2 editions to correct this issue?

  30. Tess says:

    Sridhar,

    This should not be platform dependent…

    Tess

  31. Hari says:

    ok.. May be you can comemnt on this.. I wish there is a method for page object or a static method some where in the library that helps me call something like IsValidViewState()..(Just like how they have introduced TryParse…) That we we can ignore through code as oppposed to throwing an exception..(I can understand why they have this exception thrown) I wish there is an event that fires before this exception is thrown so that we get a chance to check for it as devolopers…Reson being there are so many spasmmers out there whose sole purpose seems to be to just cause this exception..I am sure you would agree with me that cause any exceptions to happen like very few seconds..is not good………..(I know there are other mechanisms like ip blocking and smart defense ect…)

    I wish this is true for validation exception when some one enters html in querysttring…..These exceptions are such a pain..Though I have not seen yet any performance impact because of these exceptions by spasmer and bots…I am just curious what your thoughts are

  32. Hi Tess,

    We are also facing the problem with ViewState corruption.

    Our scenario is as follows :-

    We login to mobDefault.aspx.

    This page get refresh every 60 seconds. We have used following tags in <head> tag of the page

       <META HTTP-EQUIV="REFRESH" CONTENT="60">

       <META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">

    (we have also tried javascript setTimeout)

    We get the ViewState corruption error on the first Refresh

    but that if we refresh the page manually the error dosen’t occur.

    We have also noticed that error occurs only if we leave the page idle till the First Auto Refresh event fires. But if click on some other link and then come back to orignial position the Viewstate error is not shown.

    Just FYI.

    * We are not using WebFarm.

    * There is no reference to any 3rd party control or Page.

    * This error is shown only on Mobile Browser (I.E 7.0)

    * It work fine on Opera Mobile and also Desktop Browser.

    Error is as follows:

    Server Error in ‘/Caveman’ Application.

    Validation of viewstate MAC failed………………..

    ……………………………………………………………………………………………………

    ……………….

    Stack Trace:

    [HttpException (0x80004005): Unable to validate data.]

      System.Web.Configuration.MachineKeySection.GetDecodedData(Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Int32& dataLength) +289

      System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) +140

    [ViewStateException: Invalid viewstate.

    Client IP: 82.132.136.161

    Port: 41776

    User-Agent: Xda_orbit_2/240×320 (compatible; MSIE 6.0; Windows CE; IEMobile 7.11)

    ViewState: /wEXAQUDX19QD2QPBhzGKXiEkcuIZq7MBnDmV2mxi/PjOP9yPINPDPrw

    Referer:

    Path: /Caveman/MobilePages/mobDefault.aspx]

    [HttpException (0x80004005): 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.]

      System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) +106

      System.Web.UI.ViewStateException.ThrowMacValidationError(Exception inner, String persistedState) +14

      System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) +242

      System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState) +4

      System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState) +37

      System.Web.UI.HiddenFieldPageStatePersister.Load() +207

      System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +105

      System.Web.UI.Page.LoadAllState() +43

      System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +6785

      System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +242

      System.Web.UI.Page.ProcessRequest() +80

      System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +21

      System.Web.UI.Page.ProcessRequest(HttpContext context) +49

      ASP.mobilepages_mobdefault_aspx.ProcessRequest(HttpContext context) +37

      System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +181

      System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75

    Version Information: Microsoft .NET Framework Version:2.0.50727.3082; ASP.NET Version:2.0.50727.3082

    thanks in advance

    Regards

    Abhijit

  33. Doug Osborne says:

    Tess,

    We are seeing the same this – our viewstate begins with /wEP – but right after this error we have a second error

    (Server001) – Large event record (33932 bytes): possible attack on event log

    Could our viewstate be too large?

    Thanks,

    Doug

  34. Tess says:

    That’s a definite possiiblity:)  There is no "real" limits on how large it can be, but given that message I would do view source on the page and save out the viewstate to check how big it is.  If the viewstate is very big it can cause various issues like bandwidth issues, clients disconnecting because it takes to long to download etc.

    One of the most common viewstate exceptions is actually client disconnect errors where clients shut down the browser or press stop before the full viewstate is copied down, but you can see that in the error message

  35. Eric Chabot says:

    Thanks for the great post.  This for sure enlight me in the mystery world of the viewstate.  I was still under the belief that the browser were all using port 80 but now that I read your post I understand a bit better.  

    I am also having an issue with the viewstate and this have been going on for years and I never figured out what is really going on or never find a good resource that was able to answer.   My site is hosted on a share environment(no web farm) so I cannot access the Log Viewer.  However I get the errors sent by email each time a problem occur.  I am not able to reproduce the error and all I can say is that I received many errors like this every day.  My thought was that some funny guy somewhere in india or else was trying to hack my site but maybe it’s not the case.  Anyway I would appreciate if I could have you opinion on this.

    Error:

    =============

    Message

    Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

    Source

    System.Web

    StackTrace

    at System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) at System.Web.UI.ViewStateException.ThrowMacValidationError(Exception inner, String persistedState) at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) at System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState) at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState) at System.Web.UI.HiddenFieldPageStatePersister.Load() at System.Web.UI.Page.LoadPageStateFromPersistenceMedium() at System.Web.UI.Page.LoadAllState() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest() at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) at System.Web.UI.Page.ProcessRequest(HttpContext context) at ASP.company_contact_aspx.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

    Inner Exception

    Invalid viewstate. Client IP: 195.216.197.102 Port: 2777 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322) ViewState: /wEPDwUKMTA0ODg1NDczOA9kFgICAw9kFjwCAw9kFgICBA88KwAJAgAPFgYeDFNlbGVjdGVkTm9kZQUOTmF2MV9teVRyZWV0NDceDU5ldmVyRXhwYW5kZWRkHgtfIURhdGFCb3VuZGdkCBQrAAIFAzA6MBQrAAIWEB4EVGV4dAUESG9tZR4LTmF2aWdhdGVVcmwFDn4vZGVmYXVsdC5hc3B4HgxTZWxlY3RBY3Rpb24LKi5TeXN0ZW0uV2ViLlVJLldlYkNvbnRyb2xzLlRyZWVOb2RlU2VsZWN0QWN0aW9uAh4IRGF0YVBhdGgFIC8qW3Bvc2l0aW9uKCk9MV0vKltwb3NpdGlvbigpPTFdHglEYXRhQm91bmRnHhBQb3B1bGF0ZU9uRGVtYW5kaB4IRXhwYW5kZWRnHglQb3B1bGF0ZWRnFCsA Referer: http://www.clemex.com/Company/Contact.aspx Path: /Company/Contact.aspx

    =============

  36. Nikolay Petukhov says:

    The thread is great, but it goes into tricky details, and does not explain some simple cases, like one machine, application pool.

    For a novice getting "Viewstate verification failed. Reason: The viewstate supplied failed integrity check." I would recommend reading http://www.codeproject.com/kb/aspnet/machineKey.aspx and http://msdn.microsoft.com/en-us/library/ms998288.aspx

  37. mcm says:

    Do you know much about the ASP.NET Oracle Padding Vulnerability Security Patch and how that has affected viewstate processing?

    Before the patch was applied all our Invalid Viewstates spread out over the 100 websites we've developed and host were on ScriptResource.axd and WebResource.axd handlers (error message only says invalid viewstate, but contians stacktraces) broken out by browser and error count as follows:

    Pre-patch (2009-05-01 -> 2010-09-29)

    IE8 5222

    IE7 363

    IE6 171

    Firefox 9

    Opera 0

    Safari 0

    Chrome 0

    Our underatanding is that there was a IE8 bug (now fixed but people may not have the patch) with speculative downloading of scripts that causes an invalid viewstate error but the scripts still get downloaded and has no effect on end user experience.

    However, after the patch was applied the invalid viewstates no longer occurrs on the script handlers and instead occurs on aspx pages (error message now contains client ip, port, useragent etc with no stacktrace) broken out by browser and error count below:

    Post-patch (2010-09-29 -> 2011-01-19)

    IE8 565

    IE7 179

    IE6 2420

    Firefox 358

    Opera 231

    Safari 223

    Chrome 110

    Thanks,

    Michael

    csolutions.co.nz

  38. Mayank Vyas says:

    Removing " action="pagename….aspx" " from form tag fixed this error: Event message: Viewstate verification failed. Reason: Viewstate was invalid.

  39. hemant says:

    let me now about this error message problem  please solve and tell me.

    Event code: 3005

    Event message: An unhandled exception has occurred.

    Event time: 11/10/2012 1:47:06 AM

    Event time (UTC): 11/9/2012 8:17:06 PM

    Event ID: 31884226b9af4854a5d30df7b9e7c0e0

    Event sequence: 18525

    Event occurrence: 2

    Event detail code: 0

    Process information:

       Process ID: 6200

       Process name: w3wp.exe

       Account name: NT AUTHORITYNETWORK SERVICE

    Exception information:

       Exception type: FormatException

       Exception message: Input string was not in a correct format.

  40. Derrick Okundaye says:

    Hi Tess,

    What if the 3rd party is an e-commerce payment portal trying to use your site's payment confirmation page and you (tried) to remove all references to __viewstate?