Home/ Questions/Q 582599
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T14:42:14+00:00

I’m having a problem with a web app I’m managing. Users starting receiving the

  • 0

I’m having a problem with a web app I’m managing. Users starting receiving the following error occasionally:

Validation of viewstate MAC failed. If
this application is hosted by a Web
Farm or cluster, ensure that
configuration specifies
the same validationKey and validation
algorithm. AutoGenerate cannot be used
in a cluster.

The problem is that it’s not a cluster – it’s a single Windows 2003 server. After digging around, it appears that adding a machineKey section and some extra attributes to the Pages directive in my web.config resolves this error:

<machineKey validationKey='MACHINE KEY SNIPPED'
        decryptionKey='DECRYPTION KEY SNIPPED'
        validation='SHA1'/>

<pages validateRequest="true" enableEventValidation="false">

After changing these two things in my web.config, the error goes away, but now I have a new problem – Instead of an error that my viewstate is invalid, the app just “Forgets” who my user is, and sends them back to the login page. Now, the users are browsing through the application, and then they’re unexpectedly sent to the login page, even after they’ve already been logged in for a few minutes. While I can’t force this to happen, it usually happens within visiting 10-12 different pages, so pretty frequently.

I’d love a resolution to this – does anybody know what else might be causing the viewstate error on a single server, or what I can do to ensure that it’s validated properly?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It turned out that this began happening when I added additional worked processes to the app pool that was running our application. Because the session state was being stored InProc (and not in a state service or a SQL Server), it was losing track of who the user was when it switched them between working processes. For now, dropping the number of processes on our server back to one corrected the problem, since raising it didn’t seem to have any improvement in the first place.

    • 0