Starting processes via Windows Service

Question

4.00/5 (1 vote)

See more:

Hi!

We have a requirement to start few processes before accessing our application.

One way to do this is to make a batch file and run it automatically during windows startup.

Another way, which we prefer doing, is to start these processes via WindowsService, which can be started and stopped via our application interface.

Question thus is:
Using "WindowsService" project in VS/C#, can we call Process.Start() inside the OnStart() method of a WindowsService? Doing so in our code does not start the intended process. Are we missing something here?

Thanks for your time.

Posted 3-Apr-11 2:30am

TSKNaidu

Add a Solution

2 solutions

Solution 2

You probably do not understand what a Windows Service is.
Let's not mix up different things. It's quite possible to develop some application which can start either as service or as an interactive application. This is actually very useful, for debugging, for example. I do use this approach and enjoy its robustness.

The problem is different. When you manage to do that, this is like having two application in one. Even it they share some code (which is the main purpose of such design), this is really two different application. If you run such application through System.Diagnostics.Process.Run, it is not a Windows Service by definition. If you run it via Service Controller, it is not an interactive application — by definition. These two modes never run at the same time.

One useful hint: see the property System.Environment.UserInteractive.

—SA

Posted 4-Apr-11 19:00pm

Sergey Alexandrovich Kryukov

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Dave Kreskowiak · Accepted Answer · 2011-04-03T03:10:00

Solution 1

Completely wrong approaches. About the worst way to do this is to start user-mode applications from a service.

If your services are installed on the machine and setup to start Automatic, then they'll start when Windows starts.

If they are setup manually, then you can start/stop them right from your application, provided the users have the permissions to do so.

On Windows 7, you can also setup triggers to start services. I haven't looked into this at all, so you'll have to do the research, but your application should be able to start the services via a trigger, which should not need user permissions to do so.

Posted 3-Apr-11 3:10am

Dave Kreskowiak

Comments

#realJSOP 3-Apr-11 9:17am

5 - Proposed as answer

TSKNaidu 4-Apr-11 8:45am

Thanks for taking time to reflect on the question.

Are you suggesting that it is not advisable to start out-of-process servers (executables) from a windows service? Can you pl be specific why it is not?

Appreciate your time.

Dave Kreskowiak 4-Apr-11 19:07pm

Yes, starting user-mode applications from a windows service is problematic at best. Services run no matter is anyone is logged into the machine or not. Also, it is entirely possible to have multiple people logged in on the machine at the same time.

If your application requires some service to run, those services should not depend on nor launch any other applications. They should be able to exist completly on their own. The application itself should start any services that it requires, not the other way around.

Sergey Alexandrovich Kryukov 5-Apr-11 1:01am

Dave, there is more to it, please see my Answer.
--SA

TSKNaidu 5-Apr-11 9:13am

Thanks Dave for taking time to bring clarity to the issue posted.

Coming back to our requirement and as mentioned in our question (option 2), we intend to start few out-of-process servers (apps) as windows services.

And, you are suggesting to better start these apps directly from our application.

This leaves us with the first option (bundle these apps into a batch file and run the batch file).

While still technically unclear about why these apps cannot be "automated" to run without our application, I looked around for a "container" that could possibly run these apps as Windows Service.

And, I would like to share with you the following links that throws more light on how to run an external process as a windows service:

1. http://support.microsoft.com/kb/251192

2. http://www.firedaemon.com/download-firedaemon.php

3. http://www.instantfundas.com/2008/08/how-to-run-windows-applications-as.html

Appreciate your time to address our question.

best regards.

Dave Kreskowiak 5-Apr-11 12:16pm

I don't need all the explanations. I know how to run processes as services.

You seem to be hell-bent on using services when it doesn't even sound like you need them, with the brief requirements you've given so far. You do not need a batch file to start up services, nor do you need one to launch other applications from your own. You can start services and launch other executables from inside your own application quite easily.

From the hints you're dropping, it sounds as though you only need to launch a couple of executables that expose functionality only if the main application is running. You don't need a service for this. Your "service" apps can run on their own without any user interface and still communicate with your main app the same as if they were a service. Though, this all depends on what these apps are doing, of course.

TSKNaidu 5-Apr-11 13:25pm

Are you saying that we just use Process.Start() within our application? And, this is the easiest way of launching the apps?

If it is, then, what we are looking for is to take out these Process.Start() calls and automate their launch via Windows Services.

Thanks for your time.

Dave Kreskowiak 5-Apr-11 15:48pm

Are you saying that we just use Process.Start() within our application? And, this is the easiest way of launching the apps?
Yes, this is the easiest way to launch an executable.

If it is, then, what we are looking for is to take out these Process.Start() calls and automate their launch via Windows Services.
Again, if you're talking about launching a user-mode application from a Windows Service, DO NOT DO THIS!

