Invalid Viewstate

I am getting an invalid viewstate exception every time the session times out. Everything works fine on my local development machine but fails to work on discountasp.net. Basically, every time the session times out and I click on any button or anything that posts back, the invalid viewstate exception occurs. I have looked into existing issues causing this exception such as using Server.Transfer and I am not using any. Also, keep in mind that it works fine on a local machine. Has anyone experienced this problem on discountasp.net before? Any ideas why this is happening?

Thanks,
Dmitry

 

Bruce, thank you for your reply. It does sound like the only logical explanation. We are running IIS 5.0 locally, that is why we never experienced this problem. What would you recommend doing in this case? It seems like every application which is idle long enough will have this problem. Usually, session timeout is there to help you deal with it. We redirect a user back to the login page when it happens. But with this ISS setting you might get an exception sometimes. As far as I see it, even if we set the session timeout lower than the ISS setting, we might still get the problem if the application is idle for a long time.

Please advise.

Thank you,
Dmitry Peskin

 

I'm having the same problem. The time out is way too short.

 

How's the eval going? I am hitting this on my communities starter kit site.


quote:Originally posted by bruce

Thanks for your recommendation

We'll evaluate the possibility to increase the timeout.

quote:Originally posted by michaelw

I'm having the same problem. The time out is way too short.
</blockquote id="quote"></font id="quote">
</blockquote id="quote"></font id="quote">

