问题描述

背景故事
上个月，我们的开发团队创建了一个新的 asp.net 3.5 应用程序来放置在我们的生产网站上.工作完成后，我们要求管理服务器的组将应用程序复制到我们的生产站点，并将虚拟目录配置为新应用程序.

2010 年 12 月 27 日，两个公开的Gineau Pigs"被选中使用该应用程序，并且效果很好.2010 年 12 月 30 日，我们收到内部员工的通知，当该员工尝试访问应用程序(这是业务流程所有者)时，他们收到了服务器应用程序不可用"消息.

当我打电话给我们的服务器支持小组时，我被告知它可能失败了，因为我没有在我的代码中关闭连接.但是，同一组进入，然后为此扩展请求应用程序创建了一个单独的应用程序池.从那以后它就没有问题了.

我做了一点谷歌搜索，因为我不喜欢被指责.我发现当您有多个使用不同框架的应用程序并且您没有将它们放在不同的应用程序池中时，也会出现服务器应用程序不可用"消息.

技术细节 - 我们的网站结构树

主网站 <-- ASP Classic+-虚拟目录(ExtensionRequest) <-- ASP 3.5

来自我们的服务器支持小组:

'在 IIS 中查看服务器日志和网站设置.必须重置应用程序池，因为它无法正常工作.这更正了网站，现在它又重新上线了.我们继续为扩展 web 创建了一个应用程序池，因此它与主站点池隔离.过去，我们看到其他应用程序在连接处于打开状态并且池已填满时执行此操作.建议查看站点代码以确保没有任何连接处于打开状态.'

真正的问题:真正导致失败的原因是什么?连接保持打开状态不是 ASP Classic 问题吗?是不是必须首先使用 ExtensionRequest 应用程序(超过两次)才能使连接保持打开状态?失败更有可能是因为他们没有首先在自己的应用程序池中设置新应用程序吗?

对不起，啰嗦了

您确实需要获取并查看服务器的应用程序和服务器报告这些错误期间的系统事件和 HTTPERR 日志.

如果没有这些，就很难推测问题的根本原因.

更新:

OP 错误地标记了他的问题，因此下一部分不再适用.但是，我将留在原地，因为我认为这些信息对于那些遇到这些问题并且可能正在考虑迁移到 IIS7.x 的人很有用.<小时>您是正确的，在同一个应用程序池中运行两个不同的 .NET Framework 会导致这些错误，但这是您在 Windows 2003/IIS6 上看到的，而不是 Windows 2008/IIS7.

IIS7 使用稍微不同的方法来指定加载哪个 .NET Framework 版本，它由应用程序池的 managedRunTimeVersion 属性确定.当 IIS/ASP.NET 处理请求时，站点的处理程序映射使用 preCondition 属性来确定何时加载必要的处理程序(这有点像以前版本的 IIS 中的脚本映射).

此机制可防止将不正确的运行时版本加载到应用程序池的工作进程中.

因此，如果应用程序池配置为运行 .NET Framework v4.0 版本，则只会加载该版本，即使您的应用程序是针对 v2.0 构建的.

这里有一篇很棒的文章介绍了它的工作原理:

Achtung！IIS7 前提条件

关于处理程序的部分大约一半解释了为什么 preCondition 功能可以减轻意外将错误的 .NET 版本加载到池中的危险.

Server Application Unavailable 错误通常意味着发生了灾难性事件(例如将错误的 ASP.NET 版本的 ISAPI 过滤器加载到已经运行的工作进程中).

不关闭 SQL 连接不太可能导致此类严重错误.如果是这种情况，您很可能会看到黄色的死亡运行时错误屏幕.用完 SQL 连接通常不会使 ASP.NET 变形，以至于整个服务都达到顶峰.

我的主要怀疑是应用程序池身份无法正确访问应用程序文件夹的权限问题.但这只是一种预感.

同样，您需要做的是获取应用程序和系统事件日志和 HTTPERR 日志(它们驻留在 %systemroot%System32LogFilesHTTPERR 中.这将包含有关问题的线索和事实.

更新 2:

在 Windows 2003/IIS6 上，如果您有两个运行不同 ASP.NET 版本且驻留在同一个池中的应用程序，您将收到此错误.根据我的经验(我为网络托管服务商工作)，这是导致这个臭名昭著的错误页面的主要原因:

应用程序事件日志中还记录了一个事件:

虽然您的根应用程序可能不是用 ASP.NET 编写的，但很可能是某些原因触发了将不同版本的框架加载到您网站的应用程序池中.

• 根目录中有一个流氓 web.config...这将触发 ASP.NET 加载
• 站点脚本映射中有一个通配符映射到 ASP.NET 1.1(不太可能，但可能)

我倾向于认为您的新应用程序肯定会在其他站点或应用程序运行不同框架版本的池中结束.真正找出答案的唯一方法是获取应用程序事件日志并查找上面显示的事件.

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 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.

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%System32LogFilesHTTPERR. 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.

这篇关于在网站和虚拟目录之间混合 .NET 版本以及“服务器应用程序不可用"；错误信息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！