我有一个C＃WInForms客户端具有提升的用户权限（=以管理员身份运行）和一个Windows服务，如果用户意外退出客户端，它会自动重启该客户端。
如果用户启动了客户端，一切正常。 如果客户端由服务启动（ LocalSystem 帐户），则无法按预期工作。
客户端应该调用名为 gemcom 的第三方可执行文件，该第三方可执行文件又调用另一个名为 rubylink 的可执行文件。 对Gemcom的调用按预期工作，对rubylink的调用不会 - ，但仅限于以前由Windows服务启动客户端 。
Case 1: Client is started by User
A) client.exe is running in *John* account
B) gemcom.exe is called (runs in John account)
C) rubylink.exe is called (runs in John account)
--> OK!
Case 2: Client is started by Service
A) client.exe is running in SYSTEM account
B) gemcom.exe is called (runs in SYSTEM account)
C) rubylink.exe cannot be called
--> FAIL!
这里重要的是gemcom（根据错误消息）可以查看rubylink.exe但它无法对它做任何事情，即它无法与之通信。
我对从gemcom到rubylink的调用没有影响。这些都来自第三方供应商。这两个是1999年用C ++编写的。
我在Wind7 / 8和XP上都观察到了这种行为。
有人知道为什么吗？
答案 0 :(得分：0)
这可能是一个安全问题 - 如果您以用户身份运行服务会发生什么。如果可行，那么问题就在于它显而易见 - LocalSystem没有以足够的权限启动客户端来访问rubylink可执行文件。这是因为rubylink exe上的权限还是因为LocalSystem没有网络权限来进行调用，所以你必须检查（在事件日志或调试日志中得到任何错误消息）
答案 1 :(得分：0)
此类问题的最常见原因是会话零隔离。但是，由于这是在Vista中引入的，并且您遇到了XP的问题，我们可能会排除这一点。
然后将用户留作最可能的解释。程序在从LOCALSYSTEM帐户运行时失败是很常见的。程序可能失败的原因有很多。失败程序的诊断将引导您解释。
在任何情况下，您都不应该使用LOCALSYSTEM帐户。微软的官方政策至少已有10年，可能更多，您不应该使用LOCALSYSTEM帐户进行服务。我建议您在专门为其创建的用户帐户下运行您的服务。但是在短期内，为了测试理论，只需使用测试机器上的一个现有帐户。
如果这样可以解决当前的问题，那么您可能会在实现该功能的操作系统上遇到会话零隔离问题。