Service Fabric运行应用触发System.ExecutionEngineException问题求助

• 排查PInvoke/COM互操作代码
  错误提示明确指出这类代码是常见诱因，需逐一检查：

  • 核对所有PInvoke签名的参数类型、返回值、调用约定（如StdCall/Cdecl）是否与原生函数完全匹配，可参考官方PInvoke签名库校验
  • 检查COM对象的生命周期管理，确保调用Release()或使用Marshal.ReleaseComObject()时没有重复释放或遗漏，避免栈内存损坏
  • 标记所有unsafe代码块，逐行排查指针操作、内存拷贝等逻辑是否存在越界或非法访问

• 启用CLR调试与验证工具

  • 使用PEVerify.exe验证程序集的可验证性，命令：

    peverify YourServiceAssembly.dll /verbose
    

    定位不可验证的代码片段，这类代码容易触发CLR致命错误
  • 借助Application Verifier挂载到应用进程，开启内存管理、COM对象检查规则，捕获内存 corruption 细节
  • 生成并分析崩溃转储文件：用Procdump或任务管理器捕获崩溃时刻的dump，通过WinDbg加载SOS扩展，执行!analyze -v定位错误发生的具体模块或代码行

• 验证.NET版本兼容性

  • 确认Service Fabric服务的目标框架与配置一致：.NET Framework服务需在ServiceManifest.xml中正确配置ExeHost入口，而非.NET Core/.NET 5的入口类型
  • 排查应用是否混合引用不同.NET版本的组件，例如.NET 5类库被.NET Framework 4.6.1服务调用，这类跨版本引用可能引发CLR内部错误

• 排查第三方依赖

  • 暂时移除所有第三方库，测试最小化应用是否正常运行，逐步恢复依赖以定位问题组件
  • 将涉及非托管代码的第三方库更新至最新稳定版，老旧版本可能存在与当前环境（Windows 11、Service Fabric 9.1）不兼容的情况

• 检查Service Fabric服务配置

  • 确认ServiceManifest.xml中CodePackage的内存配额是否合理，过低的内存限制可能触发非预期的CLR崩溃
  • 创建空的Service Fabric无状态服务测试基础环境是否正常，排除集群或SDK本身的问题（若空服务正常，则问题出在业务代码）

• 更新系统与CLR补丁

  • 确保Windows 11安装了所有累积更新，以及.NET Framework 4.6.1的最新补丁包，部分0x80131623错误是CLR已知bug，可通过官方补丁修复

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