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?
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.
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:
Check the IIS logs. I can't see in your question if you've already done that.
404 is page not found, so I'd look at path issues before credentials.
At the risk of pointing out the obvious... Is default.aspx still in the list of default documents for that site / virtual directory?
Drop down one level, and install Wireshark. Sniff the entire transaction on the server.
Like others have said, use Wireshark or another packet capture program to analyze the traffic between the client and server. This will allow you to see the exact request that the client is sending to the server and the response from the server. I find that when I'm beating my head against a wall with a networking problem that running a packet capture often illuminates something I missed or overlooked.
asp.net / app pool issues are usually written to the event logs, so that would be my first place to check before doing any traffic analyzing.
There are a couple of applications for viewing HTTP headers right in the browser.
ieHTTPHeaders works well for Internet Explorer. If you use Firefox, you can do a search for Live HTTP Headers. (I don't have enough rep to post a second link).
What is the physical path of the application? Is it configured as a virtual directory or is it actually in wwwroot? Can you browse the contents via the IIS manager?
Changing the web service extensions to allow fixed the 404 issue for me. I believe these values got changed during one of our patching cycles.
You can try to install Fiddler and run it with IE8 Developer tools to see if you are being redirected or something.