If you’re seeing viewstate errors like “The viewstate is invalid for this page and might be corrupted” here’s the dealio. For security ASP.NET encrypts the viewstate using an Autogenerated Key that is generated when your application pool (or worker process) is started. At AppliedI.net (and many hosts today) each website is placed in a unique application pool so your site is isolated from the other sites on the server. If your application pool recycles for whatever reason, the viewstate key will change and when you go to post back to your application is may fail with the gloriously informative error of:
“The viewstate is invalid for this page and might be corrupted”.
What’s causing the application pool to do this?
Your application pool is recycling due most likely to a couple things:
- you edited your web.config and that caused the change (not likely)
- IIS was reset on the server and that caused the change (less likely)
- Your application errored out causing the application pool to recycle (possible)
- Your application pool reached a memory limit and was forced to recycle (I put my money on the #4 horse to win! this is probably it)
All hosts today that use dedicated application pools, isolated application pools or “website sandboxing” whatever they may called also set a memory limit on the application pool in shared hosting, some set it more aggressively than others. The advanced web applications of today are using more and more resources as they are more and more complex, it’s not uncommon to find a web application using anywhere from 150-350MB of memory today, although the average is still just in the range of 80-120MB.
The good news is you have options on how to get around this.
- You can upgrade your shared hosting account to an account that has a higher memory limit. At appliedi.net we offer 4 different shared hosting accounts each with separate memory limits.
- You can upgrade to a VPS hosting account or dedicated hosting account and set an even higher memory limit.
- You can completely disable the viewstatemac by adding “enableViewStateMac=”false” in your web.config. This would be a bad thing though and you can google viewstate injection for why this is bad.
- You can generate a predefined key and stop using the default autogenerated key method.
#4 is probably the route you’ll want to go. My recommendation is to go with #1 first and not just because I work for a hosting company and want to see you spend more money per month. I recommend you upgrade your hosting account to an account that has a reasonable memory limit for your application because every time that application pool recycles your site is going to be slow as it recompiles and initializes the application. You also just lost your session state information so if you’re an ecommerce site and your client was in the middle of a checkout, they probably just lost their cart contents and have to start over.
Creating a predefined viewstatemac key
The guys over at www.aspnetresources.com have a keycreator tool that makes generating your own predefined viewstatemac key effortless. To do this you’d do the following
- visit: http://www.aspnetresources.com/tools/keycreator.aspx and use it to build a key
- Copy this key into your applications web.config file between <system.web> and </system.web>
- Save your web.config file and test your application to make sure it still works. If for some reason it doesn’t work, you can delete the changes and revert back.
Where to learn more
There’s always google. But Microsoft has a pretty extensive article in their KB at: http://support.microsoft.com/default.aspx?scid=kb;EN-US;829743 that will also help. If this sounds like something that’s happening to you at AppliedI.net on your ASP.NET hosting account please contact our support team and they’ll be happy to help you troubleshoot the issue.
