Make a Windows Service start a windows program.

[UJ]

Is there any way for a windows service to start a windows program ? I have a
service that will need to restart a windows app if it needs to.

TIA - Jeff.

[Michael Nemtsev]

The problem is that service isn't interactive program, thus it's loaded
before user logged on.
You need to check whether the user logged on and only after that start app.

"UJ" wrote:

Is there any way for a windows service to start a windows program ? I have a
service that will need to restart a windows app if it needs to.

TIA - Jeff.

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Michael Nemtsev]

Just to add to my previos post than u can use WMI(System.Management) and
query to the Win32_LogonSession to check for availability of logged user
"Michael Nemtsev" wrote:

The problem is that service isn't interactive program, thus it's loaded
before user logged on.
You need to check whether the user logged on and only after that start app.

"UJ" wrote:

Is there any way for a windows service to start a windows program ? I have a
service that will need to restart a windows app if it needs to.

TIA - Jeff.

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Willy Denoyette [MVP]]

"UJ" <fr**@nowhere.com> wrote in message
news:eA**************@TK2MSFTNGP15.phx.gbl...
| Is there any way for a windows service to start a windows program ? I have
a
| service that will need to restart a windows app if it needs to.
|
| TIA - Jeff.
|
|

No there is no (easy, secure and portable) way to do this. A windows service
runs in a sandboxed non visible desktop, a process started from a service
inherits the same UI context so it will run in the same desktop, second the
service does not run in the security context of a logon user (if any), that
means that the lauched application won't have access to an interactive user
profile, so chances are that it fails to initialize when environmant
variables or profile setting are needed.

Willy.

[KBuser]

I recently had to create a program which could launch a .bat file
through the command prompt, you can try tinkering with this code, I
don't know if it will help you though.

System.Diagnostics.Process proc = new System.Diagnostics.Process();
proc.EnableRaisingEvents = false;
proc.StartInfo.FileName = fileloc;
proc.Start();
proc.WaitForExit();

[Willy Denoyette [MVP]]

"KBuser" <Ky********@gmail.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com...
|I recently had to create a program which could launch a .bat file
| through the command prompt, you can try tinkering with this code, I
| don't know if it will help you though.
|
| System.Diagnostics.Process proc = new System.Diagnostics.Process();
| proc.EnableRaisingEvents = false;
| proc.StartInfo.FileName = fileloc;
| proc.Start();
| proc.WaitForExit();

The OP's question relates to a "windows" program, not a console style
program. Note that the same remark about the user profile applies when
starting a console application, an application that considers it's profile
being loaded when started will fail if started from a service.
In general, services should not start other applications, unless you have
full control of it's UI and profile context.

Willy.

[deko]

> The OP's question relates to a "windows" program, not a console style

program. Note that the same remark about the user profile applies when
starting a console application, an application that considers it's profile
being loaded when started will fail if started from a service.
In general, services should not start other applications, unless you have
full control of it's UI and profile context.
What do you mean when you say:
"unless you have full control of it's UI and profile context"?

I have a similar situation where a service needs to instantiate an object
contained in a WinForms app. The service and the app are installed as a
pair; the UI is used to define the action taken by the service at
pre-defined intervals.

When constructing the assembly in Visual Studio that contains the
application/service pair, should the service and the app be in a separate
namespaces? Does it make any difference? The design goal is to keep the
service and the app a loosely coupled as possible since they run in
different security contexts.

[Willy Denoyette [MVP]]

"deko" <de**@nospam.com> wrote in message
news:qf********************@comcast.com...
|> The OP's question relates to a "windows" program, not a console style
| > program. Note that the same remark about the user profile applies when
| > starting a console application, an application that considers it's
profile
| > being loaded when started will fail if started from a service.
| > In general, services should not start other applications, unless you
have
| > full control of it's UI and profile context.
|
| What do you mean when you say:
|
| > "unless you have full control of it's UI and profile context"?
|

