Invalid_Viewstate

[Chris Sutton]

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

[Chris Sutton]

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.LoadPageStateFromPersistenceMed ium()
--- End of inner exception stack trace ---
at System.Web.UI.Page.LoadPageStateFromPersistenceMed ium()
at System.Web.UI.Page.LoadPageViewState()
at System.Web.UI.Page.ProcessRequestMain()</Exception>

"Chris Sutton" wrote:

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

[Chris Sutton]

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

"Chris Sutton" wrote:

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.LoadPageStateFromPersistenceMed ium()
--- End of inner exception stack trace ---
at System.Web.UI.Page.LoadPageStateFromPersistenceMed ium()
at System.Web.UI.Page.LoadPageViewState()
at System.Web.UI.Page.ProcessRequestMain()</Exception>

"Chris Sutton" wrote:

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 va******@hotmail.com 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
"Chris Sutton" <Ch*********@discussions.microsoft.com> wrote in message
news:62**********************************@microsof t.com...

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

"Chris Sutton" wrote:

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.LoadPageStateFromPersistenceMed ium()
--- End of inner exception stack trace ---
at System.Web.UI.Page.LoadPageStateFromPersistenceMed ium()
at System.Web.UI.Page.LoadPageViewState()
at System.Web.UI.Page.ProcessRequestMain()</Exception>

"Chris Sutton" wrote:

> 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
<ma**********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

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.

