SSIS读取大型Excel文件偶发Unexpected Termination异常求助

从Windows事件日志的崩溃栈可以直接定位：故障出在Office原生核心组件mso99Lwin32client.dll，异常码0xc000041d是非托管代码层抛出的未处理访问违例，属于ACE.OLEDB驱动的进程级崩溃。这类崩溃发生在SSIS托管代码的捕获范围之外，会直接杀掉ISServerExec.exe运行进程，所以Integration Services Catalog里拿不到任何业务层报错，只会显示Unexpected Termination。
你遇到的「连续稳定运行数月、偶发崩溃、重跑立刻恢复、批量处理数十个大Excel文件」的特征，完全匹配ACE引擎的已知稳定性问题：ACE是为桌面端Office交互设计的COM组件，本身没有做服务端长时间批量处理的适配，连续加载解析数十MB级别的Excel文件时，会出现非托管内存泄漏、临时COM对象未释放、跨线程调用指针越界的问题，资源占用积累到阈值就会触发崩溃，没有固定复现路径，所以公开资料很难找到对应特定版本的修复方案。

• 第一优先级：做进程隔离，从架构上避免单点崩溃打崩整个流程
  不要在同一个SSIS执行进程里用ForEach循环连续处理全部60-70个文件。把单个Excel文件的解析、写入逻辑拆成独立子包，主包循环时通过「执行包任务」调用子包，同时将执行包任务的ExecuteOutOfProcess属性设置为True。配置后每个文件的解析都会启动独立的ISServerExec子进程，单个文件处理完成后子进程自动销毁，ACE驱动累积的内存泄漏、残留句柄会随进程销毁完全释放，哪怕单个文件触发驱动崩溃，也只会终止对应子进程，不会影响整个批次的处理。你还可以给子包调用配置重试规则，单个文件失败自动重跑2-3次，完全覆盖偶发故障的场景。
• 调整驱动与连接配置，降低崩溃概率
  你当前使用的连接字符串可以做针对性优化：
  1. 追加配置;Persist Security Info=False;Mode=Read，强制驱动以只读独占模式打开文件，减少文件锁、共享访问、缓存写入相关的异常
  2. 将MAXSCANROWS参数值从104567改为0，即扫描全表判定列类型，避免大文件扫描时行指针越界触发崩溃；注意配合这个配置，需要提前在服务器注册表中找到对应位数ACE驱动的TypeGuessRows项，将值也设为0，解决IMEX模式下默认仅扫描前8行判定类型的问题
  3. 检查服务器上的Office组件安装情况：确保ACE驱动的位数和SSIS运行位数完全一致（SQL Server 2017的SSIS默认是64位运行时），不要在同服务器混装32位Office客户端、32位ACE驱动和64位ACE驱动，版本混装是mso99Lwin32client.dll偶发崩溃的最高发诱因；安装完成后将ACE驱动升级到对应大版本的最新累积更新，微软已经在后续更新中修复了多个大文件解析时的访问违例问题。
• 增加兜底自愈逻辑，把故障影响降到0
  在没法完全替换ACE驱动的前提下，加两层兜底即可把这类偶发故障的业务影响降到0：
  1. 给循环内的文件处理节点配置3次重试，每次重试间隔30秒，这类偶发的驱动崩溃99%以上场景下第一次重跑就能成功
  2. 在包启动逻辑中增加已处理文件记录：每成功解析写入一个文件，就把文件名记录到本地日志表/日志文件中，包重跑时自动跳过已经处理完成的文件，避免重跑导致重复写入数据。
• 长期替代方案
  如果想彻底摆脱ACE驱动的稳定性问题，可以把Excel解析逻辑替换为不依赖Office组件的纯.NET实现：在脚本任务中使用NPOI、ClosedXML这类托管库读取Excel内容，这类库不调用任何Office原生COM组件，不会出现非托管层的进程崩溃问题，处理40-70MB级别的Excel时，采用SAX事件驱动模式读取，性能比ACE驱动高30%以上，也不需要在服务器安装任何Office相关组件。

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