Unable to validate data

[mikeachamberlain]

Hello.

On our website we occasionally get the dreaded error:

Exception:
System.Web.HttpException
Unable to validate data.

Stack trace:
at System.Web.Configuration.MachineKey.GetDecodedData(Byte[] buf,
Byte[] modifier, Int32 start, Int32 length, Int32& dataLength)
at System.Web.UI.LosFormatter.Deserialize(String input)

Viewstate (example):
dDwtMjk4NDUyOTEyOzs+HhqaxzF2H593HEX/Hn/ArvKK7AU=

Machine Key tag from Web.config (modified slightly here for security):
<machineKey
validationKey='XXXXXXXXXXXXXXXX1B81214A550B89F2A318B3712FB5AC8CD82AF4F3925B3C6ED58CF5F38503629A78BF8C27B1B736C4E84DACE342AB83A42932B44EBC3D7601'
decryptionKey='XXXXXXXXXXXXXXXX3133028CBD4E6EEFC45B5E609D7F4107'
validation='SHA1'/>

I have scoured google for months trying to solve this problem. I can
confirm:

- we are not using a cluster / webfarm
- we are not using any Server.Transfers (eg. the viewstate is being
posted back to the correct page as far as we can see)
- we have manually set the encryption / decryption key in Web.config as
above
- the site runs in its own application pool, and recycling of the
worker process is disabled

The site will run fine for weeks, then suddenly we may get a multiple
instances of these come through at once from at least two different
users. It is only ever on one specific page though. This page does
not create any controls dynamically.

The example viewstate above does indeed appear to be invalid when we
try to run it through a view state decoder.

I am completely stuck and the boss is losing patience! Can anyone
help?

Mike

 

[Mark Rae]

Can anyone help?

I had exactly the same problem - one only one page - on only one of my
sites.

Touch wood, the upgrade to v2 seems to have fixed it inasmuch as I've not
had one single instance of it since around the beginning of December when I
deployed the v2 version.

 

[mikeachamberlain]

I had exactly the same problem - one only one page - on only one of my
sites.

Touch wood, the upgrade to v2 seems to have fixed it inasmuch as I've not
had one single instance of it since around the beginning of December when I
deployed the v2 version.

We believe it has to be a problem on the client rather than the server.
The only thing different about the page that gives the error is that
it is redirected to using a javascript redirect or a meta refresh
(depending on the browser). Despite the fact that we have disabled
client caching (or so we believe), we think that this redirect could be
causing badly behaved clients to be posting back an old version of tha
page.

We have now removed this client redirect to see if solves the issue. I
will report back once we know more.

Mike