Each service has an associated window station and desktop. Only one window station, Winsta0 can be an interactive. Any desktops created on the interactive window station can display objects to the user and receive user input. Other desktops cannot display objects or receive user input. Processes started by the logged-on user are associated with the default desktop in the Winsta0 window station (Winsta0\default).
The particular window station and desktop combination used by a service is determined by the account in which the service is running. If the service is running in the security context of the LocalSystem account and does not include the SERVICE_INTERACTIVE_PROCESS attribute, it uses the following window station and desktop: Service-0x0-3e7$\default. This window station is not interactive, so the service cannot display a user interface. In addition, processes created by the service cannot display a user interface.
If the service is running in the security context of a user account, the name of the window station is based on the user SID: Service-0xZ1-Z2$, where Z1 is the high part of the logon SID and Z2 is the low part of the logon SID. Because a SID is unique to the logon session, two services running in the same security context receive unique window stations.
If the service is running in the context of the LocalSystem account and has the SERVICE_INTERACTIVE_PROCESS attribute, it is known as an interactive service. It can display a user interface and receive user input. Refer to the Security Considerations for Interactive Services section below for important information on how to ensure that your interactive service sessions are secure.
To determine whether a service is running as an interactive service, call the GetProcessWindowStation function to retrieve a
handle to the window station, and the GetUserObjectInformation function to test whether the window station has the WSF_VISIBLE attribute.
However, note that the following registry key contains a value, NoInteractiveServices, that controls the effect of SERVICE_INTERACTIVE_PROCESS:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Windows
The NoInteractiveServices value defaults to zero, which means that services with SERVICE_INTERACTIVE_PROCESS are allowed to run interactively. When NoInteractiveServices is set to a nonzero value, no service started thereafter is allowed to run interactively, regardless of whether it has SERVICE_INTERACTIVE_PROCESS.
Security Considerations for Interactive Services
Note that running interactive services under the LocalSystem context is a dangerous practice and should be avoided. If a service that is running on a multiuser system must interact with a user, the service should do so through a separate
GUI application running within the context of the user session. This
GUI application should be designed to communicate with the service through some method of interprocess communication, such as a named pipe. This is a client/server implementation.
The server process (the interactive service) then communicates with the appropriate client through interprocess communication to tell the client when to display the
GUI. The client then communicates the results of the user interaction back to the service so that the service can take the appropriate actions. By using named pipes, the server can distinguish between multiple user processes by giving each pipe a unique name.
Interacting with the User from a Noninteractive Service
It is possible to display a message box from a service, even if it is not running in the LocalSystem account or not configured to run interactively. Simply call the MessageBox function using MB_SERVICE_NOTIFICATION. Do not call MessageBox during service initialization or from the HandlerEx routine, unless you call it from a separate thread, so that you return to the SCM in a timely manner.
It is also possible to interact with the desktop from a non-interactive service by modifying the DACLs on the window station and desktop, or by impersonating the logged-on user and opening the interactive window station and desktop directly. This allows services to provide a user interface, while maintaining the security of applications running in the account of the logged-on user. For more information, see Interacting with the User in a Service.