Difference between Process.Start() and Manual Start - c#

I have a single form application which checks user states continuously via timer. I want to start the same .exe by using process.start("C:\inetpub\wwwroot\mywebapp\Checker\checker.exe") in Web Application. The exe appears in System processes list (not appear in application list in Windows Task Manager) after the code executed but it does nothing. It is not changing the user states nor sending Data to Database. But when I start same .exe manually on double clicking, it start working and it also appears in Windows Task Manager Application list and in Process Lists. The .exe is made with C#.Net and is executed file of C# windows application.

When launched by IIS the process will run under the account that started it, which will be the w3wp processes that is running your web application. Because this isn't your account it won't show up in task manager until you select the "show processes from all users" option. When you run it via a double click it is running under your account, so will be visible.
If the changes and database access rely on using your account to gain access then this wont work when it runs from within IIS. For example, if your database connection is done using "Windows Authentication" then it will try to log in as the IIS account, which is unlikely to work.
To fix this you can launch the processes by specifying a username/password in the ProcessStartInfo structure. However, this will require you to embed your password somewhere, which may not be desirable. Alternativly look at changing the database connection string so that you specify the logon credentials explicitly.

Related

Run C# Winform Program on Remote Desktop Connection

Short version: How do I display my Winforms application to users remotely logging on in a Windows Server environment?
Background: I am deploying a C# Winforms application to a number of different Windows servers, some 2008 and some 2012. When a user logs on to one of these servers through remote desktop, I want the form to show up on the user's screen immediately. The program itself is a basic form which writes to the Windows Event Log in the Application section.
What works so far: I have successfully gotten the program to launch on a Windows Server 2008 machine when a user remotely logs on. I did this by creating a scheduled task which was triggered by user logon. Here's the batch file that did it:
SCHTASKS /Create /TN "MyLogonTask" /TR "C:\Path\To\Program.exe" /SC ONLOGON /IT
Here's the problem: When a user other than the one who created the task logs on, the form does not show up for them. To be more specific, the task does start, but the form only shows up for the user who created the task, RATHER THAN the user who actually logged on.
What I've done: I've tried changing the settings around inside the task, as well as launching the program with and without admin privileges. Also, I did try removing and recreating the task with different users, and every time the form only launched for the user who created the scheduled task. So far I have not had any luck with getting the program to display for the correct users.
You could place a shortcut in the StartUp folder. The location of this folder might vary by OS, but on 2012 R2, the user one is here:
C:\Users\[USER]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
and the machine one is here:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

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

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.
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.
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.
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.

How can I run my application when windows session is disconnected?

I have made a simple application in C# and WHITE, which click on a button to clear the logs.
I use to connect to my test machine using Remote Desktop Connection and execute that application. It works fine when my session is connected but whenever i disconnect my session, it stops working.
Is there any way to execute that application when windows session is disconnected?
You could write a Windows Service.
You could also use the task scheduler.
You may not need the C# wrapper, you can add yourself the required entry within the scheduler.
It works fine when my session is connected but whenever i disconnect my session, it stops working.
This is by design. When you disconnect your session, it is locked. When your session is locked, UI automation won't work.
You could hack around this by never locking the session, possibly via different remote desktop tools (VNC/PcAnywhere). But this is definitely a hack.
Instead I suggest a different approach. I recommend avoiding UI automation whenever possible. I have always found UI automation to be flaky and unreliable.
In the comments on your question you said your app is simply UI automation to click a button to clear a log. The logs are generated by the DebugView application.
I suggest you log to a file instead. This feature is mentioned on the web site for DebugView:
http://technet.microsoft.com/en-us/sysinternals/bb896647
You could also look into using remote monitoring.
If size is an issue, you can also look into the "Log file wrapping" and "log-file rollover" features.
Taken from
https://www.ranorex.com/help/latest/ranorex-remote/remote-faq#c13444
Create a batch file on your remote machine and insert the code below:
for /f "skip=1 tokens=3 usebackq" %%s in (
`query user %username%`
) do (
%windir%\System32\tscon.exe %%s /dest:console
)
Save this batch file on the desktop of your remote machine and name it: 'KeepSessionOpen.bat'.
If you need to disconnect the RDP session, you can now simply run this batch file using administrator privileges and your remote machine will remain unlocked.

invoke exe(with GUI) on remote machine

can we invoke exe of application(made in .net) on remote server using local machine.
we have full credentail on all machine to execute process.
how can we achive that ?its require to open GUI on remote machine.
we tried using WMI/.dat file invoke but all opens process on Task Manager & could not lunch GUI..
anyone have idea to accomplish same??
You can use psexec for this.
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
At one point in time, you could write a Windows Service, run it under the local system account, and allow it to interact with the desktop. However, this will only work on Windows XP. Vista (and I assume Windows 7) show the UAC prompt first, which is annoying and sometimes only shows up on the taskbar until it's clicked.
We got around this by writing a WinForms app that had no visibility on its own, but this app watches for a trigger. When the trigger occurs, the program then launches the appropriate exe.
For example, the trigger may specify to open up a web page on our intra net. The program uses the System.Diagnostics.Process.tart() to launch the web page in the default browser.
The trigger can be one of many things... The exe can poll a database, web service, etc. The exe can host a WCF host use remoting, or it could use a FileSystemWatcher.
The most complicated part of writing such an app is figuring out the appropriate trigger. Launching the app is trivial using the System.Diagnostics.Process.
For our situation, we set the program up to just launch when Windows starts, USG a registry setting.
Use PsExec tools
with -i switch
Like
psexec \\remotecomputer -u username -p password -i 2 "your exe loacation"

Screenshot of process under Windows Service

We have to run a process from a windows service and get a screenshot from it.
We tried the BitBlt and PrintWindow Win32 calls, but both give blank (black) bitmaps.
If we run our code from a normal user process, it works just fine.
Is this something that is even possible? Or could there be another method to try?
Things we tried:
Windows service running as Local System, runs process as Local System -> screenshot fails
Windows service running as Administrator, runs process as Administrator -> screenshot fails.
Windows application running as user XYZ, runs a process as XYZ -> screenshot works with both BitBlt or PrintWindow.
Tried checking "Allow service to interact with desktop" from Local System
We also noticed that PrintWindow works better for our case, it works if the window is behind another window.
For other requirements, both the parent and child processes must be under the same user. We can't really use impersonation from one process to another.
Currently i can't find the corresponding links, but the problem is, that a windows service runs in another session than a normal user application.
In XP this was not fully true. Here are all services started in Session 0 and the first user who logs into the system will also run in Session 0. So in that case, tricks like Allow service to interact with desktop work. But if you fast switch to another user he gets the Session 1 and has no chance to interact with the service directly. This is also true if you connect through RDP to a server version (like 2003 or 2008). These logins will also start in a session higher than 0.
Last but not least there is another drawback by using the interaction with the desktop:
If you enable this option and your service is running under the (default) SYSTEM account it won't be able to create a network connection anymore.
The correct way to get a custom GUI that works with a service is to separate them into two processes and do some kind of IPC (inter process communication). So the service will startup when the machine comes up and a GUI application will be started in the user session. In that case the GUI can create a screenshot, send it to the service and the service can do with it, whatever you like.
Have you tried to run as Local System with the "Allow service to interact with desktop" checked?
I don't think this is possible.
We had to change our scenario where our application wasn't started from a service, but was a standard windows program that has a NotifyIcon in the corner.
If someone still finds a real answer, let me know.
It works using Local System with the "Allow service to interact with desktop"
You can set it programatically using this sample code:
http://www.vbforums.com/showthread.php?t=367177 (it's vb.net but very simple)

Categories