Azure Web App（.NET Core 6）偶发崩溃，求排查指导

一、深入分析内存转储文件 #

• 放弃依赖自动生成的MHT报告，用专业工具手动解析：
  • 把转储文件下载到本地，用dotnet-dump工具加载，执行命令：dotnet-dump analyze <dump文件名>
  • 排查堆栈溢出线索：运行clrstack查看线程调用栈，重点找递归调用、无限循环的方法链
  • 分析堆内存占用：用dumpheap -stat查看内存占比最高的类型，定位是否有大量重复创建的对象；再通过dumpheap -type <类型名>列出实例，配合gcroot <对象地址>追踪引用链，确认是否存在内存泄漏
  • 针对OutOfMemoryException，检查大对象堆（LOH）：执行dumpheap -stat -min 85000查看大对象，排查未释放的大数组、长字符串等

二、补充应用级诊断日志 #

• 启用.NET Core详细日志：在appsettings.json中把日志级别设为Debug，添加控制台和文件日志提供者，确保捕获崩溃前的内部错误
• 手动添加内存监控日志：在核心业务方法、依赖调用处加入GC.GetTotalMemory(false)记录内存变化，定位内存骤降的触发点
• 开启ASP.NET Core请求日志：配置Microsoft.AspNetCore.HttpLogging中间件，记录所有请求的路径、参数、处理时间，验证是否有特定请求触发问题（包括之前认为无关的307请求）

三、排查Azure环境相关因素 #

• 检查应用服务配置：确认自动性能分析器的启动时机是否和内存下降同步，临时关闭性能分析器，观察是否仍会崩溃（排除分析器本身干扰）
• 查看Azure门户指标：重点监控内存、CPU利用率、进程数波动，对比崩溃时段的指标变化，确认是否有突发流量、资源限制等外部因素
• 核查部署包：确认代码中是否存在未测试的递归逻辑、无限循环，或第三方库的版本问题（比如依赖包存在内存泄漏/堆栈溢出bug）

四、模拟复现问题 #

• 在本地或测试环境模拟生产负载：用wrk或自定义脚本发送并发请求，尝试复现内存骤降和崩溃，方便实时调试
• 开启本地调试的堆栈溢出捕获：在Visual Studio调试选项中，勾选“启用.NET框架源代码步进”和“捕获StackOverflowException”，复现时直接定位出错代码

五、检查第三方依赖与Azure集成 #

• 排查profiler.monitor.azure.com相关调用：该记录属于Azure性能分析器，确认其配置是否正确、是否存在版本兼容问题；禁用后观察应用状态
• 核查所有NuGet包：查看包的更新日志，确认是否有已知内存问题，尝试升级到最新稳定版，或替换风险依赖包

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