I was using this feature in earlier Windows release like XP and NT. I was able to run a GUI from a Windows service. But it is not possible in the later versions.

What is the reason behind the removal of this feature? Why can't Windows services have a GUI?

5 Answers 5


Mainly security reasons.

As I understand it, when a windows service creates GUI controls such as a MessageBox, they were normally only seen in the session that the services runs in ie Session 0 which also used to be the first user logged on locally or by someone logging on using mstsc /admin. Hence this user would see these controls and could interact with the service.

But for security reasons, Session 0 is now reserved and the first user to log on will be given a new session and hence not see the GUI Controls.

Since this breaks quite a lot of services, for compatibility, there is a process (see this MSDN blog) that attempts to detect if any messages are being displayed and popups with a warning 'A program running on this computer is trying to display a message' and allows you to view or ignore the message.

Microsoft have a WhitePaper on this subject which you can download from here

I would also suspect that another minor reason is because the feature was misused/misunderstood and led to bad designs. For example, I used to have an old server with a third-party service that displayed some notifications/errors using a message box rather than writing to the event log. But I never logged on locally and rarely logged in in admin mode and hence I would not see the messages.

  • 2
    I have a feeling it had something to do with UAC - securing that means the UAC prompt couldn't share a workstation session with the interactive user, or a hacker could pop their own pretending to be the UAC prompt.
    – gbjbaanb
    Dec 28, 2012 at 13:21

Interactive services used to be possible, but the service model is that of a process that runs independently of any user. They are designed to be run unattended and therefore shouldn't need a GUI.

Interactive services haven't been available since Windows Vista so should no longer be used.

If you need to interact with the service the page I've linked to recommends creating a separate GUI application that communicates with the service through interprocess communication (IPC) of some sort - e.g. named pipes.


Because services are supposed to run in the background without interacting with the user; they may in fact run while no user is logged in.

  • then why this feature was there in earlier versions? Considering ur answer, there will be no communication between windows service and desktop application. So this answer could not be appropriate.
    – Arun
    Dec 28, 2012 at 10:48
  • 3
    @Arun - based upon that logic, then things that are broken would never be fixed. Michael's answer is correct - services shouldn't have guis. Just because earlier versions of windows had them (services with guis) doesn't mean that they should have had them.
    – user53019
    Dec 28, 2012 at 12:06
  • 8
    @Arun it is not true there is no communication between desktop apps and services, merely that the service itself does not have a GUI. Rather, a desktop app has the GUI and communicates with the server. Dec 28, 2012 at 12:22
  • So, windows services can have GUI but they shouldn have them?
    – Arun
    Dec 28, 2012 at 14:12
  • 2
    @Arun, services dont have GUIs themselves, but are often controlled by separate front end applications that can control the service by communicating with it in some manner (via named pipes, sockets,...) Dec 28, 2012 at 17:02

Yes it was possible and it worked. When you logged in you got the interface of the application. It was very useful for older applications which don't have a service available but still need to run on the server. Though it was not the most stable solution. It became running as the user which could click it away or logout. That was not very nice.

Now everybody develops native services and adds an application or log to manage the service. That's a good design pattern and is now being used most of the time.

So see it more as legacy that it was possible.


The services are meant for un attended operations , mainly in the background.The name service itself means act as a server for some client applications or other services which consumes this service. So MS might want now to stick to the basics and want to draw some clear distinction between services and Apps.So apps keeps the uses busy and let services serve their purpose silently. While nail cutter is there why go for kitchen knife to cut nils?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.