在我的开发机器上,每当我将IIS应用程序池设置为以32位模式运行时,任何启动的Web应用程序都将挂起.在浏览器中访问时,应用程序将“挂起”大约5-10秒,然后才会收到503错误.应用程序的应用程序池将在此时停止,并且必须显式重新启动.
在64位(默认)模式下,一切都很好,但是每当池切换到32位时,它甚至会立即挂在新的网站中的静态页面上.
当以32位模式发布到我的实时服务器时,相同的应用程序运行正常,因此看起来这是某种配置问题.我启用了失败请求跟踪,但日志中没有显示任何内容.
由于一些旧的COM依赖项,我有几个必须运行32位的应用程序,但我无法让服务器运行.
可能导致此问题的任何想法？
好的,我发现了问题,这是AspNetCore模块,其中64位版本在IIS模块列表中没有位数值而注册.
此问题并非特定于AspNetCoreModule,除了安装模块时未指定bitness64(对于64位版本).如果没有位数值,模块即使在32位模式下也会加载并导致服务器崩溃.
另一个失败点是IIS重写模块,当Windows更新时,它会因类似原因而被软管.每次Windows更新时,重写模块都会为我打破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" />
注意前提条件= bitness64,这是使32位AppPools再次工作所需的全部,因为这可以防止模块加载到32位进程.重新安装AspNet Server运行时可能也可以解决这个问题,但我没有验证这一点.
当应用程序启动时发生503错误时,它们通常与应用程序池相关,并且不会显示在FREB日志中. EventLog确实有更多信息,在这种情况下首先指向重写模块,然后指向AspNet核心模块.
