"View State corruption"

If you encounter an exception "the status information of this page is invalid or may be damaged" When debugging or accessing the ASP. NET page, I believe you will be helpless. Because the solutions available on the Internet and Microsoft's kb831150 will only confuse you. Of course, I am not here to provide a solution, but to record how I encountered this problem and how to avoid it, hoping to help you in a similar scenario.

I. Problem echo

The problematic page is a registration page. It uses many verification controls, input boxes, and drop-down boxes, including multiple custom verification controls. jquery is also used for client verification methods.

The problem is that when the user enters the user name and clicks "check whether the user name is available", the result is displayed in a span with the ID of accountholder, and other items are filled out, click "register" to display the error page.

The yellow classic error page is as follows:

The phrase "no source line" pushed us away, so we could not debug it.

It took more than a day to delete controls, delete verification, and disable scripts.The result is described in one sentence.At last, the line of sight is located in a JavaScript method that uses ajax to verify duplicate usernames. This JavaScript MethodCodeAs follows:

 Code 

   Function Checkaccountexists (){
  VaR  Name  =  $ (  "  # Namebox  "  ). Val ();

  If  (Validatename (name )){
$. Ajax ({
Type:  "  Post  "  ,
URL:  " Handlers/account  . Ashx  "  ,
Cache:  False  ,
Data:  "  Name =  "     +  Name,
Success:  Function  (Data ){
$ ( "  # Accountholder  "  Pai.html (data );
},
Error:  Function  (Data ){
$ (  "  # Accountholder  "  Pai.html (  "  Failed to check account name due to system exception.  "  );
}
});
}  Else {
$ (  "  # Accountholder  "  Pai.html (  ""  );
}
}
 

 

Here, validatename (name) is a regular expression test method.

As this error is difficult to debug, I hope httpwath can give us some tips.

Ii. http request and Response Information

You can use httpwath to track requests and see if an error occurs:

The address of the Ajax request is checkaccountexists. aspx. This page uses response. Write to return the verification result. I thought it was a post problem and changed the method to get (click to see the big picture ):

No matter whether post or get gets the verification result, 500 is returned, that is, the yellow page is returned. At this point, I am very anxious. No matter how you adjust the control and disable the script, it still fails.

Later, I processed the Ajax request in another way, and changed it to a handler (implementing ihttphandler) to handle the user name verification. There was no error. Let's take a look at the monitored Request Response stream:

The above is post acquisition, and the following is the get method (click to see the big picture ):

Since I cleared the same data in the browser cache and input during each test, so that the data in each post back is the same, you can see from the above, the data sent when aspx is used as the Ajax response end is 2058b, while the data sent when handler is used is 1987b. Where does this come from?

Iii. Conclusion

You may have already discovered it, but it has been hard to find it.

From the previous two httpwatch documents, we can see that when the ASPX page is used as the background Ajax response, we not only requested the ASPX page, but also two CSS files, because the ASPX page contains HTML code, the CSS file is included, and the HTML code contains a form on the server. The problem is here!

General ProcessingProgramThere will be no such problem. You must complete the returned items and have full control over them.

Of course, you can also use aspx as the Ajax background processing program. Delete all HTML code on the ASPX page and retain only the @ page declaration line. The result is:

The puzzle is finally solved.

The conclusion is that it is really annoying to modify others' programs. what's even more annoying is that others' programs are not well written. The Troubles of cooperation also arise.

In addition, it is quite depressing to find out the root cause of the error at the end of troubleshooting. I used to dislike ASP. NET's post back mechanism. One of the reasons is that viewstate and other controls affect the appearance of the page.

Iv. Reference resources

For more information about view status, see the following link:

ASP. NET view status overview

Truly understanding viewstate

Microsoft Chinese Technology Forum (msdn and technet)