BizTalk 2016 Feature Pack 2+ESB Toolkit 2.4调用CreateFaultMessage抛出异常

这种同代码跨服务器报错的情况，大概率是两台机器的ESB配置细节没对齐，既然你已经重装了ESB Toolkit、检查过应用池，那可以从这些更细节的配置维度入手排查：

1. 核对ESB异常处理核心配置文件 #

• 找到两台服务器上的ExceptionHandling.config（一般在C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\Exception Handling目录下）：
  • 仔细对比<ExceptionHandling>节点下的<Policy>规则，尤其是和故障消息构造相关的配置，比如是否有某台机器少了关键的异常处理策略
  • 检查<FaultContracts>节点，确认代码里用到的故障契约类型在两台机器的配置里都有定义，缺失的话直接会导致创建故障消息失败
• 另外通过BizTalk管理控制台的ESB配置工具，对比两台服务器的数据库级配置，确保故障消息模板、异常路由规则完全同步

2. 深挖权限配置细节 #

• 虽然你检查过应用池，但要确认应用池账户有没有ESB异常管理数据库的读写权限，还有访问BizTalk MessageBox数据库的权限——毕竟CreateFaultMessage()要把异常日志写到ESB数据库里，权限不够肯定报错
• 看看服务器本地的ESB服务账户（比如默认的ESB_Admin或者你们自定义的账户），是不是在两台机器上加入的权限组完全一致，比如BizTalk Server Administrators、BizTalk Application Users这些组有没有漏加

3. 验证程序集版本与依赖一致性 #

• 去GAC里查看两台机器的Microsoft.Practices.ESB.ExceptionHandling.dll版本是不是完全一样，版本不匹配很容易出现方法调用的兼容性问题
• 顺带检查依赖的其他ESB程序集，比如Microsoft.Practices.ESB.dll、Microsoft.Practices.ESB.ExceptionHandling.Logging.dll，确保它们的版本统一，而且都正确注册到GAC了
• 重点看事件查看器里的应用日志！找到调用CreateFaultMessage()时抛出的具体异常信息（比如类型加载失败、找不到配置节之类的），这玩意儿能直接帮你定位到根因，比瞎排查效率高多了

4. 确认BizTalk运行时配置 #

• 检查两台服务器的BizTalk宿主实例：承载ESB相关应用的Host Instance是不是已经启动，而且宿主账户的权限配置正确
• 确认ESB Exception Handling Orchestration在故障服务器上是不是正确部署并启动了，CreateFaultMessage()很多时候依赖这个编排的后台服务支撑

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