none
"Allow Service to interact with desktop" does not work on Vista

    Question

  • Network Instruments is using extensively "Allow Service to interact with desktop" for the application configuration.

    The latest build of Vista (5744) still does not support "Allow Service to interact with desktop" feature.  I can see the service running and an application that it starts and tracks is also running (seen in the Task manager). 

    Not only that, when I configure the application - running as app - and then run it from the service, it functions and I can communicate with it.  However I can't see it on the desktop.

    Is there a fix on a way?  We NEED an option to allow Service to interact with desktop!!!

     

    Monday, November 06, 2006 10:13 PM

Answers

  • No you don't. Error messages of the service belong into the Application event log. Communication with an app in an interactive session should be done through normal IPC, i.e. sockets, pipes, COM, Remoting.

    As multiples sessions are running because of terminal services or remote desktop connections there is no one to one relationship between a service and an interactive window station with one desktop. You can have one per interactive session. Which one should the service talk to? What if nobody looks at any desktop of the machine your service runs on - nobody notices that messagebox or whatever UI stuff.

    Relying on that "feature" is just not adequate anymore. Get rid of it, there will be no alternative.

    --
    SvenC

    Tuesday, November 07, 2006 10:31 PM

All replies

  • I guess that is history. Make the session ID visible in Task Manager. You will notice that your services run in Session ID 0 and interactive processes are running in a Session ID > 0. I guess that different sessions are not (or cannot?) taken into account when trying to access a desktop. I guess the service tries to get access to desktop of session ID 0. You face a similar problem when using TermServ Client to access a server remotely.

    --
    SvenC

    Monday, November 06, 2006 10:43 PM
  • I run into the the same problem.

    Yes, we NEED an option to allow Service to interact with desktop!!!

     

    Tuesday, November 07, 2006 10:13 PM
  • No you don't. Error messages of the service belong into the Application event log. Communication with an app in an interactive session should be done through normal IPC, i.e. sockets, pipes, COM, Remoting.

    As multiples sessions are running because of terminal services or remote desktop connections there is no one to one relationship between a service and an interactive window station with one desktop. You can have one per interactive session. Which one should the service talk to? What if nobody looks at any desktop of the machine your service runs on - nobody notices that messagebox or whatever UI stuff.

    Relying on that "feature" is just not adequate anymore. Get rid of it, there will be no alternative.

    --
    SvenC

    Tuesday, November 07, 2006 10:31 PM
  • There is at least one case where a windows service needs to be sensitive to messages from a windows message pump. Time change. The fixes for this are ugly at best and the windows development team needs to provide workable alternatives before this feature goes  away.
    Monday, November 20, 2006 7:28 PM
  •  SvenC wrote:
    No you don't. Error messages of the service belong into the Application event log. Communication with an app in an interactive session should be done through normal IPC, i.e. sockets, pipes, COM, Remoting.
    Actually do.I'll give a real life example:Let's say you have Apache server (running as service under Local service account). And now suppose you have running Perl script debugger!?And now what? When you are running script through web browser Debugger will try CreateWindow (GUI) and to debug line by line Perl script. If you don't have capability to "Allow Service to interact with desktop" then your debugger will never quit... Cheers!
    Tuesday, February 27, 2007 3:32 PM
  • Why should this case be special? Let the debugger and Apache (or the Perl module) communicate with some standard IPC. The service should just provide the information and commands for the debugger, which then uses that information to visualize them and calls commands to control the debug session. How else would you be able to do remote debugging.

     

    --

    SvenC

    Thursday, April 05, 2007 5:18 AM
  • Just a thought on this: Is there any way to show the Services desktop?

    I've seen it before after VNC Server tried to raise a dialog on startup and Vista asked me if I wanted to see it. I said yes and I saw the VNC dialog by itself on a grey desktop with nothing else on it.

    Makes me wonder is there a way to ask to see this desktop on demand? Maybe we need a small applet that can reveal/hide it - seems like it would bridge the gap until apps are re-written to handle this new limitation...
    Sunday, April 08, 2007 12:52 PM
  • If a service is requesting input then Vista will give you the opportunity to temporarily switch to the interactive services desktop as shown in this Channel 9 screencast.
    Sunday, April 08, 2007 1:18 PM
  • I am not sure why a feature that has always been present and useful is now deemed "you don't need to do that", of course we can always program around problems, but when debugging a service having a console window to display trace information is a lot easier than building a client-server application to do such a simple thing.

     

    The new security in Vista is causing a major headache to both users and developers. Much as the improved security is welcome in some instances it would be nice to be able to just turn it off at times so we can debug our applications. Instead we have to develop on XP and then port to Vista. I can't even register a service without problems!

    Wednesday, December 05, 2007 5:52 PM
  •  SvenC wrote:
    No you don't.

     

    What an arrogant and insulting statement, to say that this feature of XP could not possibly be the ideal choice for a developer ever is insanity. Someone tell Sven here to take the blinders off.

     

    My situation is fairly simple, and I'm attempting to use all MS products here, nothing hokey. I am an SDET for a user experience company. We are contracted to develop user interfaces. It's what we do. These interfaces need to be tested efficiently and on multiple platforms. I currently use Visual Studio test projects to organize and execute automated tests.

     

    To execute these tests on different machines, I would like to utilize Visual Studio 2008's Test Controller and Test Agent modules. The test agent runs as a Windows service. The tests operate out-of-process so as not to interfere with the codepath, and use Process.Start() to invoke the application being tested.

     

    Naturally, when executing over a test agent this doesn't really work in Vista. I guess I could write my own ramshackle controller and agent applications over a week or so, but I'd really rather not.

     

    Ignoring Sven's depressing ignorance, I know Microsoft has an internal application that acts as a test agent and controller that DOES work properly, in spite of being on Vista and running as a service. So there IS a way to pull this off. Can anyone shed some light on it?

     

    Thanks,

     

    Evan

    Monday, March 17, 2008 11:26 PM
  • In released code, services interacting with the desktop is dangerous.  That's why people are saying 'don't do it' in so many different ways, so strongly.  Session 0 isolation is goodness, and UI from services doesn't have a place in consumer products. Read about the Shatter Attack for some hint as to why session 0 isolation came about.

     

    As for how to debug a service without UI?  Services hanging around in different sessions hasn't bothered me.  I debug services frequently attaching to the process, specifying its PID, something many debuggers can do.

     

    If you want to know how to set up Visual Studio 2008's Test Controller and Test Agent stuff so that it works, try the Visual Studio forums for a much faster, and much more helpful response.

     

    If you want to write a (sane) service that is capable of launching stuff on a visible desktop, there are good ways and bad ways of getting it done.


    You should start by reading articles on RpcImpersonateClient, CreateProcessAsUser on MSDN.
    There are a number of threads in these forums touching on 'createprocessasuser from service' and so forth, which might help.


    Note, though, exposing a method to an RPC client that is effectively 'launch any application with admin privileges' is a very scary prospect since you can never trust a client at lower privilege.

    Tuesday, March 18, 2008 2:59 AM
  •  

    "services interacting with the desktop is dangerous" - Justify this, where's your evidence?  We implement a graphical rendering service that has to always be available to other processes, this approach places the difficult code outside the 'high availablity' GUI (that cannot go down, ever) and into the body of a service, thus when it faults, it crash dumps then the SCM restarts it immediately allowing the rendering outage to be momentary and the impact to the users minimal as the primary application didn't fail.  With the recent changes to Vista, we now basically have to write our own implementation of the SCM as we're still proceeding with process separation but can no longer make good use of the SCM.

     

     

    Wednesday, August 06, 2008 2:58 PM
  •  

    Services with UI are vulnerable to privilege escalation attacks via the so-called Shatter Attack. You shouldn't need to re-write the SCM, using IPC to communicate between a standard windows service and a helper application running in the user's context which actually displays any UI should suffice.
    Wednesday, August 06, 2008 3:04 PM
  • Sven, you are a fool.  It is not for you to determine what someone's application needs are.  It's not great that MS dictates when and how everyone should rewrite their applications.  Whether or not it's a good idea to interact with desktop is subjective, but I'm not sure you've read the requirements or seen the interface for the application that oilyneck already has written.

    Apparently you don't face the same kind of time & resource constraints as the rest of us down here on earth.
    Thursday, November 05, 2009 11:50 PM
  • Hello.

    I need the same functionality to work. I'm having a web script from which i need to run a desktop app. This is only for my personal use, on my private PC, not public, so there are no security risks involved. I've kept reading about how to get this to work, but no solution. I've checked "Allow service to interact with desktop" on my services "Log on" properties, but it doesn't make any difference. Not only that i don't see why the checkbox is there if it doesn't work, i'm wondering how someone like sven can stop me from deciding what programs to allow or disallow to run on my computer. But still, if this doesn't work, is there any workaround this issue? Can anyone help about how to launch an external app from my web service?

    Monday, March 29, 2010 11:38 AM
  • The take away from all of this is that all of you... and I mean all... that claim to NEED service/desktop interaction are not experienced developers.  I don't care how long you've written code - you obviously still have the skill set of a recent college grad.

    Aluciffer - if you knew anything (AT ALL) about security you would never make this claim "This is only for my personal use, on my private PC, not public, so there are no security risks involved."  You obviously haven't reverse engineered malware before or have the breadth of knowledge on the topic.

    I'm not here to teach so just take the direction that Microsoft is providing.  Take this opportunity to grow your design skills and knowledge about the platform you're developing on.  Develop code that works *with* the OS and not against it; that's the second half of being a good developer.  The first obviously is creating clean maintainable source.

     

    Sunday, April 11, 2010 7:29 PM
  • Experience has nothing to do with this issue.  Many services must interact with users because it's the only option that makes sense to the user.  Disagree?  The print spooler service was written by none other than Microsoft.  If you hold firm to the opinion that no service should ever interact with the desktop, then you are calling Microsoft and the printer mfrs that write spooler components "inexperienced".  If these developers were more "experienced", would print spooler developers do all user interaction through the event log?

    Launch services.msc, and a quick glance will show you numerous other services that must interact with desktops.  Windows Update is one example.

    Microsoft's solution to shatter attacks is worse than the original problem.  Instead of fixing the "shatter attack" vulnerability head-on, MS decided to pull functionality out of Windows.  Microsoft's response to shatter attacks is equivalent to amputating a foot to fix a broken toe.

    The individuals that posted suggestions regarding the use of RPC are a bit closer to reality on the ground than Stratcat's comment.  However, the logistics of this RPC topography are unpleasant.  Just one example of the logistical challenges:  the RPC solution requires applications to 'auto-start' on each desktop when the user logs in.  This is easily changed by any user with the proper privileges.  In my target market, that's just about every user.  Startup folders, the Run registry key, and the task scheduler are well known to users because they turn a 2 minute bootup into 3 minutes of waiting for things not yet in use!

    Fix "shatter" and give us back desktop interaction, please!  I don't care if the process has to run as guest and can't send messages to other applications.

     

    Tuesday, June 01, 2010 10:35 PM
  • Sorry, for sounding arrogant. I use another liveID and could not reuse SvenC. Maybe I should have started with "No, you don't ;-)"

    Experience has nothing to do with this issue.  Many services must interact with users because it's the only option that makes sense to the user.  Disagree?  The print spooler service was written by none other than Microsoft.  If you hold firm to the opinion that no service should ever interact with the desktop, then you are calling Microsoft and the printer mfrs that write spooler components "inexperienced".  If these developers were more "experienced", would print spooler developers do all user interaction through the event log?

    There is no one to one relationship from one service to one user desktop. It started with terminal services on Windows Server and got to the Windows Client with Fast User Switching and remote desktop connections: Multiple users can log on to one Windows machine, each has a different logon session, a different windowstation and a different visible desktop. So which desktop should your service showwindows or message boxes on? Should it multiplex? And if two users click "Yes" and three click "No" how does that count?

    Even without session 0 isolation services could only communicate with a user logged on to session 0. So when an admin used remote desktop to log on to a server he would only see those Service messages if he used mstsc /console which only one admin at a time could do. So guess how good this would work if two of those services must be administrated on one server by two different admin persons. They could not do their job in parallel.

    The event log was only mentioned as the preferred way to be used instead of a console window to put status and error messages on, besides using a simple log file.

    Launch services.msc, and a quick glance will show you numerous other services that must interact with desktops.  Windows Update is one example.

    I doubt that any Windows service from Microsoft uses this option any more. I checked Windows Update (on Windows 7) and it doesn't.

    And I doubt that session 0 isolation will go away. So I doubt that this "limitation" will go away.

    IPC got really simple. With sockets and named pipes you had to implement quite some infrastructure to exchange commands and state. With COM it got easier and with .Net and WCF it has become really easy. Integrating into MMC is also nice with .Net. Just give it a try and you will never miss that "interact with desktop" thing a second anymore.

    Saturday, June 05, 2010 6:16 PM
  • Yup. I have a reason. I want to use OpenCL, on a GPU, on a server. Without a user logged into the desktop. Yup, there you go. Valid reason. Took 5 years.
    Friday, July 01, 2011 5:35 AM
  • Yup. I have a reason. I want to use OpenCL, on a GPU, on a server. Without a user logged into the desktop. Yup, there you go. Valid reason. Took 5 years.


    Hi Jerome,

    are you sure that you need to interact with the session 0 desktop or window station to use OpenCL?

    --
    SvenC

    Friday, July 01, 2011 5:47 AM
  • Hi everybody.

    I individually use WCF to comunicate user UI with Service and it is really simple,

    somehow you can use this solution to make service UI visible outside of Session Id 0.

    the solution is very simple,

    you can use remoting by psexec.exe

    add this code to your service and add psexec.exe to your installed folder:

    shell("PsExec.exe \\127.0.0.1 -s -i -d UI.exe")

    if you directly call UI.exe (like this: Shell("UI.exe")) from your service, it will be invisible in user's desktop, but if use this: shell("PsExec.exe \\127.0.0.1 -s -i -d UI.exe") UI.exe will be visible on user's desktops, and the most important thing is, it will be shown on all of active user's desktops.

    Download PsExec.exe from here.

    have FUN.



    Monday, October 03, 2011 11:23 PM
  • Hi Abdollah,

     

    Your approach is very helpful, but when I tried it on Win 7:

    shell("PsExec.exe \\127.0.0.1 -s -i -d UI.exe")


    Task Manager still shows UI.exe running with session ID 0, so Interactive Service Detection is still showing the warning message.

    What am I doing wrong?

    Thanks,

    Philip

     

    Thursday, October 13, 2011 4:28 PM
  • Nothing. It's a cheap bodge "solution" that can fail for all the reasons that opening UI from a service on XP can fail for. And a whole bunch of new reasons to.

    It's honestly so much easier to just do it properly in the first place that trying to force half-baked solutions to work is inevitably going to cause you more headaches than just doing it right. And it'll fail a lot less that way to.

    Wednesday, October 19, 2011 12:11 AM
  • This Session 0 isolation is a good thing, hopefully it will stop a tiny percentage of the issues caused by malicious privellage escalation. The rest will of course be modified to get around the restriction one way or another. However I can see it breaking a large number of applications that cannot for many reasons be redeveloped to work with the new isolation feature. Microsoft has once again shot many of its users in the back in an attempt to make the OS more secure.


    We have an OPC Client application that uses DCOM to pull data from a user application running on the console sesion on a remote system via an OPC server, however when the OPC Client attempts to connect to the remote OPC Server that remote system launches the OPC Server as a service which cannot communicate to our application as the service is running in Sesison 0 and the application is running in Session 1.

     

    How do I make an application that has not been developed to work in different sessions work with the isolation feature........ Ideally an Opt Out feature would be perfect with a clause that it voids support for the OS or whatever.

     

    As for Security concerns this particular system is running in a DoD site which limits access to the machines by not networking it to anything other than the 2 servers via a single cat5 cable, disabling all data transfer methods (USB, CD etc) & only allowing access after going through the security office and accessing it locally. So turning this session isolation off wouldn't turn any heads as their running on Windows 95 and Dos at the moment ;)

     

    Any help would be appreciated as at the moment im trying to make the Service start in Session 1 which hasn't been very successful as of yet.

     

    Hopefully I haven't Hijacked the thread.


    • Edited by IanWhat Thursday, October 27, 2011 6:40 PM
    Thursday, October 27, 2011 6:38 PM
  • Me as well; there are more and more distributed rendering packages that need access to the GPU to do high speed computation for rendering in theatrical film, and this is not allowed from a regular service. (Various graphics errors occur).

    These apps don't necessarily use openCL, but perhaps other techniques for interacting with the GPU that works fine from a regular DOS window/login, but not from a service.

    Distributed computing programs run as a service to manage these 3rd party applications, which inherit their environments from the service that invokes them, and it's important these apps run with access to the window manager, and run as a configurable user (not the LocalSystem account).

    All this not so much to open any GUIs for user internaction, but solely to interact with the GPU.

    Configuring these machines auto-login and auto-start these services in a DOS window instead has been the only workaround that works reliably, but this is bad because entire farms of machines have to be configured to do this, and forces farm management to have all machines auto-login as a specific user, when it shouldn't matter who's logged in, or if anyone is logged in. Esp. on workstations where programs need to run in the background, while users login/out without affecting these background processes.

    Thursday, December 22, 2011 7:42 PM
  • Have the installer create a user (or allow the installing user to specify an account) and then have your service create a child process, logged in as that user, with CreateProcessWithLogonW. Run your GPU code as part of that child process, using IPC to communicate with the main service as required.
    Saturday, December 31, 2011 1:58 AM
  • What an arrogant and insulting statement, to say that this feature of XP could not possibly be the ideal choice for a developer ever is insanity. Someone tell Sven here to take the blinders off


    It is also possible that XP introduced a massive security hole by allowing such a thing. The problem would then be that XP has developed into such a massive development ecosystem that removing such a "flexibility" causes pain such as yours while the "Vista workarounds" start to develop.

    TBH, if it is a massive security hole, I'd much prefer the "short term pain" of having to retool and move forward with a more secure platform. The reality is security in the Windows ecosystem has always taken a back seat. Things like UAC really should have been part of Windows from day dot (Unix had the concept of super user and it allows separation of system administration config vs day to day user tasks).

    Wednesday, August 21, 2013 12:35 AM
  • Excellent post David. Thanks.
    Wednesday, August 21, 2013 12:36 AM