ASP.NET 7 Docker容器莫名重启：排查.NET ThreadPool通用保护故障

故障排查方向 #

• libc兼容性与完整性问题：Ubuntu 20.04默认的libc-2.31虽稳定，但需确认：容器镜像中的libc是否因隐性更新（如镜像重新构建、源更新）出现版本不一致或文件损坏；宿主机内核更新后是否与容器内libc存在兼容性冲突。
• .NET线程池底层异常：即使无业务工作项，线程池的内部维护线程（如GC辅助线程、线程清理线程）仍可能触发问题。需排查是否为.NET 7特定版本的已知线程池bug，尤其是近两周是否有.NET运行时的补丁更新。
• 宿主机/容器资源异常：通用保护故障常与内存损坏相关，需排查：是否存在OOM Killer触发前的内存碎片化/越界；宿主机CPU是否存在软错误、调度异常；容器的资源限制（CPU/内存配额）是否调整后引发资源竞争。
• 环境隐性变更：回顾近两周的操作：Docker版本是否更新、宿主机内核是否升级、应用的NuGet依赖是否变更、容器启动参数（如挂载目录、环境变量）是否调整。

诊断定位方法 #

• 生成并分析.NET核心转储：在容器中添加环境变量 COMPlus_DbgEnableMiniDump=1 和 COMPlus_DbgMiniDumpType=2，触发崩溃时会生成core dump文件。使用dotnet-dump analyze <dump-file>解析，查看崩溃线程的调用栈，定位是线程池哪类内部操作引发的错误。
• 全面收集系统日志：
  • 查看宿主机dmesg输出，排查是否有内存错误、CPU异常等硬件层面日志；
  • 导出容器完整日志docker logs --tail 1000 <container-id>，检查崩溃前应用是否有隐性异常输出；
  • 对比syslog中故障发生的时间点，关联宿主机的资源监控数据（如top、vmstat历史记录）。
• 验证libc文件完整性：在容器内执行dpkg -s libc6确认版本，再用md5sum /lib/x86_64-linux-gnu/libc-2.31.so计算校验值，与Ubuntu官方源的libc6包校验值对比，排查文件损坏。
• 切换.NET运行时版本：将应用升级到.NET 7的最新补丁版本，或临时回滚到之前稳定运行的版本，观察故障是否消失，以此排除.NET运行时的版本特定bug。
• 硬件与资源测试：在宿主机上运行memtester测试内存稳定性，用stress-ng模拟CPU/内存负载，排查硬件故障；同时调整容器的资源限制（如放宽内存配额），观察是否影响故障发生频率。
• 线程池配置调整测试：尝试修改线程池最小线程数ThreadPool.SetMinThreads，或禁用线程池的某些优化特性（如通过环境变量COMPlus_ThreadPool_ForceMinWorkerThreads=1），看是否能复现或规避故障。

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