Well I mean that it's possible for the program that gets launched from a
Windows Service session, to load the environment and profile of an
interactive user, it's also possible to migrate the current desktop to the
(visble) interactive desktop, but this is not a trivial task and requires
some thorough understanding of the OS security system.
| I have a similar situation where a service needs to instantiate an object
| contained in a WinForms app. The service and the app are installed as a
| pair; the UI is used to define the action taken by the service at
| pre-defined intervals.
|

I suppose you mean instantiate an object through remoting right? This is not
a problem as long as the WinForms app is started from an interactive logon
session and not from the service.
| When constructing the assembly in Visual Studio that contains the
| application/service pair, should the service and the app be in a separate
| namespaces? Does it make any difference? The design goal is to keep the
| service and the app a loosely coupled as possible since they run in
| different security contexts.
|

Namespace are irrelevant here, what matters is the assemblies, both your
service and the WinForms app. should reside in a separate assembly.

Willy.

[deko]

> Well I mean that it's possible for the program that gets launched from a

Windows Service session, to load the environment and profile of an
interactive user, it's also possible to migrate the current desktop to the
(visble) interactive desktop, but this is not a trivial task and requires
some thorough understanding of the OS security system.
I see.
| I have a similar situation where a service needs to instantiate an
object
| contained in a WinForms app. The service and the app are installed as a
| pair; the UI is used to define the action taken by the service at
| pre-defined intervals.
|

I suppose you mean instantiate an object through remoting right? This is
not
a problem as long as the WinForms app is started from an interactive logon
session and not from the service.

Well, that's the key question - can I do this without remoting?

The service in question will run as a Local Service since it requires full
system privaleges, but it gets launced (only) when a particular user logs
in. The UI is run in the user's security context so only that user can
adjust the parameters of the app's "projects" which are launched by the
service. The "projects" are designed to run silently in the background in a
separate thread and require no interaction with the UI (that's why I am
using a service).

However, the service needs to instantiate the Project object in the WinForms
application - this contains all the business logic. So the service needs to
pass parameters to the Project class's constructor. That's why I thought
the service and the app should be in the same assembly.

So do I really need Remoting here? I just want to instantiate the app's
Project object from the service to allow the app's "project" to run in the
service's thread and security context, while the app's UI is run in the
users's thread and security context.

Does this sound correct?

[Willy Denoyette [MVP]]

"deko" <de**@nospam.com> wrote in message
news:fb********************@comcast.com...
|> Well I mean that it's possible for the program that gets launched from a
| > Windows Service session, to load the environment and profile of an
| > interactive user, it's also possible to migrate the current desktop to
the
| > (visble) interactive desktop, but this is not a trivial task and
requires
| > some thorough understanding of the OS security system.
|
| I see.
|
| > | I have a similar situation where a service needs to instantiate an
| > object
| > | contained in a WinForms app. The service and the app are installed as
a
| > | pair; the UI is used to define the action taken by the service at
| > | pre-defined intervals.
| > |
| >
| > I suppose you mean instantiate an object through remoting right? This is
| > not
| > a problem as long as the WinForms app is started from an interactive
logon
| > session and not from the service.
|
| Well, that's the key question - can I do this without remoting?
|
| The service in question will run as a Local Service since it requires full
| system privaleges, but it gets launced (only) when a particular user logs
| in.
Services aren't lauched when users logs in, services are lauched at system
start-up, Applications that depend on interactive logon session, should
never be implemented as Windows Services, they should be normal applications
that get started at logon (search for Autorun in windows help).


The UI is run in the user's security context so only that user can
| adjust the parameters of the app's "projects" which are launched by the
| service. The "projects" are designed to run silently in the background in
a
| separate thread and require no interaction with the UI (that's why I am
| using a service).
|
| However, the service needs to instantiate the Project object in the
WinForms
| application - this contains all the business logic. So the service needs
to
| pass parameters to the Project class's constructor. That's why I thought
| the service and the app should be in the same assembly.
|

The applications should run in separate processes, so you need a 'way' to
create remote instances of classes residing in a Winforms application. One
way is through remoting (assumed both are managed apps.) and another one is
through COM interop.
One question remain, what's the use of the object instance from the UI
applications perspective? You said, the service creates an instance of class
'Project', how are you going to share the state between these two
applications?
| So do I really need Remoting here? I just want to instantiate the app's
| Project object from the service to allow the app's "project" to run in the
| service's thread and security context, while the app's UI is run in the
| users's thread and security context.
|
| Does this sound correct?
|
Willy.