If your application needs these services in order to run, you can start and stop services from inside your application, not by using Process.Start!, but by using the ServiceController class.

TSKNaidu 6-Apr-11 2:12am

Dave,

Thanks for your patience and taking time to address my question.

As things are becoming clearer and for my own understanding, I have captured the understanding as a flowchart (not the literal meaning of it!). Here it is:

====== Begin =======
logic("Adding an application to a window service")
{
if("user-mode application")
{
//do not add
return;
}
else
{
//Add the application as a Windows service using any of the following external tools
///1. sc.exe (part of Windows 2003 resource kit)
///2. instsrv.exe and srvany.exe( same as above )
///3. Firedeamon commercial utility

//Within our application (client that consumes the services):
///1. Using methods in 'System.ServiceProcess.ServiceController' class, monitor and control the above added Windows service.
}
}
====== End ========

Now, coming back to our original requirement, we are looking for another tool (#4 in the above logic - after Firedaemon utility). This tool is a small C# application that can be internally developed using 'Windows Service' project template provided by Visual Studio IDE.

Thanks again for all your time in helping us in meeting our requirements.

best regards.

Dave Kreskowiak 6-Apr-11 8:07am

Wait a minute. Are you now asking if you can run the same .EXE as both a Windows Forms app AND a Service??

Possible? Yes.
Good idea? Absolutely not.

This would not be what I call "production quality code".

Also, you would not install the service at runtime of your app. This would force your users to require admin permissions on the machine. You would install the service(s) at install-time, not run-time. You would them start/stop your services in the Windows Forms at run-time.

If you wanted to do anything resembling this, you would keep the Windows Forms app and Service app .EXEs as seperate executables. Keeping your business and data logic in a seperate .DLL project refered to by both .EXE projects.

TSKNaidu 7-Apr-11 5:49am

Are you now asking if you can run the same .EXE as both a Windows Forms app AND a Service?

No! Absolutely not! On the other hand, the service that is being created is consumed by our Windows forms app.

Coming back to our requirement, using C# with a 'Windows Service' project template, how can we create a "container" like "srvany.exe" to host a windows application to run as a service?

Thanks again for all your help and appreciate your time.

best regards,
Srikanth

Dave Kreskowiak 7-Apr-11 8:02am

Coming back to our requirement, using C# with a 'Windows Service' project template, how can we create a "container" like "srvany.exe" to host a windows application to run as a service?

You don't. You write your service as normal. You do NOT use SRVANY or similar utilities. By using them, all you're doing is adding a layer of complexity and making it harder to debug your app and find bugs after it's gone to production.

You write NORMAL dedicated services and NORMAL Windows Forms apps. You setup your services as normal Windows Services at install-time, NOT run-time. You can start/stop those services from your Windows Forms apps using ServiceController class.

You do NOT write "containers" to run .EXE's as services. You do NOT "install" or "SRVANY" up a service from your Windows Forms application at run-time.

Going against these principles gives you nothing in the way of usability and/or performance, but DOES give your more complexity with no benefit and raises the cost of supporting your application.

TSKNaidu 12-Apr-11 8:46am

Dave,

Appreciate your support.

You said: You do NOT write "containers" to run .EXE's as services.

Understanding that SRVANY is a utility that runs an EXE as a windows service, how did the guys who wrote this utility have implemented it (to run an EXE as a windows service)?

And, we are looking for an answer to this how, so that we can implement this using C#.

Thanks again for all your perseverance and help.

best regards,
Srikanth

Dave Kreskowiak 12-Apr-11 13:28pm

Understanding that SRVANY is a utility that runs an EXE as a windows service, how did the guys who wrote this utility have implemented it (to run an EXE as a windows service)?

Just because you can, doesn't make it a good idea. There are pitfalls to doing this. First, your application has to be tolerant of being stopped ANYWHERE during its execution. That means if your app keeps open files or other unmanaged resources, it has to be able to reopen those resources the next time it's launched. Also, any unmanaged handles will NOT be freed! Your application WILL leak handles, at the very least, if they are not managed properly. Your code will also NOT get the chance to commit any data it's caching or has not had a chance to commit for some reason. Your code MUST also be able to run without any user interaction at all.

If you insist on doing this, just use SRVANY and save yourself the time duplicating something that already exists.

Sergey Alexandrovich Kryukov 5-Apr-11 0:51am

Correct, my 5.
--SA

Kim Togo 5-Apr-11 16:32pm

Under Windows XP, a Windows Service can interactive with the logged in user. But under Windows Vista /Windows 7 and Windows Server 2008 it is not possible. All Windows Service is isolated and is running session id 0. Where logged in users uses session id 1 and up.