Python编写的Windows服务调试正常，运行时子脚本传参写入b.txt失效

Debug模式和Windows服务的运行上下文完全独立，子进程调用失效的所有问题，本质都是跨上下文的配置、权限、系统隔离机制不匹配导致，和脚本本身的业务逻辑没有关系。

具体失效的触发点 #

• 依赖文件关联启动，在服务上下文解析失败
  你当前的调用逻辑是直接传入C:\\SER\\txt_write.pyw路径，本质是靠系统注册表中记录的*.pyw文件关联，找到对应的pythonw.exe解释器来启动脚本。
  Debug运行时，进程在当前登录用户的环境下，能正常读取当前用户注册表的文件关联配置*，顺利找到解释器；但Windows服务默认运行在系统级的Session 0隔离上下文，这个上下文要么没有当前用户的Python关联配置，要么因为注册表访问权限的问题找不到对应的解释器路径，启动直接失败。代码里设置的shell=True会进一步放大这个问题——服务上下文的shell启动默认工作路径是C:\Windows\System32，更没法正确完成文件关联解析。
• Session 0隔离机制的启动限制
  从Windows Vista开始，所有系统服务都被隔离在独立的Session 0中，普通用户的交互程序运行在更高编号的用户Session下。pythonw.exe是GUI子系统的程序，在没有授予服务交互桌面权限的前提下，没法正常加载GUI运行环境，启动后会因为环境不匹配直接退出，全程不会有任何错误弹窗。
• 工作目录错位导致的“找不到文件”假象
  主服务里写a.txt用的是绝对路径C:\\SER\\a.txt，所以写入正常。但如果txt_write.pyw内部是用相对路径写b.txt，那么服务上下文的默认工作目录是C:\\Windows\\System32，就算子进程正常启动，也会把b.txt写到System32目录下，在C:\SER目录下自然找不到生成的文件，看起来就像调用逻辑完全失效。
• 错误完全无感知
  当前的subprocess调用没有任何返回值检查、错误输出捕获，子进程启动失败、运行报错的所有信息都会被静默吞掉，排查的时候看不到任何线索。

针对性修复方案 #

• 去掉对文件关联的依赖，显式指定解释器的绝对路径启动脚本，同时关闭shell解析：

  def run(param):
      # 替换成你当前环境下pythonw.exe的实际绝对路径
      python_interpreter = r"C:\Program Files\Python311\pythonw.exe"
      subprocess.Popen(
          [python_interpreter, r"C:\SER\txt_write.pyw", param],
          shell=False,
          cwd=r"C:\SER", # 显式指定子进程的工作目录，避免相对路径错位
          stderr=subprocess.PIPE # 捕获错误输出，方便后续排查
      )
  

• 如果遇到pythonw.exe在Session 0下启动失败的问题，可以换成控制台版的python.exe，启动时传入CREATE_NO_WINDOW参数避免弹出黑窗口，绕过GUI子系统加载失败的问题：

  subprocess.Popen(
      [python_interpreter, r"C:\SER\txt_write.pyw", param],
      shell=False,
      cwd=r"C:\SER",
      creationflags=subprocess.CREATE_NO_WINDOW
  )
  

• 增加简单的子进程健康检查逻辑，比如定期遍历Popen返回的进程对象，判断退出码，把异常信息写入服务目录下的日志文件，避免静默失败。

为什么Debug模式下所有功能正常 #

Debug运行时，整个程序是以当前登录用户的身份、在用户自己的交互Session下运行的，拥有完整的用户环境变量、文件关联配置、桌面访问权限，所有依赖用户环境的调用逻辑都能正常工作。一旦安装为系统服务，程序被切换到Session 0的系统账户上下文，那些依赖用户环境、桌面权限、用户级配置的逻辑就会全部失效——只有像“用绝对路径写入a.txt”这类不依赖环境、不依赖桌面、不依赖用户配置的逻辑，才能保持正常运行。

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