.NET application cannot run external process when previously started by a Windows Service

Question

I have a C# WInForms client with elevated user rights (=Run As Administrator) and a Windows Service that restarts that client automatically if the user accidently exits the client.

If the client is started by the User, everything works fine. If the client is started by the service (LocalSystem account), it does not work as expected.

The client is supposed to a call a 3rd party executable called gemcom, which in turn calls another executable called rubylink. The call to Gemcom works as expected, the call to rubylink does not -- but only when the client was previously started by the 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!

What's important here is that gemcom (according to the error message) can SEE the rubylink.exe but it can't do anything with it, i.e. it can't communicate with it.

I have no influence on the call from gemcom to rubylink. Those are both coming from the 3rd party vendor. Those two are written in C++ in 1999.

I observe this behavior on both Wind7/8 and XP.

Would anybody know why?

Answer 1

The most common cause for such problems is session zero isolation. But since that was introduced in Vista, and you experience the problem with XP, we can probably rule that out.

Which then leaves the user as the most likely explanation. It's quite common for programs to fail when run from the LOCALSYSTEM account. There are a multitude of reasons why the program could fail. Diagnostics from the failing program would lead you to the explanation.

In any case, you are not supposed to use the LOCALSYSTEM account. The official policy from Microsoft has been, for at least 10 years now, possibly more, that you should not use the LOCALSYSTEM account for your services. I suggest that you run your service under a user account created specially for it. But in the short term, to test the theory, just use one of the existing accounts on your test machine.

If that solves the immediate problem, it's still possible that you may encounter session zero isolation problems on operating systems which implement that feature.

Answer 2

It'll probably be a security issue - what happens if you run the service as the user. If that works, then its obvious what the problem is - LocalSystem doesn't start the client with enough permissions to access the rubylink executable. Whether that's because of permissions on the rubylink exe or whether its because LocalSystem doesn't have network permissions to make the calls is something you'll have to check (got any error messages in the event log, or your debug logs)