Run program from windows service
This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.
Asked by:
Question
Dear Microsoft support team,
We have build an window based kiosk application in WPF. Now we need to launch/run the .exe using the window service. We tried several example using process.start() but neither able to start nor getting error.
Please assist me on this will be highly appreciate.
All replies
You cannot run a UI from a Windows service. Services run in session 0 and are not tied to any user. The user would never see the UI.
If you want to show a UI for a kiosk like app then set it as the startup app and use group policies to lock down the machine. Setting it as the shell may work as Stefan mentioned but I’ve never tried it.
Michael Taylor http://www.michaeltaylorp3.net
Hi Vipin Panwar,
If there any form in your WPF application? Or only classes in your application? If there is no form, when you open the .exe file, nothing happened.
How do you open the WPF application with process.start()? Could your provide some code for us to test?
Here is a simple example for your reference.
MSDN Community Support
Please remember to click «Mark as Answer» the responses that resolved your issue, and to click «Unmark as Answer» if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.
Thanks for your quick response!
Let me make it simple, Let say we need to run Notepad.exe from window service. Reason is we need to keep monitor a specific exe, Is it running or not on a window 10 machine. If not then the window service will launch the Notepad.exe.
In my case, the only difference is we have our own build exe instead of Notepad.exe.
Please let us know if you still need more clarification.
Thanks for your prompt response.
Yes the WPF based window application have UI forms. on launch it will launch the home page have some feature on pages.
Let me make it simple, Let say we need to run Notepad.exe from window service. Reason is we need to keep monitor a specific exe, Is it running or not on a window 10 machine. If not then the window service will launch the Notepad.exe.
In my case, the only difference is we have our own build exe instead of Notepad.exe.
Please let us know if you still need more clarification.
How can I run an EXE program from a Windows Service using C#?
How can I run an EXE program from a Windows Service using C#?
This is my code:
When I run this service, the application is not starting.
What’s wrong with my code?
9 Answers 9
This will never work, at least not under Windows Vista or later. The key problem is that you’re trying to execute this from within a Windows Service, rather than a standard Windows application. The code you’ve shown will work perfectly in a Windows Forms, WPF, or Console application, but it won’t work at all in a Windows Service.
Windows Services cannot start additional applications because they are not running in the context of any particular user. Unlike regular Windows applications, services are now run in an isolated session and are prohibited from interacting with a user or the desktop. This leaves no place for the application to be run.
More information is available in the answers to these related questions:
The best solution to your problem, as you’ve probably figured out by now, is to create a standard Windows application instead of a service. These are designed to be run by a particular user and are associated with that user’s desktop. This way, you can run additional applications whenever you want, using the code that you’ve already shown.
Another possible solution, assuming that your Console application does not require an interface or output of any sort, is to instruct the process not to create a window. This will prevent Windows from blocking the creation of your process, because it will no longer request that a Console window be created. You can find the relevant code in this answer to a related question.
i have tried this article Code Project, it is working fine for me. I have used the code too. article is excellent in explanation with screenshot.
I am adding necessary explanation to this scenario
You have just booted up your computer and are about to log on. When you log on, the system assigns you a unique Session ID. In Windows Vista, the first User to log on to the computer is assigned a Session ID of 1 by the OS. The next User to log on will be assigned a Session ID of 2. And so on and so forth. You can view the Session ID assigned to each logged on User from the Users tab in Task Manager.
But your windows service is brought under session ID of 0. This session is isolated from other sessions. This ultimately prevent the windows service to invoke the application running under user session’s like 1 or 2.
In order to invoke the application from windows service you need to copy the control from winlogon.exe which acts as present logged user as shown in below screenshot.
you can use from windows task scheduler for this purpose, there are many libraries like TaskScheduler that help you.
for example consider we want to scheduling a task that will executes once five seconds later:
notepad.exe will be executed five seconds later.
for details and more information please go to wiki
if you know which class and method in that assembly you need, you can invoke it yourself like this:
Top answer with most upvotes isn’t wrong but still the opposite of what I would post. I say it will totally work to start an exe file and you can do this in the context of any user. Logically you just can’t have any user interface or ask for user input.
Here is my advice:
- Create a simple Console Application that does what your service should do right on start without user interaction. I really recommend not using the Windows Service project type especially because you (currently) can’t using .NET Core.
- Add code to start your exe you want to call from service
Example to start e.g. plink.exe. You could even listen to the output:
- Use NSSM (Non-Sucking Service Manager) to register that Console Application as service. NSSM can be controlled via command line and can show an UI to configure the service or you configure it via command line. You can run the service in the context of any user if you know the login data of that user.
I took LocalSystem account which is default and more than Local Service. It worked fine without having to enter login information of a specific user. I didn’t even tick the checkbox «Allow service to interact with desktop» which you could if you need higher permissions.
Lastly I just want to say how funny it is that the top answer says quite the opposite of my answer and still both of us are right it’s just how you interpret the question :-D. If you now say but you can’t with the windows service project type — You CAN but I had this before and installation was sketchy and it was maybe kind of an unintentional hack until I found NSSM.
You can execute an .exe from a Windows service very well in Windows XP. I have done it myself in the past.
You need to make sure you had checked the option «Allow to interact with the Desktop» in the Windows service properties. If that is not done, it will not execute.
I need to check in Windows 7 or Vista as these versions requires additional security privileges so it may throw an error, but I am quite sure it can be achieved either directly or indirectly. For XP I am certain as I had done it myself.
First, we are going to create a Windows Service that runs under the System account. This service will be responsible for spawning an interactive process within the currently active User’s Session. This newly created process will display a UI and run with full admin rights. When the first User logs on to the computer, this service will be started and will be running in Session0; however the process that this service spawns will be running on the desktop of the currently logged on User. We will refer to this service as the LoaderService.
Next, the winlogon.exe process is responsible for managing User login and logout procedures. We know that every User who logs on to the computer will have a unique Session ID and a corresponding winlogon.exe process associated with their Session. Now, we mentioned above, the LoaderService runs under the System account. We also confirmed that each winlogon.exe process on the computer runs under the System account. Because the System account is the owner of both the LoaderService and the winlogon.exe processes, our LoaderService can copy the access token (and Session ID) of the winlogon.exe process and then call the Win32 API function CreateProcessAsUser to launch a process into the currently active Session of the logged on User. Since the Session ID located within the access token of the copied winlogon.exe process is greater than 0, we can launch an interactive process using that token.
I think You are copying the .exe to different location. This might be the problem I guess. When you copy the exe, you are not copying its dependencies.
So, what you can do is, put all dependent dlls in GAC so that any .net exe can access it
Else, do not copy the exe to new location. Just create a environment variable and call the exe in your c#. Since the path is defined in environment variables, the exe is can be accessed by your c# program.
previously I had some kind of same issue in my c#.net 3.5 project in which I was trying to run a .exe file from c#.net code and that exe was nothing but the another project exe(where i added few supporting dlls for my functionality) and those dlls methods I was using in my exe application. At last I resolved this by creating that application as a separate project to the same solution and i added that project output to my deployment project. According to this scenario I answered, If its not what he wants then I am extremely sorry.
How to start a process from windows service into currently logged in user’s session
I need to start a program from Windows Service. That program is a user UI application. Moreover that application should be started under specific user account.
The problem is that a Window Services run in session #0, but a logged in user sessions are 1,2 etc.
So the question is: how to start a process from a window service in such a way that it run in currently logged in user’s session?
I’d emphasis on that the question is not about how to start a process under specific account (it’s obvious — Process.Start(new ProcessStartInfo(«..») < UserName=. Password=..>)). Even if I install my windows to run under current user account the service will run in session #0 anyway. Setting «Allow service to interact with desktop» doesn’t help.
My windows service is .net-based.
UPDATE: first of all, .NET has nothing to do here, it’s actually pure Win32 thing. Here’s what I’m doing. The following code is in my windows service (C# using win32 function via P/Inkove, I skipped import signatures, they’re all here — http://www.pinvoke.net/default.aspx/advapi32/CreateProcessWithLogonW.html):
The code goes to the line «Notepad has been started by WatchdogService. Exitcode: » + exitCode. Exitcode is 3221225794. And there’s no any new notepad started. Where am I wrong?
8 Answers 8
The problem with Shrike’s answer is that it does not work with a user connected over RDP.
Here is my solution, which properly determines the current user’s session before creating the process. It has been tested to work on XP and 7.
Everything you need is wrapped up into a single .NET class with a static method:
It’s a terrific helpful post about starting a new process in interactive session from windows service on Vista/7.
For non-LocalSystem services, the basic idea is:
Enumerate the process to get the handle of the Explorer.
OpenProcessToken should give you the access token. Note : The account under which your service is running must have appropriate privileges to call this API and get process token.
Once you have the token call CreateProcessAsUser with this token. This token already have the right session Id.
It’s a bad idea to do so. Although probably not totally impossible, Microsoft did everything to make this as hard as possible, as it enables so-called Shatter Attacks. See what Larry Osterman wrote about it back in 2005:
The primary reason for this being a bad idea is that interactive services enable a class of threats known as «Shatter» attacks (because they «shatter windows», I believe).
If you do a search for «shatter attack», you can see some details of how these security threats work. Microsoft also published KB article 327618 which extends the documentation about interactive services, and Michael Howard wrote an article about interactive services for the MSDN Library. Initially the shatter attacks went after windows components that had background window message pumps (which have long been fixed), but they’ve also been used to attack 3rd party services that pop up UI.
The second reason it’s a bad idea is that the SERVICE_INTERACTIVE_PROCESS flag simply doesn’t work correctly. The service UI pops up in the system session (normally session 0). If, on the other hand, the user is running in another session, the user never sees the UI. There are two main scenarios that have a user connecting in another session — Terminal Services, and Fast User Switching. TS isn’t that common, but in home scenarios where there are multiple people using a single computer, FUS is often enabled (we have 4 people logged in pretty much all the time on the computer in our kitchen, for example).
The third reason that interactive services is a bad idea is that interactive services aren’t guaranteed to work with Windows Vista 🙂 As a part of the security hardening process that went into Windows Vista, interactive users log onto sessions other than the system session — the first interactive user runs in session 1, not session 0. This has the effect of totally cutting shatter attacks off at the knees — user apps can’t interact with high privilege windows running in services.
The proposed workaround would be to use an application in the system tray of the user.
If you can safely ignore the issues and warnings above, you might follow the instructions given here: