The viewstate is invalid for this page and might be corrupted problem

[Hardy Wang]

Hi all:
I developed a web site, it passed various testing internally. When I put
this site in production, I receive some error reports from this site saying
"the viewstate is invalid for this page and might be corrupted". I am
wandering what kind of client side problem may cause this error? Is it
possible that user uses a browser which has local cache turned on all the
time?

Thanks for any suggestion.

 

[Cowboy \(Gregory A. Beamer\)]

Viewstate is the values, et al, of page controls, stored in a hidden field,
that is sent back to the server. It is unlikely a client error. More likely
is a machine setting, not having viewState enabled in your app/page, or a
combination of both. If you are passing from page to page with viewState,
you increase the chance of problems.

Look at enableViewStat and enableViewStateMac. Depending on server set up,
you will set one or both. Play around a bit, as I do not have the info in
front of me. Dinking with enableViewStateMac saved one of our apps. I
mention both, as I do not want to send you down a road and not give other
options.

 

[Hardy Wang]

I am pretty sure, I have enabled viewstate in my application and all web
pages. I don't use viewstate to pass information to other pages, just self
post-back.

From my machine, I even cannot reproduce this error in both development and
production machines. I tested from internal LAN and external dial-up
network, application works fine in all situation.

So I just cannot understand well why this will happen.

 

[Hardy Wang]

Hi:
What I have in this page is some standard controls, with a ASCX file,
which includes some other standard controls. I think they should be a
problem.

 

[Graham]

Hardy,

If you create any dynamic controls make sure that you recreate the control
tree the same way it existed when the page was orignally rendered and sent
off to the browser client. LoadViewState can actually occur at several
points in the life-cycle even though it only "shows up" in most life-cycle
diagrams in one place (immediately after Init). As long as the nesting of
controls is consistent with the original rendering of the page, controls
will "catch-up" in the life-cycle when they are added dynamically (say in
OnLoad, which happens after LoadViewState).

If a control wants its viewstate but it is out of sequence with where it
originally was the page framework gets angry and raises the exception you
received. When I have this problem, dynamic controls created out of
sequence is almost always the reason.

Do you programmatically added any controls to Control collections? e.g.
Controls.Add(new Button())

Best regards,
Graham.

 

[Hardy Wang]

I did not programmatically add any controls to Control collections. All my
controls are defined design-time. So that is the reason I feel very
headache.