Hi,
  I have only standard controls on the main page of my site. For certain users, sporadically, it's blowing up when they try to log in. I have seen others have this problem but nobody ever seems to reply or even look into it. Help?! Once users get into this state, it seems to be permanent until they delete their cookies and temporary files. This makes me think it's possibly a caching issue?

My Performance Settings Are:
  Page state persistence: Page
  Module Caching Method: Disk
  Performance Setting:   Light Caching
  Authenticated Cacheability: Public
  Compression Seetings: Deflate Compression

Has anyone else run into this? What was the resolution or the problem you found that caused it!?


A critical error has occurred.
DotNetNuke.Services.Exceptions.PageLoadException: Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request. --->

System.Web.HttpException: Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request. at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Page.LoadAllState() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) --- End of inner exception stack trace ---

Most often, I've seen this when user's session has timed out. The "session state" then no longer matches the current one. I don't believe that it is a caching issue, but it is a cookie issue.

Hopefully someone else has some ideas.

What settings do I need to change to increase the users session so it won't happen again? Having this come up a lot and expecting them to delete their cookies is unfortunately not going to cut it for any of us running a DNN site. Did you have any luck resolving it?

Here are some other things that probably are more important to timeout issues.

Do you have anything non-standard in your installation?

Do you have compression enabled in IIS? If you do, try disabling it.

Also, have you been playing with the performance variables available under Host Settings? If so, you should set Page State Persistence to Page and not Memory.

Here are John Mitchell's (snapsis.com) recommendations for DotNetNuke settings. I'd use them!

Page State Persistence: Page
You could try memory, but I believe there are too many problems here without much gain especially as a global setting.

Module Caching Method: Memory
Memory is much faster, and there are intermittent errors when using Disk.

Performance Setting: Heavy
There is really not much difference between the different settings here. The setting is just a multiplier that gives you only 5 hours of caching at the most (depending on the object) when on Heavy. Some items are not cached at all unless you are on Heavy.

Authenticated Cacheability: Set it to public.
This allows the client browser or downstream proxies to cache items.

Compression Setting: Deflate or Gzip does not matter.
They are both about the same and will vary depending on content. I use Gzip.

Compression Level: There is a bug that is keeping it from being applied, but it should be around five, higher than that gives diminishing return.

Use Whitespace Filter: Not Checked
Don't use it if you have compression on it is a waste of time, because compression also removes white space.

Joe,
   Thanks for the reply. I've checked my settings and they are all set to that except for the performance setting. I am currently having the site hosted on Sever Intellect and on Shared server. This undoubtedly means they have throttled both cpu and memory usage. I am unsure what happens to the ASP.NET worker process when the memory consumption exceeds the throttling, but I suspect it might be a bad thing. What are your thoughts on that matter?
  Are there also web.config settings that can cause problems with the sessions and cookies? There are all sorts of settings that appear to be strewn all over the place in there. I can't seem to dig up good information on the following items for example:

EnableCachePersistence
PersistentCookieTimeout
Forms
httpCookies
anonymousIdentification

Here are those settings as well:



  <form>s name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies"/>

    


 

Change the performance settings in DotNetNuke and see if that helps.