Mixing .NET versions between website and virtual directories and the "server application unavailable" error Message

Backstory

Last month our development team created a new asp.net 3.5 application to place out on our production website. Once we had the work completed, we requested from the group that manages are server to copy the app out to our production site, and configure the virtual directory as a new application.

On 12/27/2010, two public 'Gineau Pigs' were selected to use the app, and it worked great. On 12/30/2010, We received notification by internal staff, that when that staff member tried to access the application (this was the Business Process Owner) they recieved the 'Server Application Unavailable' message.

When I called the group that does our server support, I was told that it probably failed, because I didn't close the connections in my code. However, the same group went in and then created a separate app pool for this Extension Request application. It has had no issues since.

I did a little googling, since I do not like being blamed for things. I found that the 'Server Application Unavailable' message will also appear when you have multiple applications using different frameworks and you do not put them in different application pools.

Technical Details - Tree of our website structure

Main Website <-- ASP Classic
         +-Virtual Directory(ExtensionRequest) <-- ASP 3.5 

From our server support group:

'Reviewed server logs and website setup in IIS. Had to reset the application pool as it was not working properly. This corrected开发者_JAVA百科 the website and it is now back online. We went ahead and created a application pool for the extension web so it is isolated from the main site pool. In the past we have seen other application do this when there is a connection being left open and the pool fills up. Would recommend reviewing site code to make sure no connections are being left open.'

The Real Question: What really caused the failure? Isn't the connection being left open issue an ASP Classic issue? Wouldn't the ExtensionRequest application have to be used (more than twice) in the first place to have the connections left open? Is it more likely the failure is caused by them not bothering to setup the new Application in it's own App Pool in the first place?

Sorry for the long windedness

---

You'd really need to obtain and review the server's Application & System event and HTTPERR logs for the period the server was reporting these errors.

Without these it'd be hard speculate what was the root cause of the problem.

Update:

OP incorrectly tagged his question so this next section no longer applies. However I'll leave in place because I think the information is useful for those encountering these issues and perhaps thinking about migrating to IIS7.x.

---

You are correct that running two different .NET Framework's in the same application pool can cause these errors but that's something you'd tend to see on Windows 2003/IIS6, not Windows 2008/IIS7.

IIS7 uses a slightly different approach to specifying which .NET Framework version is loaded and it's determined by the Application pool's managedRunTimeVersion property. When requests are processed by IIS/ASP.NET the site's Handler Mapping's use a preCondition attribute to determine when to load the requisite handler (which is kind of like a script mapping in previous versions of IIS).

This mechanism prevents the incorrect runtime version being loaded into the application pool's worker process.

So if an application pool is configured to run .NET Framework version v4.0 only that version will load, even if your application is built against v2.0.

There's a great article on how this works here:

Achtung! IIS7 Preconditions

The section on Handlers about half way through explains why the dangers of accidentally loading the wrong .NET version into a pool are mitigated by the preCondition feature.

A Server Application Unavailable error usually means something catastrophic has happened (like loading the wrong ASP.NET version's ISAPI filter into an already running worker process).

Not closing SQL connections is unlikely to cause this type of serious error. You'd more than likely be seeing a yellow screen of death runtime errors if that were the case. Running out of SQL connections usually doesn't bend ASP.NET so out of shape that the whole service tops itself.

My prime suspect would be a permissions problem where the application pool identity was unable to correctly access the application folders. But it's just a hunch.

Again, what you need to do is get the Application & System event logs and the HTTPERR logs (they reside in %systemroot%\System32\LogFiles\HTTPERR. That will contain clues and facts about what went wrong.

Update 2:

On Windows 2003/IIS6, if you have two applications running different ASP.NET versions that reside in the same pool you will get this error. In my experience (I work for a web hoster) it is the primary cause of this infamous error page:

There's also a tell-tale event logged to the Application Event log:

Event Type: Error
Event Source:   ASP.NET 2.0.50727.0
Event Category: None
Event ID:   1062
Date:       12/01/2011
Time:       12:31:43
User:       N/A
Computer:   KK-DEBUG
Description:
It is not possible to run two different versions of ASP.NET in the same 
IIS process. Please use the IIS Administration Tool to reconfigure your
server to run the application in a separate process.

Whilst your root application may not be written in ASP.NET it's likely that something has triggered loading of a different version of the framework into your site's application pool.

• there's a rogue web.config in the root...this will trigger ASP.NET to load
• there's a wildcard mapping to ASP.NET 1.1 in the site script maps (less likely, but possible)

I'm inclined to think that your new application most certainly ended up in a pool where other sites or applications were running a different framework version. The only way to really find out is to obtain the Application event logs and look for the event shown above.

---

It's hard to tell; there could be many causes (too many resources used, calling outside of .NET caused something to crash, etc). I would look in the Event log and see if you can find something there.

If you're running different versions of .NET you definitely want separate pools. If you have the option, I would recommend separate pools for each application (even if in the same .NET version).

As far as "closing the connection" (I assume you mean the connection to the database). If you're creating "low level" connections (i.e. SqlConnection, SqlCommand) then make sure you're wrapping them in a "using" statement, otherwise your connection pool can fill up. In my experience though, you should receive regular .NET errors in this case. If you're using an ORM this shouldn't be an issue.

Edit:

If you can't find anything useful in the Event Log, you could try this: http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/