Viewstate verification failed server error when clients try to submit form

.NET
1

Hi Guys. I have a unique issue that I have not been able to resolve by looking at other Viewstate verification errors online.

Background: A client comes into our site, signs in and proceeds to an e-sign form. Once they click the submit button, they get the viewstate error. Sometimes they get through and get the error on either of the next two forms. This happens sporadically. Maybe 2 out of 10 receive the error. All clients who received an error were able to go back in a few hours later and complete the forms without error. My hosting company, programmers and myself have not been able to replicate the error yet.

This has been happening for the last 2 weeks.

So we have three pages that this is occurring on one domain and another separate page on a different domain. All on the same windows dedicated server. So first thought is that, I have not changed any code in months, my SQL admin has not changed code related to these processes in several months, so it must be the server. I submitted a ticket with Liquidweb. They could not find anything wrong.

Funny thing is, I do not use viewstates in my web.config or on my forms. I did try using the disable viewstate code in the config file. I also checked the viewstate base64 code in a decrypter, that looked fine. I checked the sessions are enabled and enough time is set for timeouts. No patterns have occurred, like specific times, browsers, or locations.

I’m currently having the programmers that we work with go through the code and server settings.

Conclusions: It seems like the cookie or session data is being lost somewhere along the process. I checked the ideal timeout settings and they are at 20min. More than enough time for someone to e-sign, (our reps walk the client through the entire process, so I’m sure on the timeframe.) I still think it’s a hosting issue, but they say nothing has changed in two weeks.

It’s starting to come down to finger pointing now between the hosting techs, sql admin, it admin and programmers. Grrrr.

Here is the error:



 Event code: 4009

Event message: Viewstate verification failed. Reason: The viewstate supplied failed integrity check.

Event time: 3/23/2011 8:54:31 PM

Event time (UTC): 3/24/2011 12:54:31 AM

Event ID: aaaa4d1a98f84f05a61e45a82178275c

Event sequence: 33

Event occurrence: 4

Event detail code: 50203

 

Application information:

    Application domain: /LM/W3SVC/6983/Root-1-129454012216742214

    Trust level: Full

    Application Virtual Path: /

    Application Path: C:\\Inetpub\\vhosts\\secure.xxx.com\\httpdocs\\

    Machine name: HOST2-xxx

 

Process information:

    Process ID: 351124

    Process name: w3wp.exe

    Account name: HOST2-xxx\\IWPD_2(xxx)

 

Request information:

    Request URL: https://secure.xxx.com:443/ClientForms/creditor_info_form.aspx

    Request path: /ClientForms/creditor_info_form.aspx

    User host address: 166.56.104.216

    User: 

    Is authenticated: False

    Authentication Type: 

    Thread account name: HOST2-xxx\\IWPD_2(xxx)

 

ViewStateException information:

    Exception message: Invalid viewstate.

    Client IP: 166.56.104.216

    Port: 1812

    User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

    PersistedState: /wE....

    Referer: https://secure.xxx.com/ClientForms/creditor_info_form.aspx

    Path: /ClientForms/creditor_info_form.aspx
2

Are you on a load balanced host?

3

No, I have a dedicated windows server at LiquidWeb hosting.

4

I’d keep an eye on application restarts – seems like the app pool might be getting dumped so you are getting a new key and the viewstate is invalid. I would also keep an eye on available RAM – running out can cause ASP.NET to get self defensive and dump things unexpectedly.

For session timeouts, we keep it very, very short. Like 2 minutes, but use a litte AJAX “heartbeat” that keeps the session alive as long as someone is on the page. Works great as no one ever loses a session on the site, but killing abandoned sessions quickly keeps memory pressure down.

5

Thanks. Those are some great ideas. I will contact my host to inquire about the RAM usage and to see if there are any logs for the app pool restarts.

6

Talked to my programmers. They said they tried to add the machinekey. However, because our wacky scripting, the global.asa file is not loading. Our current login and main customer account info is coded in classic ASP and our e-sign and other forms are all done in .net. So the conflict is preventing the file from loading. Seems logical and fishy at the same time. Would like to get other peoples opinion on this before issuing a recode of the classic ASP. Thanks.

7

asp.old and asp.net should be able to run together, although it would not be advised. I would keep everything asp.net if possible. It is hard to say what your problem is caused by without having access to the code and server.