Invalid_Viewstate

[Guest]

I have a production asp.net application that is getting seemingly random
Viewstate errors.

It is a single server, so there isn't any issue with posting viewstate to a
different server that what it was received from. Also, it happens with users
that have to go through a firewall and users that don't.

It happens across the a broad array of pages, most of them are simple grid
pages that you can drill down into to collect more input data.

Also, the viewstate size is typically 5-30K depending on the page. Never
gets anywhere near 1024K.

We have also installed sp1 for the 1.1 release of the .net framework, so we
can collect more detailed viewstate errors.

I'll post the most typical error that we get in a follow up message.

If anybody knows what actually causes this I would be very interested in
knowing. A resolution would be even better.

Chris Sutton

 

[Guest]

This is the stack with the error message. I have removed the viewstate to
save on some space, it definitely looks like it is truncating the viewstate
though:

<Exception>System.Web.HttpException: Invalid_Viewstate
Client IP: 64.167.38.121
Port: 1531
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 1.1.4322)
ViewState:
Http-Referer:
Path: /Reports/Default.aspx. ---> System.Web.HttpException: Authentication
of viewstate failed. 1) If this is a cluster, edit <machineKey>
configuration so all servers use the same validationKey and validation
algorithm. AutoGenerate cannot be used in a cluster. 2) Viewstate can only
be posted back to the same page. 3) The viewstate for this page might be
corrupted. ---> System.Web.HttpException: Unable to validate data.
at System.Web.Configuration.MachineKey.GetDecodedData(Byte[] buf, Byte[]
modifier, Int32 start, Int32 length, Int32& dataLength)
at System.Web.UI.LosFormatter.Deserialize(String input)
--- End of inner exception stack trace ---
at System.Web.UI.LosFormatter.Deserialize(String input)
at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
--- End of inner exception stack trace ---
at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
at System.Web.UI.Page.LoadPageViewState()
at System.Web.UI.Page.ProcessRequestMain()</Exception>

 

[Guest]

We have found two ways this error can be reproduced now. If you have a page
that has been served with viewate in it, and then you change the credentials
on the worker process, it will throw a viewstate error when you post back.

Also, if the worker process recycles in between posts on a given page (a
fairly common scenario) we are throwing a viewstate error.

Once again, this is a single server (not a garden or farm). It is a two
processor server though, if that makes a difference.

The second scenario seem like it would more likely be our problem. But why
would a recycled worker process cause a viewstate error?

Any suggestions here would be great.

Chris

This is the stack with the error message. I have removed the viewstate to
save on some space, it definitely looks like it is truncating the viewstate
though:

<Exception>System.Web.HttpException: Invalid_Viewstate
Client IP: 64.167.38.121
Port: 1531
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 1.1.4322)
ViewState:
Http-Referer:
Path: /Reports/Default.aspx. ---> System.Web.HttpException: Authentication
of viewstate failed. 1) If this is a cluster, edit <machineKey>
configuration so all servers use the same validationKey and validation
algorithm. AutoGenerate cannot be used in a cluster. 2) Viewstate can only
be posted back to the same page. 3) The viewstate for this page might be
corrupted. ---> System.Web.HttpException: Unable to validate data.
at System.Web.Configuration.MachineKey.GetDecodedData(Byte[] buf, Byte[]
modifier, Int32 start, Int32 length, Int32& dataLength)
at System.Web.UI.LosFormatter.Deserialize(String input)
--- End of inner exception stack trace ---
at System.Web.UI.LosFormatter.Deserialize(String input)
at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
--- End of inner exception stack trace ---
at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
at System.Web.UI.Page.LoadPageViewState()
at System.Web.UI.Page.ProcessRequestMain()</Exception>

I have a production asp.net application that is getting seemingly random
Viewstate errors.

It is a single server, so there isn't any issue with posting viewstate to a
different server that what it was received from. Also, it happens with users
that have to go through a firewall and users that don't.

It happens across the a broad array of pages, most of them are simple grid
pages that you can drill down into to collect more input data.

