>The default encoding for ViewState uses base64 encoding with the MIME character set (A-Z,a-z,0-9) so the case-sensitivity is critical. Even if it were not any change to ViewState on the browser would result in an invalid hash code so ASP.NET would reject it.
>
>You have a few options:
>
>(a) Change where ViewState is stored. You can do this by overriding the PageStatePersister property of a page.
>There's a ready built SessionPageStatePersister class which will store it as a session variable on the server. The main problem there is that it will disappear if the session expires (and won't work on a farm)
>You can also create your own. e.g. create a class that saves state to a SQL table.
>
>(b) Create a sub-class of the HiddenFieldPageStatePersister which uses a custom IStateFormatter. This will allow you to use a different mechanism for encoding/decoding the ViewState.
>
>(c) Return a snide message regarding their browser behaviour :-}
>
>TBH I don't see much point in implementing (b) since it's *always' open to corruption (whether deliberate or otherwise) on the browser.
>
>Option (a) OTOH can have other side benefits. If, for example, ViewState contains a LOT of data you avoid round tripping that over the wire. The SQL option is handy where a different server might get the postback.
>
>Personally I'd stick to option (c).......

This error happens before I can take over the hit. ASP.NET does the high level decryption of that ViewState. So, I cannot send a message. However, it goes into my error handler. So, I will trap for that specific error and forward elsewhere.

Thanks for the information