ASP.NET Core 8 Web API无日志异常崩溃（503）技术求助

我们维护的ASP.NET Core 8 Web API支撑约120个网站，部署在Windows Server 2016服务器上（搭载SQL Server 2019 Web版，含约130个数据库）。目前遇到随机静默崩溃问题，崩溃时无任何异常日志（事件查看器、API自有日志均无记录），仅返回503 Service Unavailable，只能通过回收应用池恢复服务。

已完成排查：

• 检查所有后台任务、递归逻辑，排除无限循环可能性
• 梳理信息级日志及自定义审计日志，未发现崩溃前的异常活动

当前日志配置：

日志级别默认设为Information，Microsoft.AspNetCore和Microsoft.EntityFrameworkCore类别设为Warning；输出目标包含Console和Debug，已启用日志功能

排查方向建议 #

1. 补充核心日志采集，覆盖崩溃场景 #

• 将全局日志级别调整至Debug或Trace，重点监控Microsoft.AspNetCore.Hosting、Microsoft.AspNetCore.Server.IIS、System.Net.Http等关键类别，捕获更细粒度的运行时细节
• 配置Windows事件日志的ASP.NET Core专属通道，确保不遗漏托管层崩溃事件，修改appsettings.json：

  "Logging": {
    "EventLog": {
      "LogLevel": {
        "Default": "Warning",
        "Microsoft.AspNetCore": "Warning"
      }
    }
  }
  

• 启用进程崩溃转储：使用Procdump工具执行procdump -ma -w dotnet.exe，捕获崩溃瞬间的进程内存快照，用于后续分析

2. 排查IIS及服务器资源瓶颈 #

• 实时监控服务器CPU、内存、磁盘IO、网络带宽，重点关注崩溃前是否出现资源耗尽（如内存溢出、磁盘空间不足）
• 检查应用池配置：
  • 确认是否开启快速失败保护（默认连续5次崩溃会暂停应用池），可暂时禁用或调整阈值验证
  • 检查应用池的内存/CPU限制，是否因资源超限被自动回收
  • 查看IIS日志（路径：%SystemDrive%\inetpub\logs\LogFiles），排查崩溃前是否有请求量突增或特殊请求触发问题

3. 数据库层关联排查 #

• 监控SQL Server的阻塞、死锁情况，使用Extended Events捕获长时间运行的查询，确认是否因数据库操作阻塞导致API进程挂起
• 检查数据库连接池配置，验证MaxPoolSize是否合理，排查是否存在连接泄漏
• 梳理130个数据库的连接管理逻辑，检查跨数据库操作时是否存在未释放的资源

4. 深层排查ASP.NET Core运行时异常 #

• 启用ASP.NET Core托管诊断日志，修改web.config添加以下配置，捕获IIS与Kestrel的通信异常：

  <aspNetCore processPath="dotnet" arguments=".\YourApi.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="inprocess">
    <handlerSettings>
      <handlerSetting name="debugFile" value=".\logs\aspnetcore-debug.log" />
      <handlerSetting name="debugLevel" value="TRACE" />
    </handlerSettings>
  </aspNetCore>
  

• 检查是否存在未处理的原生异常（如C++/COM组件抛出的异常），这类异常可能绕过.NET日志系统，可通过Windows错误报告（WER）捕获崩溃事件

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