Also, the viewstate size is typically 5-30K depending on the page. Never
gets anywhere near 1024K.

We have also installed sp1 for the 1.1 release of the .net framework, so we
can collect more detailed viewstate errors.

I'll post the most typical error that we get in a follow up message.

If anybody knows what actually causes this I would be very interested in
knowing. A resolution would be even better.

Chris Sutton

 

[Alvin Bruney [MVP - ASP.NET]]

Chris,
This is not the case. The viewstate issue seems to be a new issue that I am
digging into. If you have any other relevant information, please don't
hesitate to send it to me at (e-mail address removed) subject: Invalid Viewstate

--
Regards,
Alvin Bruney - ASP.NET MVP

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc

We have found two ways this error can be reproduced now. If you have a
page
that has been served with viewate in it, and then you change the
credentials
on the worker process, it will throw a viewstate error when you post back.

Also, if the worker process recycles in between posts on a given page (a
fairly common scenario) we are throwing a viewstate error.

Once again, this is a single server (not a garden or farm). It is a two
processor server though, if that makes a difference.

The second scenario seem like it would more likely be our problem. But
why
would a recycled worker process cause a viewstate error?

Any suggestions here would be great.

Chris

This is the stack with the error message. I have removed the viewstate
to
save on some space, it definitely looks like it is truncating the
viewstate
though:

<Exception>System.Web.HttpException: Invalid_Viewstate
Client IP: 64.167.38.121
Port: 1531
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 1.1.4322)
ViewState:
Http-Referer:
Path: /Reports/Default.aspx. ---> System.Web.HttpException:
Authentication
of viewstate failed. 1) If this is a cluster, edit <machineKey>
configuration so all servers use the same validationKey and validation
algorithm. AutoGenerate cannot be used in a cluster. 2) Viewstate can
only
be posted back to the same page. 3) The viewstate for this page might be
corrupted. ---> System.Web.HttpException: Unable to validate data.
at System.Web.Configuration.MachineKey.GetDecodedData(Byte[] buf,
Byte[]
modifier, Int32 start, Int32 length, Int32& dataLength)
at System.Web.UI.LosFormatter.Deserialize(String input)
--- End of inner exception stack trace ---
at System.Web.UI.LosFormatter.Deserialize(String input)
at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
--- End of inner exception stack trace ---
at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
at System.Web.UI.Page.LoadPageViewState()
at System.Web.UI.Page.ProcessRequestMain()</Exception>

I have a production asp.net application that is getting seemingly
random
Viewstate errors.

It is a single server, so there isn't any issue with posting viewstate
to a
different server that what it was received from. Also, it happens with
users
that have to go through a firewall and users that don't.

It happens across the a broad array of pages, most of them are simple
grid
pages that you can drill down into to collect more input data.

Also, the viewstate size is typically 5-30K depending on the page.
Never
gets anywhere near 1024K.

We have also installed sp1 for the 1.1 release of the .net framework,
so we
can collect more detailed viewstate errors.

I'll post the most typical error that we get in a follow up message.

If anybody knows what actually causes this I would be very interested
in
knowing. A resolution would be even better.

Chris Sutton

 

[mattburnside]

We're experiencing the same issue. The servers are within a cluster,
but we have a hardware load balancer that assures client-server
affinity based on client IP address, so I don't think it's an issue of
viewstate posting back to a different server.

Any resolution or suggestions on what may be causing this error would
be greatly appreciated.

 

[Alvin Bruney [MVP - ASP.NET]]

working on it still, no resolution yet. more and more incidents are starting
to pop up.

--
Regards,
Alvin Bruney - ASP.NET MVP

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc

 

[danpak6]

Try this...

Protected Overrides Sub SavePageStateToPersistenceMedium(ByVal
viewState
As Object)

Dim _formatter As New LosFormatter

Dim key As String = Request.Url.ToString & "__VIEWSTATE"
Dim memStream As New System.IO.MemoryStream
_formatter.Serialize(memStream, viewState)
memStream.Flush()
Session(key) = memStream

