您确实需要获取并查看服务器报告这些错误期间的服务器应用程序和系统事件以及 HTTPERR 日志。
如果没有这些,就很难推测问题的根本原因是什么。
Update:
OP 错误地标记了他的问题,因此下一节不再适用。不过,我将保留原样,因为我认为这些信息对于那些遇到这些问题并且可能正在考虑迁移到 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 使用稍微不同的方法来指定加载哪个 .NET Framework 版本,它由应用程序池的managedRunTimeVersion
财产。当 IIS/ASP.NET 处理请求时,站点的处理程序映射使用preCondition
属性来确定何时加载必要的处理程序(这有点像以前版本的 IIS 中的脚本映射)。
此机制可防止将错误的运行时版本加载到应用程序池的工作进程中。
因此,如果应用程序池配置为运行 .NET Framework 版本 v4.0,则仅会加载该版本,即使您的应用程序是针对 v2.0 构建的。
这里有一篇很棒的文章介绍了它是如何工作的:
阿赫东! IIS7先决条件
关于处理程序的部分大约一半解释了为什么意外地将错误的 .NET 版本加载到池中的危险可以通过preCondition
特征。
服务器应用程序不可用错误通常意味着发生了灾难性的事情(例如将错误的 ASP.NET 版本的 ISAPI 筛选器加载到已运行的工作进程中)。
不关闭 SQL 连接不太可能导致此类严重错误。如果是这种情况,您很可能会看到死亡运行时错误的黄屏。 SQL 连接耗尽通常不会使 ASP.NET 变形以致整个服务自行崩溃。
我的主要怀疑是权限问题,应用程序池标识无法正确访问应用程序文件夹。但这只是一种预感。
同样,您需要做的是获取应用程序和系统事件日志以及 HTTPERR 日志(它们驻留在%systemroot%\System32\LogFiles\HTTPERR
。其中将包含有关问题所在的线索和事实。
更新2:
在 Windows 2003/IIS6 上,如果您有两个运行不同 ASP.NET 版本且位于同一池中的应用程序,则will得到这个错误。根据我的经验(我为网络托管服务商工作),这是这个臭名昭著的错误页面的主要原因:
应用程序事件日志中还记录了一个明显的事件:
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.
虽然您的根应用程序可能不是用 ASP.NET 编写的,但很可能某些内容触发了将不同版本的框架加载到您站点的应用程序池中。
- 有一个流氓
web.config
在根目录中...这将触发 ASP.NET 加载
- 站点脚本映射中有一个到 ASP.NET 1.1 的通配符映射(不太可能,但有可能)
我倾向于认为您的新应用程序肯定最终出现在其他站点或应用程序运行不同框架版本的池中。真正找出答案的唯一方法是获取应用程序事件日志并查找上面显示的事件。