Failed to load viewstate.

Discussion in 'ASP.NET / ASP.NET Core' started by dbireporter, Mar 7, 2010.

  1. I load Page1. Then I navigate to Page2.
    In Page2 I make a FormView visible.
    I click on the FormView Cancel button, which navigates to Page2 again to refresh it.
    Then I navigate back to Page1 and get the "Failed to load viewstate...." error msg.
    Any idea what I can do to avoid this error?
     
  2. The examples address pages where controls are dynamically added.
    In my case, I am not adding controls, but I am making controls visible and then not visible.
    I do have controls with the same name on different pages.
    Would naming controls on different pages with unique names be a good idea?
    Could this be causing the problem?
    Thanks.
     
  3. Hi,
    Well...I'm a bit rusty but did a lot of testing on this, even for a few Microsoft teams.
    You can probably get some good tips in the official ASP.NET forums.
    What I've had to do at times, the C9 team also, was disable viewstate on resulting pages.
    I'm not suggesting that but it does work. ;-)
    All the best,
    Mark
     
  4. Update to this problem

    Some information of interest. This was a real bear to debug.

    Validation of viewstate MAC failed...where is the fix?

    UPDATE: after going through a bunch of posts, it boils down to this: either this bug of ASP.NET is related to an error caused by the programmer, or, it’s because DiscountASP.NET is not allowing the user to have enough memory. In my case I think it’s the latter. No fault of DiscountASP.NET, just pointing out what my research showed. In my case, I ‘solved’ this problem by simply reducing the time it took my program to do certain calculations—in the long run, it was a blessing in disguise as it made my web app run faster. My updated comments appear inline below.

    PJ

    See this blog (and all comments in it):

    http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx

    and here: "In my case, this error was caused by hitting a site memory cap instituted by my web hosting company. They increased my limit and it went away."


    I see somebody else here had nearly the same problem, but the link is now broken:

    http://community.discountasp.net/showthread.php?t=7169&highlight=autogenerate


    My problem seems similar. I am navigating using Session variables from one page (a source.aspx page) to another (a destination .aspx page). My program works fine on DiscountASP.NET if it runs for less than two minutes, but if the program is working more than 2.5 minutes (because it has threads, is multithreaded, and a certain thread sometimes takes up to a half hour to complete), you get the below error. I also use “Master” pages as templates, which some people blame for this problem.

    On Visual Studio 2008 ASP.NET 3.5 with the built in localhost server I have no problems, even after a half hour running the program, but that is on my own localhost hard drive. But here on DiscountASP.NET I'm having this problem after less than five minutes but greater than 2 minutes.

    I tried certain easy suggestions found on the net like: setting these parameters on your destination page: EnableViewStateMac="false" EnableViewState="false" but this did not work.

    Also I eliminated Transfer.Server and replaced it with Response.Redirect on the source page (but that did not work, as expected, since these two commands are nearly identical anyway). Also I changed Server.Transfer("WebFormDestinationPage.aspx", true); to  Server.Transfer("WebFormDestinationPage.aspx", false); //this helps says the net—and so I did it, based on this suggestion: http://support.microsoft.com/kb/316920/

    The only thing I can think of: DiscountASP.NET requires, as a security default and because apparently ASP.NET 3.5 suggests this, that a certain hash key / public key be used for anytime server side code for a page is running more than 2 minutes (since this error almost always occurs at 2.5 to 2.75 minutes after the program thread starts). I guess this is to prevent the page from being hijacked. *UPDATE: this is somewhat true—adding the machineKey parameter below does not hurt, and probably helps.

    UPDATE--THEREFORE: I added, using this online tool: http://aspnetresources.com/tools/keycreator.aspx the following lines in my Web.config file:

    BUT THIS IS NOT ALLOWED ON DISCOUNT ASP.NET--SO SCRAP

    <machineKey
    validationKey="0A5A3A7C3BBF2DF27F71B8E43EBA5631D205C2688D18A7E7A258C417E7DD8F0D5A47BBE7CDF0EF598C76000F723B15F7BA6394E835DB6CD4BBE0E04962236CED"
    decryptionKey="10CEC1165CC68A422513A29AB31311186902B0F4BCD7CD4FD8FB5DF5F7419A43"
    validation="SHA1"
    decryption="AES"
    />

    The important phrase in the below error message (I'm pretty sure) is this: 'AutoGenerate cannot be used in a cluster. '. On my localhost machine, there's no cluster, but clearly DiscountASP.NET's servers are in a cluster. (TURNS OUT THIS IS NOT THE REAL ISSUE—YOU CAN GET THIS ERROR EVEN ON A SINGLE SERVER)

    What is this key? (SEE ABOVE) Can I use any kind of key like a GUID or is it a special format? (SEE ABOVE, USE THE ONLINE TOOL TO GENERATE IT) How do I set it in the source code? Where, in the Web.config file maybe? (SEE ABOVE, YES). Why did the link above from this site disappear? It seems it had the answer. (another clue is here: http://support.microsoft.com/kb/312906 and here:
    http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx and here: "In my case, this error was caused by hitting a site memory cap instituted by my web hosting company. They increased my limit and it went away."


    Thanks a lot! I like this company, it's very kind to programmers.

    PJ

    Below is the error given by the browser (with a few details like my IP address taken out).

    UPDATE: sometimes this error is given instead of the below: Service Unavailable
    HTTP Error 503. The service is unavailable.
    and the server times out for about 2 minutes.

    Error message:

    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.


    Server Error in '/MyApplication_' Application.
    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.

    Source Error:

    [No relevant source lines]


    Source File: c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\MyWebProgram_\f9926566\d99a1721\App_Web_dfutbzxj.5.cs Line: 0

    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:
    Port:
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
    ViewState:
    Referer: ]

    [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.]
    Files\MyWebProgram_\f9926566\d99a1721\App_Web_dfutbzxj.5.cs:0
    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.4200; ASP.NET Version:2.0.50727.4016
     
  5. BUT THIS IS NOT ALLOWED ON DISCOUNT ASP.NET--SO SCRAP? No--it's irrelevant--program works either way: make sure you ratify after publishling (FTP) via Visual Studio on DiscountASP.NET according to this tool: https://my.discountasp.net/webapplication-tool.aspx

    Update to the update: the "<machineKey validationKey" issue is completely irrelevant to this problem--though I ended up putting it in since it did not seem to hurt. leaving it out is also not a problem. Make sure you follow the steps here of course when publishing from inside of Visual Studio 2008: http://support.discountasp.net/KB/a...ual-studio-20082005-visual-web-developer.aspx
     
  6. I also will point out that the old program does not throw an error when I run it during "off hours" at DiscountASP.NET. So this shows it was an error such as pointed out in the thread above "In my case, this error was caused by hitting a site memory cap instituted by my web hosting company. They increased my limit and it went away."

    Either DiscountASP.NET increased my limit, or, just as likely, when there's not a lot of load on the servers at DiscountASP.NET, the program will run fine. Just something to keep in mind if you plan on deploying bandwidth heavy applications--either get an increased memory allotment from DiscountASP.NET, or, like I did (and even better) streamline your program so it's not such a resource hog.
     
  7. mjp

    mjp

    This is coincidental. Time of day has no effect on memory available to your site.

    Server load also does not affect available memory. It can affect available CPU resources. But that applies to any shared server, not just ours.

    The only way to do that is to move from IIS6 to IIS7. The memory quotas are fixed for each platform and cannot be increased.

    That's always the best solution because you get the added benefit of better site performance overall.
     

Share This Page