End Sub

Protected Overrides Function LoadPageStateFromPersistenceMedium()
As Obj
ect

Dim _formatter As New LosFormatter
Dim key As String = Request.Url.ToString & "__VIEWSTATE"

If Not Session(key) Is Nothing Then
Dim memStream As System.IO.MemoryStream = _
CType(Session(key), System.IO.MemoryStream)
memStream.Seek(0, IO.SeekOrigin.Begin)
Return _formatter.Deserialize(memStream)
End If

End Function


Best,

Daniel Pak

 

[schott19]

Hi Dan,

Thnaks for the code snippet. Looks like it could be promising.

I am also having the viewsate problem. Does this code need to go i
every code behind page? or just in the global?

Regard

 

[P.J]

We, too, are experiencing 'Invalid_Viewstate' error since a couple of
weeks. I have been investigating the problem lately, and this is what
I have to say about it:

-All development servers (virtual servers) and development workstations
do not have the problem. As someone mentionned, the problem is only on
the production server (no farm here - single server setup): a multi-cpu
Xeon (hypethreading) machine. I've asked to replicate the production
environment in a lab test on the same hardware (or almost the same) and
I succeeded in replicating the problem: Each time the the worker
process of an application pool shuts down, any Post made to a web page
already in-session in IE would result in the error. So I've asked to
remove all cpus except one, and to disable HT on it, just to check if
any relation could be made. No succes, the error still happens.

-Next item that I did check is the Application Pool security. On
development servers, the IIS Application Pool identity is always set to
the default Network Service and I can not replicate the error on them.
On the production server though, we set up the Application Pool to run
with a NT Domain service account and the application works just fine.
We do that so our application data layer can communicate with the
database through a trusted SQL connexion (thus avoiding the dilema of
having a userid and password in clear text somewhere in the web.config
file - like we do in development environment). So what I did this
morning is to set back (on the production environment in the lab) the
identity of Application Pool of our application to Network Service: the
problem is gone and I can not replicate it.

So what I can conclude right now is that there is some problem in the
way the security context of an Application Pool is applied to the
validation of an ASP.NET Viewstate when the worker process of the pool
shuts down for being idle.

As a work around I did last week is to 'uncheck' the 'Idle timeout'
from the Application Pool so people here won't experiment the error.
And I also set the application to recycle each night when no one is
using it.

I hope that this can help someone in some ways, and also help gurus
pinpointing the problem and fix it.

Our setup is:
Windows Server 2003 Standard
..Net Framework 1.1 + SP1 + SP1 Update
Application is developed in C# and we are using some of MS Application
Blocks (Data Access, Exception, etc)

Workstation are XP and 2000 and are using IE6 with the latest patches.

 

[danpak6]

Hi schott19,

Add it to your code-behind pages, and let me know if that help solve
the problem.

Best,

Daniel Pak

 

[Huzaifa Tapal]

Hello Daniel,

I added your code snipped to my Base code-behind page, but then I wasn't
getting the error but the application was behaving very strange.
Randomly, it would log the user out and the refreshing that page would
automatically log them back in.

I am using Server.Transfer to redirect from one page to another to take
advantage of adding querystring values to the Context and this problem
only seems to happend on the destination page of the Server.Transfer.

Any help would be appreciated.

 

[danpak6]

Hi Huzaifa,

Are you adding data to the context object before transferring?

Ex. in WebForm1.aspx:
Context.Items("myParameter") = x
Server.Transfer("WebForm2.aspx")

Then, in WebForm2.aspx:
Grab data from the context property
Dim x as Integer = CType(Context.Items("myParameter"),Integer)

 

[Huzaifa Tapal]

Hello Daniel,

Yes I am adding variables to the Context before transferring so that I
don't have to pass them in through the Query String.

This seems to be working fine on my development box but not on the
production Windows 2003 box.

 

[P.J]

