"Allow Service to interact with desktop" does not work on Vista
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!!!
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
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.
--
SvenCI run into the the same problem.
Yes, we NEED an option to allow Service to interact with desktop!!!
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- 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.
- 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!
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. 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
- 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... - 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.
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!
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
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.
"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.
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.- 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.