Jon
(Information doesn't want to be free, it wants to be sixty-nine cents @ pound)

 

quote:Originally posted by bruce

Not completed yet.

This is a huge project because it affects how many customers we put onto a box, how much memory we need in a box, etc....


quote:Originally posted by JonO

How's the eval going? I am hitting this on my communities starter kit site.


quote:Originally posted by bruce

Thanks for your recommendation

We'll evaluate the possibility to increase the timeout.

quote:Originally posted by michaelw

I'm having the same problem. The time out is way too short.
</blockquote id="quote"></font id="quote">
</blockquote id="quote"></font id="quote">

Jon
(Information doesn't want to be free, it wants to be sixty-nine cents @ pound)
</blockquote id="quote"></font id="quote">
</blockquote id="quote"></font id="quote">

 

We have a long form on one of our client's sites. This form can take a user a little while to fill out. If the user takes too long they receive the "The viewstate is invalid for this page and might be corrupted" error. I'd really like to avoid breaking the form into multiple parts. Do you know of any work around this timeout.

Also if you could give me a status on the eval that would be great.

In the meantime I'll be looking for a work around.

Thanks,
bajdev

 

After further research it appears the viewstate can be captured in the global.asax Application_Error event, however since the process is terminated the viewstate is gone so the user essentially would have to start the form over.

The default timeout on the worker process is set to infinite. While I appreciate you are trying to get more performance out of your servers (I certianly would), this is serious issue with my client's apps, and my guess everyone else's, since anyone who takes awhile to fill in a form (steps away for coffee, takes a call, etc) will get a server error.

If there isn't a work around and the timeout won't be changed, is it possible to move over to a Win2k server.

Thanks,
bajdev

 

Hi There,

I am also receiving this error. Are we absolutely convinced that the session timeout problem is the real issue? I disabled sessions on my web site by setting the <sessionState> mode="Off" setting in my web.config file, but still receive the error!

I found one reference at ASP.NET forums which suggested the error can also be caused by un-synchronised machine keys across a web farm. Could that be the problem?

The address of the post is:

http://www.asp.net/Forums/ShowPost.aspx?tabindex=1&PostID=277267

Can I say that I think this is a *very* important issue. This is the first issue I've had with you guys, which I can see from the other posts is taking some time to resolve. Please, can we get it solved.

Thanks in Advance,
Trevor Andrew

 

Hi There,

I realised afterwards that I had neglected to check the Page level directive regarding sessionState, so I changed that for the page that I'm seeing the errors on, and the problem still occurs.

I should point out however that in something of a contradiction to what I mentioned before, the problem does seem to occur *only* once a session (if one is indeed being established) is idle for a period of time, which would lean towards the session timeout explanation mentioned earlier.

I am however still perplexed as to why a session expiring would be sufficient to invalidate a viewstate *unless* I'm then going back to a server with a different machine ID. I'm still puzzled!

Regards,
Trevor Andrew

 

Any update on the status of this?

We really like your hosting. This is the only issue we have run into with you guys. However this is a *major* issue and I really don't want to have to move our clients.

Thanks,
bajdev

 

I *may* have a workaround for this problem.

The approach I have used that *appears* to overcome the viewstate corruption issue involves providing specific validation and decryption keys within the <machineKey> section of my web.config file. Previously, I had no <machineKey> section, and I assume I was implicitly using the settings from the machine.config file.

The process for generating these keys is outlined in the Microsoft Knowledge Base article below.

http://support.microsoft.com/default.aspx?scid=kb;en-us;312906

It involves writing a small C# console application that creates an appropriate <machineKey> section with specific key values, as opposed to auto generated ones. The text it creates is ready for cutting and pasting into a web.config file.

And that appears to have overcome *my* problems. I have left my pages idle for over 15 minutes, returned to them and re-posted them back, and all *appears* to work well. I'm continuing to test as we speak. Even though my site isn't hosted on a web farm, this approach of having specific keys appears closely related to the solution recommended by Microsoft with regard to web farms, and perhaps it is related to specific "worker processes" having different validation and decryption keys?

I hope this approach *may* help others with similar or related problems!

I should say that the suggestion to try this came from Dino Esposito, the author of the Microsoft Press Book "Programming ASP.NET", who kindly responded to a question of mine regarding this issue. BTW, I can highly recommened his book. It covers more deeply some of the more important issues of ASP.NET programming than some other texts I've seen.

Regards,
Trevor Andrew

 

Did you all fix this problem or extend the timeout?

I don't seem to be having a problem anymore. Just checking.

Thanks,
bajdev

 

Ah true, cool deal, just wondering.

Thanks for the info,
bajdev

 

I was having the same issue on an application that my company was hosting. Didn't appear in dev or test, but once I deployed to the production environment I would get the view state errors once a session timed out. I followed the steps in the microsoft article (well, actually I changed the program to a windows form instead of a console application), and installed the keys in the web.config file, and the problem appears to be solved. Thanks for the good information--

DN

 

quote:Originally posted by bruce

No. We are still working to fix the problem.
</blockquote id="quote"></font id="quote">

Bruce,

Is there an update on this. I host a very modest (somewhat small, but generally can take > 10 minutes) form and the timeout value is too short. I am getting more complaints than submittions.

Thanks in advance,
Burg

Burg
---------
We have enough youth, how about a fountain of Smart?

 

Bruce,

Thanks for all your help on this.

BTW. What is the session timeout value?

Thanks

Burg
---------
We have enough youth, how about a fountain of Smart?

 

Hi,
I am also gettin the same Viewstate error contantly from the site. I can't able to simulate this error from my side. I think this problem is because of some lower version of OS or Browser using by the client. I am not sure its my observation.Out of 10,000 hits i am geting nearly 20 viewstate errors. Please if naybody knows how to stop it just mail me the solution.

Thank You.
vel

 

1) at the "Default Web Site" node in IIS, at the "Properties" dialog, at the "Web Site" page, it has an "HTTP Keep-alives enabled" checkbox (it's used by browsers to reuse the same connection channel when getting images and other data related to one page fetch, so that they don't open many connections - so it may not be related to the problem, so just being suspicious). Is this checked?

2) Also supposing above is checked, is there a chance the web browser client isn't using HTTP1.1 or something and having a problem by not using HTTP Keep-alives? I'd suggest trying with latest Internet Explorer (with default options [see Advanced options, check the "HTTP 1.1" option]) and latest Netscape Navigator and see if the behaviour differs in any of those settings


~~~~~~~~~~~~~~~~~~~~~~~~
George Birbilis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ QuickTime VCL and ActiveX controls (for PowerPoint/VB/Delphi etc.)
+ Plugs VCL and ActiveX controls (InterProcess/Internet communication)
+ TransFormations, VB6 forms to ASP.net WebForms convertion
http://www.kagi.com/birbilis
+ Robotics
http://www.mech.upatras.gr/~robgroup
.........................

 

see also:
http://www.dotnet247.com/247reference/msgs/30/154803.aspx
http://www.dotnet247.com/247reference/msgs/32/163740.aspx

this one too (may have already been mentioned):
http://support.microsoft.com/default.aspx?scid=kb;en-us;323744

I read somewhere that the URL that generated the webpage is used as a key to find its implementation. But in a project of mine, I'm adding a #bookmark to the URL that may be different, depending on where you came to that page from (using it so that at page return I go back to the appropriate bookmark on the page that brought me there so that autoscrolling to that bookmark position is done by the browser).

So I wonder whether using such different URLs (with different bookmarks) by different concurrent users to access the same page may be causing it, though I still think this is of low probability

will try the idea of storing the viewstate at the server instead of at the client page (which is very handy since client pages will load faster [only have to modify the Mat.Reynold's approach to work with many pages viewed at the same time by one client])