IIS 10随机崩溃问题排查求助（Windows Server 2019环境）

一、需重点排查的日志位置 #

• .NET Core 应用日志
  检查每个应用的自定义日志目录（如C:\inetpub\wwwroot\[应用名]\logs，具体路径取决于你使用的日志框架如Serilog/NLog的配置），查看是否存在未捕获的异常记录，尤其是请求处理后期、应用启动阶段的错误——这类错误可能导致自定义错误页逻辑未触发。同时在Windows事件查看器的应用程序日志中，筛选源为.NET Runtime的事件，重点关注Event ID 1026（.NET未处理异常），这类日志常记录应用级崩溃细节。
• IIS 失败请求跟踪日志
  在IIS管理器中为目标站点启用失败请求跟踪，设置跟踪规则覆盖状态码500及空白响应（如状态码200但无内容）。跟踪日志生成于C:\inetpub\logs\FailedReqLogFiles，可完整查看请求从IIS到ASP.NET Core模块的流转过程，判断问题出在IIS层还是应用层。
• IIS HTTPERR日志
  路径为C:\Windows\System32\LogFiles\HTTPERR，这里记录IIS无法处理的请求（如连接超时、队列溢出、端口占用），空白页问题大概率与这类日志相关。
• ASP.NET Core 模块日志
  在应用的web.config中开启stdoutLogEnabled="true"，设置stdoutLogFile=".\logs\stdout"，日志会记录应用启动失败、进程意外退出的原因；同时可查看C:\Windows\System32\LogFiles\W3SVC[站点ID]下的模块交互日志。

二、潜在问题方向 #

• 线程池耗尽
  每个网站190线程数对于IO密集型的ASP.NET Core应用偏高（正常情况下，线程数应与CPU核心数正相关，8核服务器通常在几十到一百左右）。排查应用中是否存在大量同步阻塞操作（如Task.Wait()、.Result调用，或同步IO），这类操作会占满线程池，导致新请求无法被处理，此时IIS会直接返回默认500或空白页，自定义错误页逻辑无法触发。可使用dotnet counters monitor --process-id [应用PID] System.Threading.ThreadPool监控线程池工作线程、IO线程数量及队列长度，若队列持续增长则可确认问题。
• 应用进程崩溃/频繁重启
  检查任务管理器中dotnet进程的启动时间，或在Windows事件查看器的系统日志中筛选源为IIS-W3SVC-WP的事件，查看是否存在进程回收记录（Event ID 1074、1076）。应用进程崩溃或重启期间，请求会直接触发IIS默认错误页或空白响应。同时排查内存泄漏问题——即使NewRelic显示内存充足，也可能存在进程重启释放内存的情况，可通过dotnet-dump或内存快照分析未释放对象。
• IIS与应用错误页配置冲突
  检查MVC网站的web.config中<httpErrors>节点是否正确配置：

  <httpErrors errorMode="Custom" existingResponse="Replace">
    <remove statusCode="500" subStatusCode="-1" />
    <error statusCode="500" path="/Error/500" responseMode="ExecuteURL" />
  </httpErrors>
  

  同时确认Program.cs中是否启用了app.UseExceptionHandler("/Error/500")。若请求未到达ASP.NET Core中间件就出错（如应用启动失败、IIS模块异常），自定义错误页不会生效，IIS会返回默认500。
• IIS应用池配置问题
  检查应用池的回收设置，是否存在固定时间回收、内存阈值回收等规则，回收期间会导致请求失败。另外查看应用池的队列长度（默认1000），若请求队列满，IIS会直接截断请求，返回空白页或错误响应。
• 底层系统/网络问题
  执行netstat -ano查看TCP连接状态，若存在大量TIME_WAIT或CLOSE_WAIT连接，可能导致端口耗尽，新请求无法建立连接。同时排查近期Windows Server或.NET 9的更新记录，确认是否存在兼容性问题导致IIS与ASP.NET Core模块交互异常。

内容的提问来源于stack exchange，提问作者Matthew Warr