[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

--
schott1
-----------------------------------------------------------------------
schott19's Profile: http://www.msusenet.com/member.php?userid=59
View this thread: http://www.msusenet.com/t-186940149

[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.

[Alvin Bruney [MVP - ASP.NET]]

I'm aware that the application pool restarts cause this issue. However, I
also have this error occuring on a server where application pools are not
allowed to recycle under any circumstance.

--
Regards,
Alvin Bruney - ASP.NET MVP

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc
"P.J" <pj*********@snclavalin.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

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.

[Alvin Bruney [MVP - ASP.NET]]

I'm aware that the application pool restarts cause this issue. However, I
also have this error occuring on a server where application pools are not
allowed to recycle under any circumstance.

--
Regards,
Alvin Bruney - ASP.NET MVP

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc
"P.J" <pj*********@snclavalin.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

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
schott19 wrote:

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 in
every code behind page? or just in the global?

Regards
--
schott19
------------------------------------------------------------------------ schott19's Profile: http://www.msusenet.com/member.php?userid=593
View this thread: http://www.msusenet.com/t-1869401494

[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.

*** Sent via Developersdex http://www.developersdex.com ***

[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.

*** Sent via Developersdex http://www.developersdex.com ***

[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.
*** Sent via Developersdex http://www.developersdex.com ***

[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.

*** Sent via Developersdex http://www.developersdex.com ***

[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...;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="501CCD40823C2A627CEDD026581211B94DF 5EF821008B6149BA4E6EE73A2D0B1E27E32970441D954F1CEF 1870CA5FD5EAAD4E83776CE2B5B5FD9F0A6661FB91E"
decryptionKey="0BA0B07AB3E69714D0D387AE74E92ADD4B7 BB70DB79EB478"
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,

[Alvin Bruney [MVP - ASP.NET]]

That's good stuff, i'll push this out to MSDN as a solution. P.J. send me
your full name if you require credit for the solution va******@hotmail.com
subject line 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, Amazon.com etc
"P.J" <pj*********@snclavalin.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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...;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.

[Huzaifa Tapal]

Unfortunately, I tried this solution out for my scenario and it does not
work. Here is what my application is running on:

- Windows 2003 HyperThreaded II6 Server
- Application Pool's identity is user account
- Using FormsAuthentication
- Using Server.Transfer to go from page to page taking advantage of
performance gains and the Context to pass query values between pages.

If I disable the EnableViewStateMac in my web.config, I am no longer
running into this problem. What is interesting is that I had the same
application running on another Windows 2003 machine about 4 months ago
and it did not error out like this. The only difference between the
current one and the old one is that the current one is HyperThreaded.

The machine key solution might work for Web Farm scenarios but not
regular sites running on a shared production box at a web hosting
company.


*** Sent via Developersdex http://www.developersdex.com ***

[P.J]

There are 3 possible solutions to this problem:

1st solution: Disable the application pool idle worker process shutdown
via IIS 6.0 console | <your_application> properties

2nd: I think the code snippets provided by danpak6 persist the
viewstate so it stays available on subsequent hit

3rd: In the machine.config file of your server, in the system.web
section, change the validationKey setting from the default (which is
Autogenerate) to a permanent key you generated (see above post to make
the tool that will generate one for you).

I think that sums it all.

[Huzaifa Tapal]

Of the three solutions you suggested, none of them work.

1st solution: Disable the application pool idle worker process shutdown
via IIS 6.0 console | <your_application> properties

-- Did that under the Performance tab, recycled the application pool,
still the error persists.

2nd: I think the code snippets provided by danpak6 persist the viewstate
so it stays available on subsequent hit

-- Although this was not giving any error, the application was behaving
oddly. It would keep logging me out when it usually three the Invalid
ViewState error otherwise. Then accessing a secured area, I would
automagically be logged in again.

3rd: In the machine.config file of your server, in the system.web
section, change the validationKey setting from the default (which is
Autogenerate) to a permanent key you generated (see above post to make
the tool that will generate one for you).

-- This is the solution, in my previous reply I mentioned does not work
(possibly in a non-web farm environment).

*** Sent via Developersdex http://www.developersdex.com ***

[Alvin Bruney [Microsoft MVP]]

>Did that under the Performance tab, recycled the >application pool,still

the error persists. You should manipulate the settings so that the application does not recycle.
This is not what you have said.
--
Regards
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
--------------------------------------------------
"Huzaifa Tapal" <hu***********@aidenblerb.com> wrote in message
news:O0**************@TK2MSFTNGP14.phx.gbl... Of the three solutions you suggested, none of them work.

1st solution: Disable the application pool idle worker process shutdown
via IIS 6.0 console | <your_application> properties

-- Did that under the Performance tab, recycled the application pool,
still the error persists.

2nd: I think the code snippets provided by danpak6 persist the viewstate
so it stays available on subsequent hit

-- Although this was not giving any error, the application was behaving
oddly. It would keep logging me out when it usually three the Invalid
ViewState error otherwise. Then accessing a secured area, I would
automagically be logged in again.

3rd: In the machine.config file of your server, in the system.web
section, change the validationKey setting from the default (which is
Autogenerate) to a permanent key you generated (see above post to make
the tool that will generate one for you).

-- This is the solution, in my previous reply I mentioned does not work
(possibly in a non-web farm environment).

*** Sent via Developersdex http://www.developersdex.com ***

[P.J]

In the Performance tab, uncheck the "Idle timeout" checkbox. By
default it is at 20 minutes, but unchecking it will leave it in memory
and no shutdown (recycling) will happen again. Then, the the Recyling
tab, uncheck any 'recycling' option that are set.

Note: if you are connected to your site, make changes to the
application pool setting, and then continue to browser, you might have
the error since the worker process did recycle when you applied the
settings to the pool. But from a fresh new session, you shouldn't
received the error.

Hope that will you better!
P.J

[danpak6]

Hi Huzaifa Tapal,

The unofficial solution is to set the enableViewStateMac property to
True on the page you'll be transferring to, then set it back to False.
This records that you want a definitive False value for this property
and resolves the bug.

Best,

Daniel

[Huzaifa Tapal]

Well turning off the recycling options and the idle timeout still did
not work. The wierd thing is that this only happens after doing
Server.Transfer and after Forms Authentication.

Turning the EnableViewStateMac to false fixes the problem, however,
since that is not reccommended I want to find a better solution to this.

I am surprised Microsoft is not doing anything about this. I believe
this is a huge bug in ASP.NET

*** Sent via Developersdex http://www.developersdex.com ***