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:
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.
Run a process from a windows service as the current user
I currently have a windows service that is running under the System Account. My problem is that i need to start certain processes from within the service as the current logged on user. I have all the code etc to get the current logged on user / Active session.
My problem is that i need spawn a process as the logged on user but will not know the user credentials etc.
The service is .net compiled service and i expect that i need to use some Pinvoke methods to get a handle of one of the current users process in order to duplicate it and lunch as process with the handle.
Unfortunately i cannot find any good documentation / solution on how to implement it?
If someone is able to give me some guidance / example i would highly appreciate it.
* Updated * I think i have explained this incorrectly and need to reajust according to what i actually require. I do not necessarily want to launch a new process, i just want to impersonate the logged on user. I have been so wrapped up at looking at CreateProcess etc i have lead myself down a path of create a new process as the current logged in user (which is not particularly what i want to do).
In turn i just want to run some code under the current user context (Impersonate the current Logged on user)?
2 Answers 2
One option is to have background application that automatically starts when user logs on and listens to commands from your service through WCF, or thrift, or by just monitoring some file and reading command from there.
Another option is to do what you originally asked for — launch using windows API. But the code is quite scary. Here is a sample, that you can use. It will execute any command line under currently active user session, with CreateProcessInConsoleSession method:
As is so common with these types of questions about Windows services, you’re operating in the mindset of a single-user operating system. The whole reason you decided to write your app as a service was because you were running into conflicts between your mental model of a single-user OS and the reality of a multi-user OS. Unfortunately, a service didn’t solve all of your problems and now you’re trying to figure out how to accomplish step two in the ultimately-doomed hacked design.
The fact is, you cannot be guaranteed that there is a «logged on user». If no one has logged on to the workstation, there will be no one logged on, yet your service will still be running.
Even if you somehow got past this by ensuring that someone will always be logged on (impossible), then you would run into the situation where multiple users are logged on. Then which one should your service start the process as? Should it just pick one of them randomly?
And is it necessary in your case to distinguish between users logged on locally to the console and those who are logged on remotely? Remember that remote users won’t have a local console.
If you could somehow get past all of these hurdles (unfortunately, probably by burying your head in the sand and continuing to pretend that Windows is a single-user OS), you could make use of the WTSGetActiveConsoleSessionId function to obtain the current session ID, the WTSQueryUserToken function to obtain the user token corresponding to that session ID, and then finally the CreateProcessAsUser function to launch your process in the context of that user. If there is one. And they have the appropriate privileges. And the physical console is not attached to a dummy session. And you’re not running a server SKU that allows multiple active console sessions. And…
If you could decide on a particular user whose account you wish to use to start the auxiliary process, you could log on that user, manipulate their user token, execute the process, and finally close the process and log out the user. The CreateProcessWithLogonUser function wraps up a lot of this drudgery for you, making the code a lot more svelte. But appearances can be deceiving, and this still has some massive security implications that you probably do not completely understand if you’re asking this question in the first place. And you really cannot afford to not understand security risks like this.
Besides, users that are logged in with LogonUser (which is done for you automatically when you use the CreateProcessWithLogonUser function) lack a window station and desktop on which they can launch interactive processes. So if the process you wish to launch in the context of that user will show any kind of UI, you’re out of luck. Windows will kill your app as soon as it tries to access a desktop for which it lacks the requisite permissions. There is no way, from a Windows service, to obtain the handle of a desktop that will be useful to you (which goes a long way towards explaining the general rule you probably already know, that services cannot display any type of UI).
