How to use a service to start a regular windows application

[illegal.prime]

Hi all, I have a service that needs to start a regular windows
application.

I'm running the service as ServiceAccount.LocalSystem.

But, when it starts the process (using Process.Start) the GUI for the
application doesn't appear - however, I can see the process in the
TaskManager.

Now, feel free to mention that starting a regular windows application
using the LocalSystem account is a security risk and therefore I
shouldn't be doing this. But, what I'm more interested in is why the
GUI for this application isn't appearing in the current architecture.

I read in a few different places something about:
INTERACT WITH DESKTOP
and
RUN INTERACTIVE

Is it possible that the LocalSystem account doesn't have those flags
and that is why the GUI for this application doesn't appear? If so,
can I use impersonation or something to use an account that will show
the GUI for this application?

Thanks,
Novice

 

[Guest]

What is the goal? Do you want to start a specific program at a specific time?
just put an entry into Task Scheduler to run it on whatever schedule you want.

If you want to start the program when the OS starts, there are a slew of
registry entries you can look up that will enable you to do that, too.

If that's the goal, the general advice you'll get here is not to have the
overhead of a windows service to do this. Especially since services are
designed to start when the OS starts BEFORE any "Real user" has logged on and
would be able to see UI dialogs.
Peter

 

[Sunil]

You cant do what you are trying to do with Process.Start.
You would have to PInvoke CreateProcess() Win32 API and set the Desktop of
the process to the default interactive desktop.
Process.Start sets the desktop to the desktop of whatever process started it
(which in this case is not interactive)

Here is the code.
http://sayala.com/?page_id=126

 

[Chris Dunaway]

Hi all, I have a service that needs to start a regular windows
application.

I'm running the service as ServiceAccount.LocalSystem.

But, when it starts the process (using Process.Start) the GUI for the
application doesn't appear - however, I can see the process in the
TaskManager.

Now, feel free to mention that starting a regular windows application
using the LocalSystem account is a security risk and therefore I
shouldn't be doing this. But, what I'm more interested in is why the
GUI for this application isn't appearing in the current architecture.

I read in a few different places something about:
INTERACT WITH DESKTOP
and
RUN INTERACTIVE

Is it possible that the LocalSystem account doesn't have those flags
and that is why the GUI for this application doesn't appear? If so,
can I use impersonation or something to use an account that will show
the GUI for this application?

And keep in mind that under Windows Vista, services will no longer be
able to interact with the desktop. If you intend to use this app on
Vista, you will have to use a different approach.

This is a good link:

http://tinyurl.com/y8s7l7

From the article:

Session 0 Isolation

Brief Description

In Windows XP, Windows Server 2003, and earlier versions of the Windows
operating system, all services run in the same session as the first
user who logs on to the console. This session is called Session 0.
Running services and user applications together in Session 0 poses a
security risk because services run at elevated privilege and therefore
are targets for malicious agents who are looking for a means to elevate
their own privilege level.

The Microsoft Windows Vista operating system mitigates this security
risk by isolating services in Session 0 and making Session 0
non-interactive. In Windows Vista, only system processes and services
run in Session 0. The first user logs on to Session 1, and subsequent
users log on to subsequent sessions. This means that services never run
in the same session as users' applications and are therefore protected
from attacks that originate in application code.

Specific examples of affected driver classes include:

* Printer drivers, which are loaded by the spooler service.
* All drivers authored with the User Mode Driver Framework (UMDF),
because these drivers are hosted by a process in Session 0.

Application classes affected by this feature:

* Services that create UI.
* A service that tries to use window message functions such as
SendMessage and PostMessage to communicate with an application.
* Applications creating globally named objects.