0

I have a situation occuring when launching Processes from a Windows service

 _________
|         |           * Process 1
| Service |  -------> * Process ...
|_________|           * Process n

The code used by the service to do so is the following:

    ProcessStartInfo startInfo = new ProcessStartInfo(executablePath, commandlineArgs);
    startInfo.WorkingDirectory = instancePath;
    startInfo.UserName = userB;
    startInfo.Password = passwordSecureString;
    startInfo.Domain = domain;
    startInfo.UseShellExecute = false;

    Process process = new Process
    {
      StartInfo = startInfo,
      EnableRaisingEvents = true,
    };

    process.Start();

Now, I have two accounts - for simplicity's sake, say A and B. The service is being run under the first one and starts the processes using the second one.

  • Both accounts are in the Local Admin group
  • Both accounts have the right to log on as a service
  • Secondary logon service is enabled (just in case, should that matter)
  • OS: Windows Server 2012 R2.

The following table is supposed to indicate what happens in which account constellation.

 _______________
|   |  A  |  B  |      
|===+=====+=====|
| A | OK  |  X  |
|---+-----+-----|
| B |  X  |  OK |
|___|_____|_____|
  • OK - Processes start as expected
  • X - The service gets no error, but processes terminate right away.

...which makes me assume that the user change leads to the problem.

Details on the occuring exception:

enter image description here

After having read upon Error Code 142, here's what I've tried so far:

  • Different Server
  • Windows Updates
  • Redistributable c++ installation
  • coffee, followed by strong liquor, then again coffee

Can anyone relate to this issue?

Sebastian Edelmeier
  • 4,095
  • 3
  • 39
  • 60
  • 1
    Running programs that were not designed to be a service in session 0 is never not a problem. A very common cause for 0xc0000142 is [described here](https://blogs.msdn.microsoft.com/ntdebugging/2007/01/04/desktop-heap-overview/). – Hans Passant Oct 17 '17 at 10:12
  • Thanks, Hans. I have to admit I haven't read the linked article yet, but I will. Actually, I forgot to mention that I have also increased non-interactive Desktop Heap Size (as indicated [here](https://blogs.msdn.microsoft.com/ntdebugging/2007/01/04/desktop-heap-overview/ ). – Sebastian Edelmeier Oct 17 '17 at 12:40
  • An explanation (well, sort of) and a solution can be found [here](https://stackoverflow.com/questions/677874/starting-a-process-with-credentials-from-a-windows-service/30687230#30687230) – Sebastian Edelmeier Oct 24 '17 at 08:21

1 Answers1

1

Stephen Martin has given an explanation of what's going on here, so if you are experiencing the issue described in the original question, the following blog post may be of interest to you:

http://asprosys.blogspot.de/2009/03/perils-and-pitfalls-of-launching.html

Here, Stephen explains

Oops again, where is the process? Check the event log (or you may have received an Application Error pop-up). There should be an entry for Application Error that says that your process was the faulting application, either user32.dll or kernel32.dll was the faulting module and the exception was: 0xC0000142. There may be some minor variation in this but basically it is saying that your application could not initialize. The reason for this is that on initialization, before any application code is run, all processes are attached to a Window Station and all threads are attached to a Desktop but the user you are launching under does not have permission to access the Window Station and Desktop in which your process is being launched, ergo it can't initialize. The security descriptors for the Window Station and Desktop must be adjusted to give AllAccess permission to the user the process is being launched under. This is a devil to do directly in .Net, so you might find the security wrapper classes here useful

If you don't like using Stephen's library, you can also check the other solutions offered here (which I haven't tested yet).

Sebastian Edelmeier
  • 4,095
  • 3
  • 39
  • 60