VB.Net服务使用Excel Interop导出文件报0x800706BE RPC失败问题咨询

你遇到的问题确实是Excel Interop在Windows服务环境下运行的固有局限性，和你当前的导出代码逻辑没有直接关系——同一段代码在交互会话的窗体应用中能正常运行，恰恰可以证明代码本身没有逻辑缺陷。

从设计层面，微软从未提供对非交互服务/会话0场景下调用Office系列COM组件的支持。Excel Interop本质是通过进程外COM机制拉起独立的EXCEL.EXE后台进程，这个进程的运行依赖完整的用户交互桌面环境，哪怕你配置了隐藏窗口、不显示操作界面，进程启动和运行过程中依然会调用大量依赖交互会话的系统API，在Windows服务默认运行的隔离会话0中，这类API调用会直接导致Excel进程异常崩溃，最终抛出远程过程调用失败的0x800706BE错误。

你之前按照通用攻略配置的几个常规方案，仅临时适配了早期Office版本的部分报错，没有从根本上解决会话隔离的核心矛盾：

• 创建的C:\Windows\SysWOW64\config\systemprofile\Desktop目录，仅能绕开Office启动时“检查是否存在桌面目录”的前置校验，无法解决后续运行过程中对交互桌面环境的依赖
• 使用IO.Path.GetTempFileName生成的本地临时文件，如果运行服务的账户没有配置对应的COM交互权限，依然会触发Excel进程的异常终止
• 将服务运行身份从本地系统账户切换为指定用户账户时，如果没有提前让该用户完成一次完整的桌面登录、配置DCOM组件的远程激活权限，该用户在服务环境下的运行上下文依然是未初始化桌面环境的非交互状态，和本地系统账户的运行状态没有本质区别

不要强行通过调整DCOM配置硬跑Excel Interop，这种方式的稳定性极差，长期运行下的偶发崩溃概率极高，可优先选择以下低维护成本的方案：

• 完全替换Excel Interop的依赖，改用纯.NET实现的无界面Excel读写组件（如NPOI、EPPlus、ClosedXML），这类组件不需要拉起独立的Excel进程，直接按照Office Open XML格式读写文件，天然适配服务的非交互运行环境
• 如果业务必须使用Excel的高级功能（如复杂宏计算、特殊格式渲染），无法通过上述组件实现，可以将导出模块从Windows服务中拆分出来，部署为用户登录后自动启动的后台桌面程序，Windows服务仅负责采集日志、存储SQL Server，将需要导出的数据传递给桌面程序完成Excel生成、上传SharePoint的流程

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