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)

"Zeeshan Gulzar" <ZeeshanGulzar@discussions.microsoft.com> ¼¶¼g©ó¶l¥ó·s»D:89CAEA36-D639-4814-BB67-570DDED15A9E@microsoft.com...

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