[UJ]

OK Folks. After much conversation here, let me tell you what my real problem
is and maybe somebody can help me out.

We have a windows app that will run essentially as a kiosk. The program
needs to running all of the time. If an error happens and it shuts down, it
needs to restart.

So I thought about using a service 'watchdog' that would make sure the
program is up and running. If it's not running then it would start it. Seems
easy enough.

The only service account that can make a program run so the user can see it
is LocalSystem and you turn on the Interact with desktop checkbox.

But according to somebody here, this option is not available under Vista.

So my question - how can I make sure a program is always running so that if
it stops running for whatever reason, it will restart again. This could be
because the program crashes or the user shuts it down. We just need to get
the program back up and going (it doesn't have to be instantaneous. It could
take a couple of minutes for it to restart - that's OK.)

Anybody have any thoughts?

TIA - Jeff.

"UJ" <fr**@nowhere.com> wrote in message
news:eA**************@TK2MSFTNGP15.phx.gbl...

Is there any way for a windows service to start a windows program ? I have
a service that will need to restart a windows app if it needs to.

TIA - Jeff.

[deko]

> Services aren't lauched when users logs in, services are lauched at system

start-up, Applications that depend on interactive logon session, should
never be implemented as Windows Services, they should be normal
applications
that get started at logon (search for Autorun in windows help).
Only the UI portion of the app depends on an interactive logon. The service
can start at system boot. I was thinking I could start it at user log on,
but, as you say, that dependency is not what services are all about. good
point.
The applications should run in separate processes, so you need a 'way' to
create remote instances of classes residing in a Winforms application. One
way is through remoting (assumed both are managed apps.) and another one
is
through COM interop.
One question remain, what's the use of the object instance from the UI
applications perspective?
When the service instantiates the Project object from the class in the UI
app (at predefined "run time" intervals), lots of IO stuff happens. From
the UI app's perspective, this "run time" instance does not need to expose
anything. The UI will retreive information about the results of the
completed "project" from an XML file that the service logs to.
You said, the service creates an instance of class
'Project', how are you going to share the state between these two
applications?

That's a good question - is this possible only through remoting? As I
mentioned above, the service will write to an XML file, so I can retrieve
the project results from that, unless I can get these results from the state
of the object instantiated by the service. But is that not possible when
that instance was created by a separate thread? (the service and the UI are
both managed)

Thanks for your comments - I'm still rather green with .NET and appreciate
you insights. There may well be another way to do this, but a service is my
preference because the IO stuff that need to be done is based on system up
time, not user log-in time. And using a service gives me the separate
thread so the user can work with the UI app while a project is running.
Also, a Local Service has will have the required security context to perform
the IO tasks at hand.

PS. The search matches I found for "Autorun" were for CDs and Pocket PC.
Were referring to having a shortcut to the app in the windows startup
folder?

[Willy Denoyette [MVP]]

Make sure it doesn't crash and that the user cannot shut it down?
Who's gone start this application initially? remember it can't be done from
a service.
And what if it keeps crashing? Really, such applications must be robust.

Willy.
"UJ" <fr**@nowhere.com> wrote in message
news:OL****************@TK2MSFTNGP10.phx.gbl...
| OK Folks. After much conversation here, let me tell you what my real
problem
| is and maybe somebody can help me out.
|
| We have a windows app that will run essentially as a kiosk. The program
| needs to running all of the time. If an error happens and it shuts down,
it
| needs to restart.
|
| So I thought about using a service 'watchdog' that would make sure the
| program is up and running. If it's not running then it would start it.
Seems
| easy enough.
|
| The only service account that can make a program run so the user can see
it
| is LocalSystem and you turn on the Interact with desktop checkbox.
|
| But according to somebody here, this option is not available under Vista.
|
| So my question - how can I make sure a program is always running so that
if
| it stops running for whatever reason, it will restart again. This could be
| because the program crashes or the user shuts it down. We just need to get
| the program back up and going (it doesn't have to be instantaneous. It
could
| take a couple of minutes for it to restart - that's OK.)
|
| Anybody have any thoughts?
|
| TIA - Jeff.
|
| "UJ" <fr**@nowhere.com> wrote in message
| news:eA**************@TK2MSFTNGP15.phx.gbl...
| > Is there any way for a windows service to start a windows program ? I
have
| > a service that will need to restart a windows app if it needs to.
| >
| > TIA - Jeff.
| >
| >
|
|

[Ciaran]

Sounds to me like a normal application running with a notify icon rather
than a form would be the best way to achieve what your after. Then it would
just be an icon in the system tray. Or it could just be a window app without
a form.

HTH

Ciaran

"deko" <de**@nospam.com> wrote in message
news:FP********************@comcast.com...

Services aren't lauched when users logs in, services are lauched at
system
start-up, Applications that depend on interactive logon session, should
never be implemented as Windows Services, they should be normal
applications
that get started at logon (search for Autorun in windows help).

Only the UI portion of the app depends on an interactive logon. The
service can start at system boot. I was thinking I could start it at user
log on, but, as you say, that dependency is not what services are all
about. good point.

The applications should run in separate processes, so you need a 'way' to
create remote instances of classes residing in a Winforms application.
One
way is through remoting (assumed both are managed apps.) and another one
is
through COM interop.
One question remain, what's the use of the object instance from the UI
applications perspective?

When the service instantiates the Project object from the class in the UI
app (at predefined "run time" intervals), lots of IO stuff happens. From
the UI app's perspective, this "run time" instance does not need to expose
anything. The UI will retreive information about the results of the
completed "project" from an XML file that the service logs to.

You said, the service creates an instance of class
'Project', how are you going to share the state between these two
applications?

That's a good question - is this possible only through remoting? As I
mentioned above, the service will write to an XML file, so I can retrieve
the project results from that, unless I can get these results from the
state of the object instantiated by the service. But is that not possible
when that instance was created by a separate thread? (the service and the
UI are both managed)

Thanks for your comments - I'm still rather green with .NET and appreciate
you insights. There may well be another way to do this, but a service is
my preference because the IO stuff that need to be done is based on system
up time, not user log-in time. And using a service gives me the separate
thread so the user can work with the UI app while a project is running.
Also, a Local Service has will have the required security context to
perform the IO tasks at hand.

PS. The search matches I found for "Autorun" were for CDs and Pocket PC.
Were referring to having a shortcut to the app in the windows startup
folder?

[Willy Denoyette [MVP]]

"deko" <de**@nospam.com> wrote in message
news:FP********************@comcast.com...
|> Services aren't lauched when users logs in, services are lauched at
system
| > start-up, Applications that depend on interactive logon session, should
| > never be implemented as Windows Services, they should be normal
| > applications
| > that get started at logon (search for Autorun in windows help).
|
| Only the UI portion of the app depends on an interactive logon. The
service
| can start at system boot. I was thinking I could start it at user log on,
| but, as you say, that dependency is not what services are all about. good
| point.
|
| > The applications should run in separate processes, so you need a 'way'
to
| > create remote instances of classes residing in a Winforms application.
One
| > way is through remoting (assumed both are managed apps.) and another one
| > is
| > through COM interop.
| > One question remain, what's the use of the object instance from the UI
| > applications perspective?
|
| When the service instantiates the Project object from the class in the UI
| app (at predefined "run time" intervals), lots of IO stuff happens. From
| the UI app's perspective, this "run time" instance does not need to expose
| anything. The UI will retreive information about the results of the
| completed "project" from an XML file that the service logs to.
|
| > You said, the service creates an instance of class
| > 'Project', how are you going to share the state between these two
| > applications?
|
| That's a good question - is this possible only through remoting? As I
| mentioned above, the service will write to an XML file, so I can retrieve
| the project results from that, unless I can get these results from the
state
| of the object instantiated by the service. But is that not possible when
| that instance was created by a separate thread? (the service and the UI
are
| both managed)
|
| Thanks for your comments - I'm still rather green with .NET and appreciate
| you insights. There may well be another way to do this, but a service is
my
| preference because the IO stuff that need to be done is based on system up
| time, not user log-in time. And using a service gives me the separate
| thread so the user can work with the UI app while a project is running.
| Also, a Local Service has will have the required security context to
perform
| the IO tasks at hand.
|
| PS. The search matches I found for "Autorun" were for CDs and Pocket PC.
| Were referring to having a shortcut to the app in the windows startup
| folder?
|

Ok, it looks like all you need is a single WinForms application, if you need
to perform a privileged task you can run this on a separate thread that
impersonates a privileged user, no remoting needed.

PS. Autoruns are application installed in the startup foler of a specific
user. Search autorun in "Help and Support" from the start menu.

Willy.

[deko]

> Sounds to me like a normal application running with a notify icon rather

than a form would be the best way to achieve what your after. Then it
would just be an icon in the system tray. Or it could just be a window app
without a form.

So you're saying rather than have a UI app and a service to kick it off at
different intervals, have a UI app and a second WinForms app to kick it off?

Perhaps the problem can be described at a higher level like this:

I want to define methods to be run in a UI app - which runs in an
interactive user account's security context - and have those methods
executed in a separate thread - in the Administrator's security context.
The intervals at which the methods are to be run are based on system up time
(not any user log-in time).

So I'm thinking one assembly with a WinForms app, and a Windows Service.
The only problem with this (as far as I can see) is the inter-process
communication between the UI app and the service. But all the service has
to do is instantiate an object from the UI app and no further communication
is needed. The suggested solution is to use Remoting, though I'm wondering
if that's really necessary. The only thing about the service that the UI
app needs to be aware of is whether or not the service is running.

Is there a better way? I'm open to suggestions...

[deko]

> Ok, it looks like all you need is a single WinForms application, if you

need
to perform a privileged task you can run this on a separate thread that
impersonates a privileged user, no remoting needed.

PS. Autoruns are application installed in the startup foler of a specific
user. Search autorun in "Help and Support" from the start menu.

That sounds interesting. I didn't know I could impersonate a privileged
user in a separate thread.

But this does not solve the problem of intervals based on system up time. I
suppose the app could be installed in the All Users profile and the app
placed in the All Users start up folder.

Do you think this would accomplish the task of tracking system up time? Is
there a better way to track system up time from some class in the FCL?
Other suggestions?

Thanks again for your comments.

[UJ]

I plan on making it robust so that hopefully it won't crash.

I'll put it in the startup group for everybody to start it initially.

J.

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:Oz****************@TK2MSFTNGP09.phx.gbl...

Make sure it doesn't crash and that the user cannot shut it down?
Who's gone start this application initially? remember it can't be done
from
a service.
And what if it keeps crashing? Really, such applications must be robust.

Willy.
"UJ" <fr**@nowhere.com> wrote in message
news:OL****************@TK2MSFTNGP10.phx.gbl...
| OK Folks. After much conversation here, let me tell you what my real
problem
| is and maybe somebody can help me out.
|
| We have a windows app that will run essentially as a kiosk. The program
| needs to running all of the time. If an error happens and it shuts down,
it
| needs to restart.
|
| So I thought about using a service 'watchdog' that would make sure the
| program is up and running. If it's not running then it would start it.
Seems
| easy enough.
|
| The only service account that can make a program run so the user can see
it
| is LocalSystem and you turn on the Interact with desktop checkbox.
|
| But according to somebody here, this option is not available under
Vista.
|
| So my question - how can I make sure a program is always running so that
if
| it stops running for whatever reason, it will restart again. This could
be
| because the program crashes or the user shuts it down. We just need to
get
| the program back up and going (it doesn't have to be instantaneous. It
could
| take a couple of minutes for it to restart - that's OK.)
|
| Anybody have any thoughts?
|
| TIA - Jeff.
|
| "UJ" <fr**@nowhere.com> wrote in message
| news:eA**************@TK2MSFTNGP15.phx.gbl...
| > Is there any way for a windows service to start a windows program ? I
have
| > a service that will need to restart a windows app if it needs to.
| >
| > TIA - Jeff.
| >
| >
|
|