0

我有一个具有提升的用户权限（=以管理员身份运行）的 C# WInForms 客户端和一个 Windows 服务，如果用户意外退出客户端，它会自动重新启动该客户端。

如果客户端由用户启动，则一切正常。如果客户端是由服务（LocalSystem帐户）启动的，它不会按预期工作。

客户端应该调用名为gemcom的第 3 方可执行文件，而后者又调用另一个名为 ruby​​link 的可执行文件。对 Gemcom 的调用按预期工作，对 ruby​​link 的调用没有——但只有当客户端先前由 Windows Service 启动时。

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（根据错误消息）可以看到 ruby​​link.exe 但它不能用它做任何事情，即它不能与它通信。

我对 gemcom 到 ruby​​link 的调用没有影响。这些都来自第 3 方供应商。这两个是在 1999 年用 C++ 编写的。

我在 Wind7/8 和 XP 上都观察到了这种行为。

有人会知道为什么吗？

4

2 回答 2

0

这可能是一个安全问题 - 如果您以用户身份运行服务会发生什么。如果这可行，那么问题就很明显了——LocalSystem 没有以足够的权限启动客户端来访问 ruby​​link 可执行文件。无论是因为对 ruby​​link exe 的权限还是因为 LocalSystem 没有网络权限来进行调用，您都必须检查（在事件日志或调试日志中收到任何错误消息）

于 2013-04-09T11:42:18.907 回答
0

此类问题的最常见原因是会话零隔离。但是由于这是在 Vista 中引入的，并且您在 XP 中遇到了问题，我们可能可以排除这种情况。

然后将用户作为最可能的解释。从 LOCALSYSTEM 帐户运行程序时失败是很常见的。程序失败的原因有很多。来自失败程序的诊断将引导您进行解释。

在任何情况下，您都不应该使用 LOCALSYSTEM 帐户。至少 10 年以来，Microsoft 的官方政策一直是，您不应该使用 LOCALSYSTEM 帐户来提供服务。我建议您在专门为其创建的用户帐户下运行您的服务。但在短期内，要测试理论，只需使用测试机器上的现有帐户之一即可。

如果这解决了眼前的问题，那么您仍然可能会在实现该功能的操作系统上遇到会话零隔离问题。

于 2013-04-09T11:42:48.360 回答