Introduction to Windows Service Applications

Microsoft Windows services, formerly known as NT services, enable you to create long-running executable applications that run in their own Windows sessions. These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface. These features make services ideal for use on a server or whenever you need long-running functionality that does not interfere with other users who are working on the same computer. You can also run services in the security context of a specific user account that is different from the logged-on user or the default computer account. For more information about services and Windows sessions, see the Windows SDK documentation.

You can easily create services by creating an application that is installed as a service. For example, suppose you want to monitor performance counter data and react to threshold values. You could write a Windows Service application that listens to the performance counter data, deploy the application, and begin collecting and analyzing data.

You create your service as a Microsoft Visual Studio project, defining code within it that controls what commands can be sent to the service and what actions should be taken when those commands are received. Commands that can be sent to a service include starting, pausing, resuming, and stopping the service; you can also execute custom commands.

After you create and build the application, you can install it by running the command-line utility InstallUtil.exe and passing the path to the service’s executable file. You can then use the Services Control Manager to start, stop, pause, resume, and configure your service. You can also accomplish many of these same tasks in the Services node in Server Explorer or by using the ServiceController class.

Service Applications vs. Other Visual Studio Applications

Service applications function differently from many other project types in several ways:

The compiled executable file that a service application project creates must be installed on the server before the project can function in a meaningful way. You cannot debug or run a service application by pressing F5 or F11; you cannot immediately run a service or step into its code. Instead, you must install and start your service, and then attach a debugger to the service’s process. For more information, see How to: Debug Windows Service Applications.

Unlike some types of projects, you must create installation components for service applications. The installation components install and register the service on the server and create an entry for your service with the Windows Services Control Manager. For more information, see How to: Add Installers to Your Service Application.

The Main method for your service application must issue the Run command for the services your project contains. The Run method loads the services into the Services Control Manager on the appropriate server. If you use the Windows Services project template, this method is written for you automatically. Note that loading a service is not the same thing as starting the service. See «Service Lifetime» below for more information.

Windows Service applications run in a different window station than the interactive station of the logged-on user. A window station is a secure object that contains a Clipboard, a set of global atoms, and a group of desktop objects. Because the station of the Windows service is not an interactive station, dialog boxes raised from within a Windows service application will not be seen and may cause your program to stop responding. Similarly, error messages should be logged in the Windows event log rather than raised in the user interface.

The Windows service classes supported by the .NET Framework do not support interaction with interactive stations, that is, the logged-on user. The .NET Framework also does not include classes that represent stations and desktops. If your Windows service must interact with other stations, you will need to access the unmanaged Windows API. For more information, see the Windows SDK documentation.

The interaction of the Windows service with the user or other stations must be carefully designed to include scenarios such as there being no logged on user, or the user having an unexpected set of desktop objects. In some cases, it may be more appropriate to write a Windows application that runs under the control of the user.

Windows service applications run in their own security context and are started before the user logs into the Windows computer on which they are installed. You should plan carefully what user account to run the service within; a service running under the system account has more permissions and privileges than a user account.

Service Lifetime

A service goes through several internal states in its lifetime. First, the service is installed onto the system on which it will run. This process executes the installers for the service project and loads the service into the Services Control Manager for that computer. The Services Control Manager is the central utility provided by Windows to administer services.

After the service has been loaded, it must be started. Starting the service allows it to begin functioning. You can start a service from the Services Control Manager, from Server Explorer, or from code by calling the Start method. The Start method passes processing to the application’s OnStart method and processes any code you have defined there.

A running service can exist in this state indefinitely until it is either stopped or paused or until the computer shuts down. A service can exist in one of three basic states: Running, Paused, or Stopped. The service can also report the state of a pending command: ContinuePending, PausePending, StartPending, or StopPending. These statuses indicate that a command has been issued, such as a command to pause a running service, but has not been carried out yet. You can query the Status to determine what state a service is in, or use the WaitForStatus to carry out an action when any of these states occurs.

