I have an aspx.net website running on the .net framework version 4.0, the website uses forms authentication, except for a small portion of the system, where the web services are kept, which has been configured to be accessible by all (using the location setting in the web.config file).

the application is setup on a windows 2008 server, IIS7.5, with it's own memory pool, configured for .NET 4.0. There is also a DefaultAppPool also configured, which I originally left configured for .NET 2.0.

I was investigating a problem with running one of my web services, in which an error 404 was returned whenever a function was called, I resolved this problem, however I noticed whenever I received the error, the .NET version returning the error was version 2.0, rather than version 4.0, that of the application pool it should be running in. I confirmed this behaviour by changing the settings of the DefaultAppPool to 4.0 as well, and the error was then being generated by the appropriate version.

IIS appears to have made a decision about which memory pool it should use, bypassing what I had configured for the aspx.net website.

has anybody else experienced a similar problem, am I going mad, is there a configuration option hidden somewhere that could justify this behaviour? (i.e. somewhere in machine.config)


It's only when there's an error, though, and it was a 404; this suggests that the request generating the error wasn't part of the namespace served by your app pool. Cos a 404 is Not Found, and that implies that the URL wasn't correct; psychic debugging tells us that this didn't fall within your app's /path/ .

If the Default Web Site runs as DefaultAppPool at the root, any misrouted requests that land outside your specific app path (which runs in Your40AppPool) will be serviced by the DefaultAppPool.

Netsh http sh ser 

will show you the URL namespaces defined for each App Pool (just stare at it a while until you get the hang of it). If any request targets anything outside the /path/ mapped to Your40AppPool, it'll be served by whatever's registered at the site (or box) level, which most times is DefAppPool.

  • ah, I like the term psychic debugging. the 404 was being generated because I was hand crafting the web service request and the HTTP 1.1 header, I incorrectly defined the "Host:" header, but it sounds like your original superstition is still valid, that's a nifty little command, thanks for the comment. – Phill Oct 24 '11 at 16:50

Your Answer

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

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