Invalid_Viewsta te

[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

[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*********@sn clavalin.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

We, too, are experiencing 'Invalid_Viewst ate' 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.I tems("myParamet er"),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_MACH INE\Software\Mi crosoft\ASP.NET
HKEY_CURRENT_US ER\Software\Mic rosoft\ASP.NET

When machineKey is set to AutoGenerate, the key information is stored
in the
HKEY_CURRENT_US ER hive for the account running the process. When the
process
launches, ASP.NET will use the HKEY_CURRENT_US ER registry key if it is
available, but will fall back to the
HKEY_LOCAL_MACH INE key if it is not. If neither registry key exists,
the process
creates the key in the HKEY_LOCAL_MACH INE 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]

EnableViewState Mac
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 EnableViewState Mac 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_Viewsta te 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.