Notepad.exe within Windows Service ?

[Guest]

This application is sort of remote execution. I use C#.NET

I have created a windows service listening a port say 4000. When client
connected to the listener; send a special packet containing executable file
name with command line arguments, server start this exe at own machine(server
itself).

Server start this process by using Process class, but the problem is that

if i say the exe is notepad.exe. server started notepad successfully but in
background and does'nt show it's GUI but can view at task manager->Processes
tab not appear in task manager->Application tab.

ProductInstaller modifiers is public, Account = LocalSystem.

Without Windows Service wrapper, this application is working perfectly

Please help urgently. Thanks in advance
Zeeshan Gulzar

 

[Zvonko Keber]

Did you try setting the "Allow service to interact with desktop" inside:

Computer management --> Services --> "your service" --> Properties --> Log
On tab

When you change it, you need to restart the service.

 

[Guest]

Thanks Keber
Yes i have tested it but still in background.

 

[Lau Lei Cheong]

Are you logging in the console session (i.e. Session #0)?

The UI of an interactive service will only appear on console session, but
not other user session.(Normally remote desktops)

 

[Guest]

Thanks for your replys
This problem is solved by
Process.StartInfo.WindowStyle = ProcessWindowStyle.Normal
what i am facing is, due to any other value of ProcessWindowStyle

Thanks again

 

[Richard Grimes]

Thanks Keber
Yes i have tested it but still in background.

Don't do this. It is considered a bad thing to do. The reason is that
the GUI system is a secure object called a Window Station. Windows are
shown on another secure object called a Desktop and each Desktop can
exist in only one Window Station. Using the "Allow service to interact
with desktop" is effectively a hack to get around the Window Station
security. The accepted way to do this is to run a process in the
interactive Window Station (ie the interactive user account) that
listens for communication from the service (for example via .NET
remoting) and the interactive app will then show windows to the user.

Of course, if you are writing an app that runs in the interative user
Window Station and listens on some interprocess communication endpoint
then you may as well get this application to listen on the port and
forget about the service. Which raises the question, why do you need
your listener to be a service? If you need it to run when the system
starts then the startup folder or the registry run key is just as good.
If you need it for the security aspect, think carefully if you really do
need to run under LOCALSYSTEM or some other named privileged account
(because events will be audited against those specific accounts and you
may think that it is more useful to do auditing against the interactive
user account).

In many cases when people say they *must* write a service, if they think
it through they come to the conclusion that an ordinary process can do
the job just as well.

Richard