IIS6: How to troubleshoot a 404 error in an ASP.NET application?

I have an ASP.NET application on a Windows Server 2003/IIS6 that refuses to run for some reason (it's the Xerox Centre, if that info helps). It has been working flawlessly before though on this server.

Now, all I get if I try to open the app homepage (http://some.intranet.server/XeroxCentreWareWeb/) is a "404 - File or directory not found" error.

• The app is configured to run in it's own app pool, which runs as Network Service.
• The Network Service account has read access to the configured directory.
• If I stop the app pool, I get the expected "Service Unavailable" message, meaning the app and its pool are wired correctly
• I tried to track down any file permission issues with procmon - nothing to be seen. There isn't even an access to the web app directory happening when the page loads.
• Interestingly, according to procmon, the web server accesses the 401-2 custom error file (Logon failed due to server configuration) first, but then decides to send the 404 down to the client.
• EDIT: The app runs with Windows-integrated authentication. Regular users have access to the app directory as well (I would have noticed file system "ACCESS DENIED" messages in procmon, if there had been any.)

This makes me think that there is some kind of weird permission problem that occurs even before the application files are being accessed. I just have no idea where to look.

I've tried to run the app pool as Local System for a test, but to no avail.

What else could I check in this case?

Solution 1:

First off, I love the troubleshooting steps that you took. One more 'break' test is to stop the site itself, not just the app pool, to make sure that it's not another site handling it, yet sharing the app pool.

IIS6 has the "Web Service Extensions" section within IIS Manager. Make sure that the framework version that you're using is allowed. If you've recently changed the framework version to one that isn't marked as allowed, that will throw a 404 error.

The IIS logs will also confirm the sub-status code for you and it will also confirm that the right site is wired up.

Solution 2:

The answer I've found is as simple as non-obvious.

There still was a "Wildcard Application Map" defined to a no-longer-existent application server (ColdFusion, in this case). The ColdFusion uninstaller obviously "forgot" to remove that setting from the MetaBase.

Wildcard Application Maps are defined here:

• in IIS Manager, open the Application Properties dialog
• on the "Virtual Directories" tab, look in the "Application Settings" section
• click "Configuration…"
• the "Application Configuration" dialog opens
• there it is, on the "Mappings" tab