Are Windows-GUI calls (creating visible windows, e

Question

First off, I know some proper ways of making a truly interactive Windows Service.

The situation is, I do have a tool that does not interact with the user as such. However, it does display non-blocking notifications both via popup windows and via the Windows Notification Area (aka System Tray). It also writes a logfile of the notifications it displays.

This tool is normally spawned by a main user application and as long as the main application is a normal application, these notifications do work as intended.

When this tool is spawned by a Windows Service, no notifications are displayed, naturally. (The Desktop Session for the service isn't visible.) But this would be OK, we have the logfile and these notifications are just - notifications, nothing the user absolutely must see under all circumstances.

The question now becomes: Is a process running in the context of a Service (the Service itself or any process it starts) "allowed" to make Windows API calls that display a visible GUI?

• Will most Windows API calls (e.g. creating and showing a window, using Shell_NotifyIcon, etc.) behave the same in the invisible session of the service?
• Or would I have to make sure throughout the source code, that no GUI displaying/modifying stuff is called in the context of the service?

And yes, calling ::MessageBox is a bad idea because it will block. But I can handle these calls.

And yes, this could be designed better, but it's what I have at the moment and it would be nice if I hadn't to rip the whole tool apart to make sure no GUI related code is run in the service.

Answer 1

GUI elements from a Windows Service are shown on Session 0. On Windows XP & 2003, users were allowed to log in to Session 0 and interact normally with the windows created by a service, but Microsoft put a knife in the heart of interactive services in Vista (and beyond) by isolating Session 0.

So, to answer your specific questions:

Is a process running in the context of a Service (the Service itself or any process it starts) "allowed" to make Windows API calls that display a visible GUI? Will most Windows API calls (e.g. creating and showing a window, using Shell_NotifyIcon, etc.) behave the same in the invisible session of the service?

Yes, GUI calls are allowed and should succeed as normal. The only notable exceptions that I know of are those related to tray icons because the process providing the task bar (explorer.exe) is not running in the isolated Session 0.

Or would I have to make sure throughout the source code, that no GUI displaying/modifying stuff is called in the context of the service?

That should not be necessary, though you should proceed cautiously with any GUI interaction from your service. Test thoroughly!

Answer 2

I would like to provide some info wrt. Raymonds Chen's comment to the other answer

You should avoid presenting UI in a service because you may trigger the UI Detection Service which will switch the user to your service UI temporarily. – Raymond Chen

I find these good articles:

• What is Interactive Services Detection and Why is it Blinking at Me?
• Inside Session 0 Isolation and the UI Detection Service, Part1, Part2

Where one can find explanation on what the UI detection service (UI0Detect) is and does and how it's supposed to work.

Interactive Services Detection (the blinking button on the taskbar) is a mitigation for legacy applications that detects if a service is trying to interact with the desktop. This is handled by the Interactive Services Detection (UI0Detect) service.

However, one must note that this only can work if the service that is trying to view a GUI has the flag "Allow service to interact with desktop" set, because only then the service process will be running on WinSta0of Session0 even allowing it to show anything at all.

Alex Ionescu mentions this:

If UI0Detect.exe ... the SCM has started it at the request of the Window Hook DLL. The service will proceed ... The service first does some validation to make sure it’s running on the correct WinSta0\Default windowstation and desktop and then notifies the SCM of success or failure.

So, to come back to Raymond's comment: As far as I can see, as long as a service doesn't tick the type= interact option (see sc.exe), and normally you don't tick this, the UI0Detect service doesn't do anything and there shouldn't be any "danger" of triggering it.

---

Note: The information above is based on my limited research and tests on only a single Windows 7 PC.