Results 1 to 7 of 7
Mar 31, 2011, 11:23 #1
Viewstate verification failed server error when clients try to submit form
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: 188.8.131.52 User: Is authenticated: False Authentication Type: Thread account name: HOST2-xxx\IWPD_2(xxx) ViewStateException information: Exception message: Invalid viewstate. Client IP: 184.108.40.206 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
Mar 31, 2011, 11:30 #2
- Join Date
- Aug 2007
- 3 Post(s)
- 0 Thread(s)
Are you on a load balanced host?
Mar 31, 2011, 11:50 #3
Mar 31, 2011, 12:09 #4
- Join Date
- May 2003
- Washington, DC
- 4 Post(s)
- 0 Thread(s)
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.
Mar 31, 2011, 12:19 #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.
Apr 5, 2011, 09:42 #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.
Apr 5, 2011, 22:14 #7
- Join Date
- Jul 2004
- Cape Town, South Africa
- 44 Post(s)
- 0 Thread(s)
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.