You can pause, stop, or resume a service from the Services Control Manager, from Server Explorer, or by calling methods in code. Each of these actions can call an associated procedure in the service (OnStop, OnPause, or OnContinue), in which you can define additional processing to be performed when the service changes state.

Types of Services

There are two types of services you can create in Visual Studio using the .NET Framework. Services that are the only service in a process are assigned the type Win32OwnProcess. Services that share a process with another service are assigned the type Win32ShareProcess. You can retrieve the service type by querying the ServiceType property.

You might occasionally see other service types if you query existing services that were not created in Visual Studio. For more information on these, see the ServiceType.

Services and the ServiceController Component

The ServiceController component is used to connect to an installed service and manipulate its state; using a ServiceController component, you can start and stop a service, pause and continue its functioning, and send custom commands to a service. However, you do not need to use a ServiceController component when you create a service application. In fact, in most cases your ServiceController component should exist in a separate application from the Windows service application that defines your service.

For more information, see ServiceController.

Requirements

Services must be created in a Windows Service application project or another .NET Framework–enabled project that creates an .exe file when built and inherits from the ServiceBase class.

Projects containing Windows services must have installation components for the project and its services. This can be easily accomplished from the Properties window. For more information, see How to: Add Installers to Your Service Application.

Starting GUI application from Windows Service — Approaches

Note: Despite appearing as yet another question of the same matter, it’s not, but choosing the right title seems hard so more appropriate title change is welcome.

I’m trying to solve an issue of starting up GUI application (Windows Forms, .NET) from a service application on Windows 7 Embedded (POS ready), and have come across several solutions, but none of them worked, with one exception I discovered along the way: Using a batch file as a helper file.

Background: There are several posts like this describing why this has been removed and protected, and I understand session 0 isolation, but before any debate dives into why this shouldn’t be done, I’m just trying to get my head around it, as I don’t like the current solution that our company is using.

I’ll be using words «actual app» which represents two GUI applications that I’ve tried to run. One is Windows Forms .NET exe, and second Adobe AIR build exe app.

I’ve successfully set up a test service and have done tests with two accounts:

• Running a service under Local System account (with and without «Interact with desktop» option. )
• Running a service under Administrator account -> This approach does not allow use of CreateProcessAsUser since its already in user session

Under Local System account, it works as expected, and I’ve successfully executed CreateProcessAsUser» command as shown here by murrayu and used his helper class implementation, but with no success. While actual app starts up in GUI under user account, it either doesnt start (AIR), or it has issues and erros, mostly with Access Denied exceptions present (.NET app).

Under Administrator account, the solution using CreateProcessAsUser does not work as mentioned, but using approach B (code at the end of post), which works fine for one app starting another app, did not work. There was no GUI present, as expected in a way.

Third try, solution included helper application that service would call, which then starts up the actual app. Testing this using Local System account and CreateProcessAsUser, then calling approach B in the helper app, resulted in the same behaviour as in first test, where service invoked actual app.

Oddly enough, opening up Notepad.exe, cmd.exe, calc.exe using CreateProcessAsUser works just fine.

Since command line worked, I went down that rabbit hole: The fourth try, solution included a batch file, that included a single command:

Note that it points to the shortcut, as calling exe directly does not work.

To my surprise, this approach worked! The actual app started as if started regularly by executing the file manually.

Now what bugs me the most is — Is there something I haven’t found or try yet? Did I miss something important? The .NET app was ran using Administrator account with full rights when it reported Access denied exceptions, and works totaly fine even under User account (restricted) if executed manually form folder, so there’s really nothing special about it that would seem like a cause of the errors when ran from service.

Most importantly, or most wondering question though: What does the command line / batch do that makes it work? Is it possible to program it’s behaviour / solution in a helper app, or better yet, directly in the service itself?

Also, when wanting to have a service handle GUI application, and where relying on Startup/Autorun is not desirable, what would be the better solution?

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:

1. 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.
2. 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:

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