Windows服务生产环境下PrintDocument调用PDF打印机失效问题

这是Windows服务Session 0隔离机制导致的典型兼容性问题，核心触发逻辑如下：

• Windows服务默认运行在系统专属的Session 0非交互会话中，和当前登录用户使用的交互式会话（Session 1、Session 2等）完全隔离，无法访问用户会话的桌面、交互窗口、用户专属配置资源。
• 实体打印机的驱动为会话无关的内核/后台架构，打印任务提交后由系统打印后台服务独立处理，不受会话隔离影响，因此可以正常工作。
• 几乎所有PDF虚拟打印机（包括系统自带的Microsoft Print to PDF、第三方Adobe/Foxit等PDF打印机）都依赖用户态交互组件完成渲染、保存路径选择等流程，无法在非交互的Session 0中正常执行：既无法弹出交互窗口，也无法读取当前用户的打印机配置，最终会出现打印队列显示任务完成、但无任何实际文件输出、全程不抛异常的现象。
• 调试模式下程序直接运行在当前登录用户的交互式会话中，没有会话隔离限制，因此包括PDF打印机在内的所有设备都能正常工作。

按顺序执行以下操作即可快速定位问题：

• 临时将Windows服务的启动方式改为手动，停止服务后直接在当前登录用户的桌面环境下双击运行服务对应的EXE程序，发起PDF打印请求，如果此时PDF打印正常，即可100%确认问题由Session 0隔离导致，和代码逻辑无关。
• 打开服务属性面板，检查服务的登录身份配置：如果使用的是Local System、Local Service、Network Service这类内置系统账号，默认都运行在Session 0会话中，符合问题触发条件。
• 检查PDF打印机的配置：如果开启了打印后弹出保存对话框、输出路径配置为相对路径/系统受保护目录（如C盘根目录、Program Files目录），会进一步放大非交互会话下的失败概率。

根据业务场景选择对应方案即可：

方案1（推荐，全场景兼容） #

将打印执行逻辑从Windows服务中拆分：

• Windows服务仅保留本地API端口监听、请求校验的能力，不直接调用打印相关接口。
• 新增一个轻量托盘后台程序，配置为随用户登录自动启动，运行在当前用户的交互式会话中。
• 服务收到打印请求后，通过本地命名管道/内存映射文件等IPC方式，把打印参数传递给同机运行的托盘程序，由托盘程序调用PrintDocument.Print()方法执行实际打印操作。
  该方案完全绕开Session 0隔离限制，兼容所有实体打印机和PDF虚拟打印机，是本地打印类工具的通用实现架构。

方案2（仅适用于无交互的静默PDF打印场景） #

如果业务不需要用户手动选择PDF保存路径，可以通过调整服务配置解决问题：

• 将Windows服务的登录身份修改为实际使用设备的登录用户账号（不要使用系统内置服务账号），确保服务运行在对应用户的会话上下文下。
• 提前在该用户账号下完成PDF打印机的配置：关闭所有打印时弹出的交互窗口（包括保存对话框、打印完成提示），将PDF输出路径设置为该账号有完整读写权限的绝对路径，不要使用相对路径。
• 代码中调用打印方法时显式指定PDF打印机的完整名称，不要依赖系统默认打印机配置——不同会话、不同用户账号下的默认打印机配置是完全独立的，服务上下文下可能无法正确读取用户设置的默认PDF打印机。

注意：不要尝试通过勾选服务属性中的「允许服务与桌面交互」选项解决问题，该配置在Windows Vista及之后版本的系统中已失效，Session 0弹出的窗口会被系统直接拦截，用户无法看到也无法操作，依然会导致打印静默失败。

内容的提问来源于stack exchange，提问作者Alejandro Ezequiel Mendez