The 'Interact With Desktop' setting was restricted starting in Windows Vista. Interactive services are susceptible to a so-called 'shatter' attack, where a high-privileged process doesn't properly validate the parameters of a window message sent to it by a lower-privileged process running on the same desktop. That can lead to a security vulnerability. As a defence-in-depth measure, Microsoft changed the console session from being session 0, as in previous versions of Windows, to session 1. Interactive services still run on session 0 and can create UI, or run other programs that show UI, but the user can't see them and they can't receive malicious messages from other processes.
For compatibility, Windows includes the Interactive Service Detection service (Ui0detect). If an interactive service creates a new window, this generates a prompt telling the user that it's trying to show a message and requesting that they switch to session 0 to see it.
However, on Windows 8 this service is now set to manual start, and it won't start (reporting error 1, Incorrect function) if the NoInteractiveServices
registry value is set to 1, which it is by default. This value is under HKLM\SYSTEM\CurrentControlSet\Control\Windows
. (source)
I strongly advise not doing this. Interactive services must run under the LocalSystem security context, which is highly privileged. It's unlikely that your code actually needs those privileges. Instead, write the UI as a low-privileged process that gets launched from the user's Startup program group or one of the various Run registry keys, and connects to the web application, polling for a signal to launch the process that you need to be launched. You could use SignalR to notify the launcher that it's time to launch the application.
Reference: Session 0 Isolation for Services and Drivers