{"id":624,"date":"2004-08-17T07:55:01","date_gmt":"2004-08-17T11:55:01","guid":{"rendered":"http:\/\/wordpress.cephas.net\/?p=624"},"modified":"2004-08-17T07:55:01","modified_gmt":"2004-08-17T11:55:01","slug":"aspnet-the-view-state-is-invalid-for-this-page-and-might-be-corrupted","status":"publish","type":"post","link":"https:\/\/cephas.net\/blog\/2004\/08\/17\/aspnet-the-view-state-is-invalid-for-this-page-and-might-be-corrupted\/","title":{"rendered":"ASP.NET: The View State is invalid for this page and might be corrupted"},"content":{"rendered":"

I fixed a tricky bug yesterday on one of our sites that runs ASP.NET. Like all good webmasters, anytime a 500 error occurs on the site, an email is sent to me that contains all the juicy details: the URL the user was visiting, the date\/time, what browser they were using, which server in the cluster it occured on, the stack trace, any form variables, the querystring, session variables, and cookies. This particular error would occur on any page with a form and the stack trace would look like this:
\n
\nException of type System.Web.HttpUnhandledException was thrown.
\nsource = System.Web
\ntarget site = Boolean HandleError(System.Exception)
\nstack trace = at System.Web.UI.Page.HandleError(Exception e) at
\nSystem.Web.UI.Page.ProcessRequestMain() at
\nSystem.Web.UI.Page.ProcessRequest() at System.Web.UI.Page.ProcessRequest(HttpContext context) at System.Web.CallHandlerExecutionStep.System.Web.HttpApplication+IExecutio
\nnStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep
\nstep, Boolean& completedSynchronously)
\n<\/code>
\nwhich isn’t very helpful at all. So my first problem was that I wasn’t getting enough information; I couldn’t tell what the problem really was. The HttpModule that I wrote that listens for Application_Error<\/code> events was retrieving the exception using this code:
\n
\nHttpApplication application = (HttpApplication)source;
\nException error = application.Server.GetLastError();
\n<\/code>
\nwhich technically does retrieve the error that caused the event, but I was missing one key step: the last line should have read:
\n
\nException error = application.Server.GetLastError().InnerException;
\n<\/code>
\nand once I fixed that, I magically started receiving a much richer error description:
\n
\nSystem.Web.HttpException: The viewstate is invalid for this page and might be corrupted. at System.Web.UI.Page.LoadPageStateFromPersistenceMedium() at System.Web.UI.Page.LoadPageViewState() at System.Web.UI.Page.ProcessRequestMain()
\n<\/code>
\nThat description leads to a couple different knowledge base articles on support.microsoft.com<\/a>; Q323744<\/a> and Q312906<\/a> were the ones that fixed the problem I was experiencing. Turns out that when you a) run an ASP.NET application in a cluster (in my case it’s an ASP.NET application load balanced behind with an F5<\/a>), b) don’t use sticky sessions, and c) utilize view state, you must setup your web servers to use the exact same machine key, which is a setting in machine.config. Microsoft supplies a C# script that will generate the appropriate machineKey element for you machine.config in Q312906.<\/p>\n","protected":false},"excerpt":{"rendered":"

I fixed a tricky bug yesterday on one of our sites that runs ASP.NET. Like all good webmasters, anytime a 500 error occurs on the site, an email is sent to me that contains all the juicy details: the URL the user was visiting, the date\/time, what browser they were using, which server in the … Continue reading ASP.NET: The View State is invalid for this page and might be corrupted<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[17,12],"tags":[],"_links":{"self":[{"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/posts\/624"}],"collection":[{"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/comments?post=624"}],"version-history":[{"count":0,"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/posts\/624\/revisions"}],"wp:attachment":[{"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/media?parent=624"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/categories?post=624"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/tags?post=624"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}