Geeks With Blogs

Joe Mayo

Today, I was testing a Web site for deployment and encountered the problem described in the subject of this post.  However, the process leading up to realizing the true problem was far from clear.  This post describes my initial experience, steps I took to isolate the true problem, and what I did to fix it.  To put this in context, My project is an ASP.NET 4.0 Website.


While testing, I encountered a System.Web.HttpException with the following message:

File does not exist.

with the following stack trace:

at System.Web.StaticFileHandler.GetFileInfo(String virtualPathWithPathInfo, String physicalPath, HttpResponse response)
at System.Web.StaticFileHandler.ProcessRequestInternal(HttpContext context, String overrideVirtualPath)
at System.Web.DefaultHttpHandler.BeginProcessRequest(HttpContext context, AsyncCallback callback, Object state)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

As you can see, there’s no indication of which file was not found.  So, my first step was to set some breakpoints to see what was happening.  In the current scenario, I was redirecting to another page.  The page exists and it would have been a situation where the page would have had to have been deleted for it not to exist.

The Hunt

If it wasn’t the page itself that was missing, maybe it was something else like a CSS file or image?  So, I went into divide and conquer mode, starting off by commenting everything on the content and master pages.  The error was still there, indicating that it wasn’t something on the destination page.

Suspecting that something in ASP.NET might have contributed, I went to look at the HTTP stream.  Normally, I’ll use Fiddler2 to check this out, but ran into a problem that I can’t reproduce now.  If I was using Firefox, I could have used Firebug.  However, I’m running in IE and there is a nice set of Developer Tools that open by clicking F12.  Visiting the Network tab, I clicked the Start Capturing button.  Running the application, I discovered a request for /Account/Login.aspx.

The problem here is that /Account/Login.aspx is the default location of the ASP.NET login page if you don’t do anything to change it.  In my case, I had the loginUrl attribute of the authentication/forms element in web.config set to “Login.aspx”.  Changing the URL to “/Login.aspx” and “~/Login.aspx” didn’t solve the problem.  It’s been set that way since the application has been in production and is consistent with many other Web applications that I’ve built over the years.  In fact, this site has been working fine for a long time, but now ASP.NET is ignoring this setting.

Tip: Another way to verify that the loginUrl in web.config is being ignored is to hit a break-point in the Page_Load event of default.aspx and type FormsAuthentication.LoginUrl <Enter> in the immediate window.

So, now I know what the problem is.  Next, step is to find a solution.

Solving the Problem

So, I started searching for the answer (Yes, I used Bing).  Notice that I made the point earlier that my site is a WebForms Website, not to make a political statement, but to discuss my reasoning of how I solved the problem and infer some conclusions on the cause.  It seems that this has been an issue with MVC 3 for a while.  One of the solutions that kept cropping up was to add an appSettings entry to web.config with a key of “loginUrl” and the value being the controller you want to activate.  In WebForms, there are pages, not controllers, so I added the following line to web.config appSettings:

<add key="loginUrl" value="~/Login.aspx" />

Problem solved.

Surely, somewhere deep in the pipeline there’s a logical explanation for why this works.  I just call it a bug, but I might speculate on the cause.

Root Cause Clues

Since the site was happily serving customers without a hiccup until now, it’s only natural to look for what happened in-between then and now.  Change logs don’t indicate any modifications to web.config, other than appSettings between the last deployment and now.  Login.aspx and Login.aspx.cs haven’t been touched and neither have any of the other ASP.NET security controls.  What else has changed between then and now?

Windows 7 has a nice history of all the windows updates made to a system.  Examining Windows Update > View Update History shows all the Microsoft patches, along with dates.  The context menu of each of those patches allow you to View Details, which takes you to the Microsoft Knowledge Base site for that patch.  In particular, there were two patches that could have contributed to this problem during this timeframe:

KB 2533523 -

KB 2468871 -

There were other updates, but they didn’t modify the ASP.NET assemblies. There isn’t definitive proof that Microsoft introduced a bug with these patches, but you might be curious too about “What’s different between when everything was recently working perfectly and now?”



Posted on Wednesday, August 31, 2011 10:36 AM ASP.NET Web Forms | Back to top

Related Posts on Geeks With Blogs Matching Categories
Copyright © Joe Mayo | Powered by: