通过DTExec.exe运行SSIS父包时触发Appcrash Kernelbase.dll错误求解决方案

我之前帮几个同行排查过类似的SSIS 64位环境下Kernelbase.dll崩溃的问题，结合你提到的子包适配推测，给你几个实打实的排查和修复方向：

• 强制子包以32位模式运行
  很多时候SSIS子包依赖的组件（比如旧版OLE DB驱动、第三方数据源）只支持32位，在64位环境下直接运行就会触发这类底层崩溃。你可以在父包的Execute Package Task里，找到Run64BitRuntime属性，把它设为False。如果是通过SQL Server Agent执行，还要在作业步骤的配置里勾选“使用32位运行时”——毕竟SQL Server Agent本身是64位的，得手动指定才会切换到32位环境。

• 单独测试每个子包，排查数据源适配问题
  别直接跑父包，先在64位测试服务器上单独运行每个子包，看哪个会触发错误。重点检查子包里的数据源连接：比如有些ODBC驱动在64位系统里的安装路径和32位不同，或者需要专门安装64位版本的驱动。要是单个子包运行就崩溃，那问题大概率出在这个子包的组件适配性上。

• 扒开Windows事件日志找真实崩溃原因
  Kernelbase.dll的错误提示太笼统了，Windows事件查看器里的应用程序日志才藏着真相。你可以过滤事件来源为Application Error的条目，找到对应的崩溃记录，里面会有具体的异常代码、调用栈，甚至能指出是哪个模块（比如自定义脚本组件、第三方DLL）触发的崩溃，这能帮你精准定位问题。

• 检查自定义.NET组件的编译目标
  如果子包里用到了自定义的脚本任务或.NET组件，一定要确认它们的编译目标是AnyCPU或者x64，不能是x86。另外，组件引用的第三方库也得有对应的64位版本，不然在64位环境下加载就会出问题。

• 修复系统文件（最后一招）
  虽然概率不高，但系统文件损坏也可能导致Kernelbase.dll报错。你可以打开管理员命令提示符，运行sfc /scannow扫描并修复系统文件。如果还是不行，再尝试用regsvr32 kernelbase.dll重新注册这个文件——不过Windows 10及以上版本一般不需要手动注册，先试sfc扫描就好。

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