ASP.NET Core应用ISAPI报运行状况异常触发回收，如何获取详细错误

观测到的事件本质是IIS工作进程加载的ISAPI扩展主动向工作进程上报非健康状态，触发对应应用池回收。默认系统配置下不会记录该上报动作携带的具体故障信息，可通过以下分层配置逐步定位根因，拿到精细化错误明细：

启用失败请求跟踪模块锁定触发异常的具体ISAPI组件 #

• 针对目标应用池创建失败请求跟踪规则，匹配范围覆盖全量请求，重点勾选与ISAPI回调、健康状态上报相关的事件节点，包括ISAPI调用ReportUnhealthy、GetHealthStatus方法的全链路记录
• 调整跟踪日志的缓冲区容量为64MB以上，避免全链路调用信息被截断
• 日志生成后可首先定位到触发非健康上报的具体ISAPI DLL物理路径，直接排除无关组件的排查范围

调整应用池配置捕获错误上下文 #

• 临时关闭目标应用池的快速失败保护、定期自动回收、闲置超时回收功能，排除非ISAPI因素触发的误回收干扰，确保观测到的回收动作完全来自ISAPI的主动申请
• 开启应用池事件日志的详细记录模式，将健康检查失败、工作进程回收的完整上下文（而非通用描述文本）写入系统事件日志
• 调整工作进程对ISAPI上报信息的处理逻辑，不丢弃ISAPI返回的自定义错误内容，直接将其纳入事件记录

补全ISAPI组件自身的日志输出 #

• 针对IIS内置ISAPI组件，逐一开启组件级别的错误日志开关：
  • 旧版ASP扩展：开启脚本错误日志写入功能，关闭自定义错误页拦截，记录脚本超时、COM组件调用失败、内存访问异常等明细
  • 旧版ASP.NET兼容ISAPI：临时将站点的自定义错误模式调整为关闭状态，开启组件调试日志，记录程序集加载失败、权限不足、未处理运行时异常等信息
• 针对第三方ISAPI组件，查阅组件自带的配置项开启调试日志，记录组件主动上报非健康状态前的最后执行操作、附带的故障参数
• 配置完成后复现之前的异常请求场景，即可从组件日志中拿到具体的故障原因

兜底定位手段 #

• 若上述配置仍无明细输出，可在工作进程启动后临时附加调试器，捕获ISAPI上报非健康状态时的完整调用栈
• 逐一排查ISAPI组件的基础运行环境：
  • 校验ISAPI DLL及依赖项的物理路径读取权限
  • 确认ISAPI组件的32/64位架构与应用池的“启用32位应用”配置匹配
  • 排查依赖系统DLL是否缺失、版本是否与当前Windows服务器兼容

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