I created a new site in IIS7, added a new application underneath that site. When trying to then use an ASP.NET web service that is housed underneath this new application, I get an HTTP 500 Internal Server Error.

I've looked through the Event logs, IIS Logs, and tried to setup the "Failed Request Tracing", but nothing seems to get traced. I have it setup to check all content, verbose error logging, and HTTP errors ranging from 400-600. But nothing is ever logged underneath the FailedReqLogFiles folder. Other sites in this IIS configuration seem to be tracing failed requests just fine.

I can see the HTTP GET requests being logged in the IIS logs for that site, but they are obviously not very helpful as they just show the request being returned a 500 error.

I've checked permissions on the site folders in Explorer, and I've made sure Anonymous access was turned on and the app pool identity has access to the folder's contents as well.

Any ideas? Did I give enough information about the problem? Thanks in advance for any help or suggestions you can give.

  • I've gotten a little further, see, I'm no server guy, I'm just a dev. I setup a host file on one of the servers to point to its own IP for the external url so that I could see the error being thrown. It's an HTTP 500.19 "Cannot read configuration file due to insufficient permissions". And from the looks of it, it's the web.config that it's having issues with. I've checked the permissions, and nothing seems awry. – user10095 Jun 19 '09 at 18:18
  • It appears now that if I move the service from its subfolder underneath the application, to the root of the application, there are no issues whatsoever. And yet, I cannot tell a single permission difference between the root folder, and its subfolder. So weird. If I find a definitive answer, I'll post it here. – user10095 Jun 19 '09 at 20:01

Have you run Process Monitor to see if IIS has the appropriate permissions to write the FRT logs?


With Failed Request Tracing, you need to setup the rule, but as a separate step you must turn it on. In the Failed Request Tracing, check the Action pane on the right, that will have an option to enable it. That's my guess as to why the tracing isn't working.

My recommendation on any configuration in IIS7 where you have 1 site per app pool, or when all sites trust each other and the sites are stable, is to set Anonymous authentication to use the identity of the app pool. That gives you one less user to deal with. Then make sure that the app pool identity is granted permission on disk.

You mention that it doesn't work in the subfolder. It is possible to have different permissions or a different app pool used for a sub-application. Double check the app pool being used, and anonymous auth settings.

Finally, use Process Monitor as Colin suggested. Get it from www.sysinternals.com. It's free, safe to run on a production server and you'll figure it out in under 10 minutes. That will tell you exactly which user is denied access to which folder (or registry key).


Check your web.config, do you have impersonate = true?

In this case with annonymous access in IIS, it will be the IIS anonymous user that tries to read web.config not the application pool user.


Your web.config must be in the root of your web application folder. Otherwise, you will get all sorts of errors.


Apart from all the suggestion, you may also try Chrome Dev Tool [Press F12] to see if you get any clues. Similarly you can try this on IE [Press F12] as well if you can't have chrome.

https://developer.chrome.com/devtools for more details, For your case look in the network and console area

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy