13

So i have a simple example, where i have app A, which has some hard coded creds to user X , a local admin, and then it launches app B with those Credentials using a hardcoded absolute path. Both A and B and dotnet console applications, however they don't interact with the console, just just write out info to a file.

When i run A interactively (under my Creds, by double clicking, or through CMD.exe , or an interactive PowerShell session it runs fine. successfully calling B

When i run it through a scheduled tasks with A being under by creds, and calling B with user X the error code of the Process.Start(mystartinfo) is -1073741502 or 0xC0000142 in hex which means "The application failed to initialize properly"

However if i run the scheduled task calling A with user X credentials it works..

I made this small test mostly because i see similar behaviour when trying to do "start-job -Credential" in powershell from either a scheduled task or remoting, or calling start-process in powershell or System.Diagnostic>Process.Start from within PowerShell in the same scenarios. At first i thought it was a bug in PowerShell but it seems to be deeper.. Either Windows or specifically Dotnet and i want to know if this is known/documented and if there are any workarounds.

klumsy
  • 4,081
  • 5
  • 32
  • 42
  • Anything meaningful in the task scheduler log? – David Brabant Apr 17 '12 at 06:25
  • no as the parent process (the one that the scheduled task runs) just catches and logs the exception, the task scheduler just logs a successful execution. – klumsy Apr 17 '12 at 16:18
  • Total shot in the dark. I know scheduled tasks require the "Log on as batch job", since you can successfully run A with user X directly, I'm not sure if this applies. http://msdn.microsoft.com/en-us/library/ms813942.aspx – Adam Driscoll Apr 19 '12 at 03:37
  • in my own example i found that under the different credentials workingdirectory is undetermined and causes an issue. If i determine it myself then it works fine (i haven't tried FROM powershell), so maybe the problem with PowerShell is not setting the workingdirectory when different credentials are stored? – klumsy Apr 20 '12 at 21:36

3 Answers3

2

I'm running in the same issue (powershell start-process fails with exit code -1073741502 when run through a service).

Apparently this is related to this issue: Why is this process crashing as soon as it is launched?

Process.Start internally calls CreateProcessWithLogonW(CPLW) when credentials are specified. CreateProcessWithLogonW cannot be called from a Windows Service Environment (such as an IIS WCF service). It can only be called from an Interactive Process (an application launched by a user who logged on via CTRL-ALT-DELETE).

I guess it's something similar when you are running a scheduled task, it's run in a Windows Service Environment.
Probably the API native calls you are inducing are prevented to be run from a service.

TylerH
  • 20,799
  • 66
  • 75
  • 101
John-Philip
  • 3,392
  • 2
  • 23
  • 52
1

I encountered such a behavior caused under Windows Server 2008R2. My C# application (A) starts a process B.

Process B fails to run without access to Windows Desktop, [fails to Call Windows API CreateWindow();] which is prevented to run when run as a Service (or by scheduler) (this is to prevent a well known user privilege escalation using "at /interactive cmd.exe")

I recommend to check the environment you are using and check if it is the same problem. If so, then you should search for how to remove references to the CreateWindow() API call or handle it correctly.

Unfortunately, I had no access to Process B and therefore had no success in solving this issue. I ended up deploying the solution on a Server 2003 machine.

Bart
  • 19,692
  • 7
  • 68
  • 77
Tomer W
  • 3,395
  • 2
  • 29
  • 44
  • thanks, i am aware of that. In my real world scenario its all about PowerShell V3 and scripts. but in my prepro i mentioned above, i just made very simple console apps that did not Create any windows. – klumsy Jul 10 '12 at 00:06
1

So you have a process A which runs from a Scheduled Task (Non Interactive) as you and launches process B as X (local admin) Clarifications:

  • Are You an admin on that box?
  • Does B need a window handle or console handle?

You can try to use ProcessMonitor to see which call exactly fails. My guess is that B is trying to interact with the desktop and is getting denied the permission to do that.

When you are logged in say as user A, and you launch an interactive process using scheduler, the window would come up fine. But if you are logged in as user B (say a guest user) and launch an interactive process which runs as A (say a local admin), then the system really has a problem as to what it should do about showing the UI

To summarize, if you have an interactive process which uses the credentials of the non logged in user, there is no clear winner as to what is the right thing to do.

IDK
  • 178
  • 8