I\'m running into a strange behavior with a powershell Start-Process call.
Here is the call:
$process = start-process `
\"C:\\somepath\\MyBinar
start-process
is an 'alias' for System.Diagnostics.Process.Start()
, so yes, it does make use of CreateProcessWithLogonW()
. As noted, this method can't be called from a service process, it can only be called from an 'interactive' process. The caveat to that "only" is the one you've discovered - that when you aren't changing credentials, it can at least get the process started. (This may actually even be a bug - a Microsoft Support engineer I spoke with about this issue was "surprised" it worked at all.)
The only (supported) way to launch another process from inside a service process is to use the native Win32 API method CreateProcessAsUser()
. An example of how to do this is C#.NET can be found in the answer to the question mentioned in edit #2.
A Windows process must launched as part of a user session. If the launching process is running as part of an interactive session - the kind where you logged in using CTRL+ALT+DELETE and have a desktop open - then you can use CreateProcessWithLogonW()
, which will use your current user session automatically. If the launching process is a service, or "batch" process (as Scheduled Tasks are), then the launching process must either create a new user session (or identify an existing one) to launch the new process in (which is what the code in the afore-mentioned answer does.)
There is a Microsoft KB 2701373 on a similar issue with a hotfix available. Helped me to resolve the problem.
Only solution I have found so far is to disable UAC (set EnableLUA to 0 = Admin approval mode in Local Security Policy). So, it definitely seem to be a file/folder/registry access problem which the UAC ignores when disabled.