does windows have a limitation when a process started by a scheduled task under one set of creds runs another program under a different set of Creds

Question

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.

Answer 1

Ok this post is quite old but 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.

Answer 2

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.