在我的开发机器上，每当我将IIS应用程序池设置为以32位模式运行时，任何启动的Web应用程序都会挂起。在浏览器中访问时，应用程序将“挂起”大约5-10秒，然后才会收到503错误。该应用程序的应用程序池将在此时停止，并且必须明确重新启动。
在64位（默认）模式下，一切都很好，但是只要将池切换到32位，它就会立即挂在新的网站中的静态页面上。
当以32位模式发布到我的实时服务器时，相同的应用程序运行正常，因此看起来这是某种配置问题。我启用了失败的请求跟踪，但日志中没有显示任何内容。
由于一些旧的COM依赖项，我有几个必须运行32位的应用程序，但我无法让服务器运行。
任何可能导致此问题的想法？
答案 0 :(得分：9)
好的我发现了问题，这是AspNetCore模块，它在64位版本中注册了IIS模块列表中没有位数值。
此问题并非特定于AspNetCoreModule，除了安装模块时未指定bitness64（对于64位版本）。如果没有位数值，模块即使在32位模式下也会加载并导致服务器崩溃。
另一个失败点是IIS重写模块，当Windows更新时，它会因类似原因而被软件化。每次Windows更新时，Rewrite Module都会为我打破IIS（32位和64位）。这是初始失败和事件日志条目。重新安装重写模块后，AspNetCoreModule错误开始显示在事件日志中。我在我的博客上发布了更多信息：https://weblog.west-wind.com/posts/2015/jul/05/windows-10-upgrade-and-iis-503-errors
为了修复AspNetCore模块的位数，我改变了Applicationhost.config中的位数：
<add name="AspNetCoreModule" image="%SystemRoot%\system32\inetsrv\aspnetcore.dll" preCondition="bitness64" />
注意precondition=bitness64，这是使32位AppPools再次工作所需的全部内容，因为这可以防止模块加载到32位进程中。重新安装AspNet Server运行时可能也可以解决这个问题，但我没有验证这一点。
当应用启动时出现503错误时，它们通常与应用程序池相关，并且不会显示在FREB日志中。 EventLog确实有更多信息，在这种情况下首先指向重写模块，然后指向AspNet核心模块。