Well finally through our support with HP and Microsoft, I finally got
these answers in relation with the Identity of an Application Pool on
IIS 6.0:

==================================================
There are two registry keys that are significant:

HKEY_LOCAL_MACHINE\Software\Microsoft\ASP.NET
HKEY_CURRENT_USER\Software\Microsoft\ASP.NET

When machineKey is set to AutoGenerate, the key information is stored
in the
HKEY_CURRENT_USER hive for the account running the process. When the
process
launches, ASP.NET will use the HKEY_CURRENT_USER registry key if it is
available, but will fall back to the
HKEY_LOCAL_MACHINE key if it is not. If neither registry key exists,
the process
creates the key in the HKEY_LOCAL_MACHINE hive. Otherwise a new set of
keys is generated.
There is some logic that checks to ensure that the key was created
after the
install time for ASP.NET as well so updates will cause a new key.

Now is the catch:

When the application pool is running under a user account (** my case
**) the above keys are NOT generated and you get the VIEWSTATE error.
Running as an administrative level account or Network Service does NOT
return a viewstate error.

MORE INFORMATION:
====================================
IIS does not load an explicit user profile hive for the worker process.
The Service
Control Manager loads the user profile hive for network service so this
area is
available, but custom accounts do not. As a result, there is not an
HKCU hive (or
any other innate writable location) in which to persist keys. There is
work being
done in ASP.NET 2.0 to try and provide a place to persist this type of
data for
other accounts.

The workaround is to use a specific key in the machine.config so the
key will not
be generated on each process start. You can also disable the IIS
health features
that you do not explicitly need to reduce the probability of running
into the
situation. As we discussed before, using the key in the machine.config
is common
since it is required in web farm scenarios.
====================================

So now I going to try the machine.config key solution and makes some
tests.

 

[Huzaifa Tapal]

Would we be able to add this key (if the solution works) to the
web.config file rather than the machine.config since the machine belongs
to a web host?

Can you provide a sample of the snipped that goes into the
machine.config file? Since I myself work at a web hosting company I had
the opportunity to switch the application pool of my website to Network
Service, however, ASP.NET did not like that.

Thanks for the great info. Will be waiting for your results.

 

[danpak6]

EnableViewStateMac
Indicates that ASP.NET should run a machine authentication
check (MAC) on the page's view state when the page is
posted back from the client. true if view state should
be MAC checked; otherwise, false. The default is false.

Note A view state MAC is an encrypted version the hidden
variable that a page's view state is persisted to when sent
to the browser. When you set this attribute to true, the
encrypted view state is checked to verify that it has not
been tampered with on the client.

 

[Huzaifa Tapal]

We can turn off the EnableViewStateMac in the web.config or machine
level in machine.config, however, that is not reccommended since
ViewState then can be tampered with.

 

[P.J]

I successfully tested the solution by adding a key in the
machine.config file of the server.

I use this link to make a small console application (in C#) to generate
a key (SHA1):
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312906

Then I updated the machine.config file under the system.web section
with the output produce and tried to make the Invalid_Viewstate error
come up again. But it didn't show up, so it is an acceptable solution
for us.

I agree that on a commercial hosting server, this solution might not be
appropriate since every web site will share the same key. I have no
answer for that beside disabling the application pool 'health' feature,
but then, you lose the advantage of using Windows 2003 and IIS 6.

 

[P.J]

As for an example of the key I used, here is the section in system.web
of the machine.config file:

<machineKey
validationKey="501CCD40823C2A627CEDD026581211B94DF5EF821008B6149BA4E6EE73A2D0B1E27E32970441D954F1CEF1870CA5FD5EAAD4E83776CE2B5B5FD9F0A6661FB91E"
decryptionKey="0BA0B07AB3E69714D0D387AE74E92ADD4B7BB70DB79EB478"
validation="SHA1"/>

(the validationKey is on one line)

 

[omark]

Can someone who has this problem fixed give the exact steps needed to
eliminate the problem. It seems several solutions were mentioned, but
not enough details were layed out.

Thanks,