Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
1  
+1 for using ProcMon, btw. –  user3914 Oct 22 '09 at 13:06
add comment

10 Answers

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.

share|improve this answer
add comment
up vote 2 down vote accepted

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
share|improve this answer
    
Nice to know you found your answer. Good. –  Vivek Kumbhar Mar 24 '10 at 23:35
add comment

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.

share|improve this answer
    
If that was the case, I would have seen a failed attempt to access a non-existing path in procmon. Strange enough, the log file directory is empty… WTF?! –  Tomalak Oct 22 '09 at 13:19
    
Go with Jeff's suggestion re WireShark. –  user3914 Oct 22 '09 at 17:35
add comment

At the risk of pointing out the obvious... Is default.aspx still in the list of default documents for that site / virtual directory?

share|improve this answer
    
Yes. Such a problem would lead to a "directory listing not allowed" message anyway, not to a 404. –  Tomalak Oct 22 '09 at 15:28
add comment

Drop down one level, and install Wireshark. Sniff the entire transaction on the server.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
add comment

You can try to install Fiddler and run it with IE8 Developer tools to see if you are being redirected or something.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.