I'm attempting to use psexec to spawn a process on a remote machine (for automated testing purposes) and noticed that the spawned process wasn't correctly responding to a message (WM_GETOBJECT, but that's another question entirely). I opened spy++ in an attempt to see why, but I couldn't log any messages going to my process' window. The window properties also indicated that the "Windows Proc" for the window was "Unavailable":
.
I think this is a behavior of Windows services since psexec uses an embedded service on the remote machine to launch the requested application. I was logged onto both machines with the same credentials so I don't believe it is a user security issue but rather a service-related behavior.
As a sanity check I wrote a quick standalone server and client to execute a program remotely and everything worked as expected: the Window Proc was no longer "unavailable" and I could spy on messages.
I used the normal Windows Calculator (calc) for all my tests, i.e.:
psexec.exe -i \\other-machine calc
My question: Can someone confirm, explain, and/or cite why I can't see message queues of processes spawned off services? Also is there a workaround to this? I'd rather use psexec than my custom solution. Bonus if you can also explain why WM_GETOBJECT doesn't return my custom UI Automation provider in this situation as well, as that's my original problem.
Related
I'm trying to run external Application from service,
I've tried different solutions but nothing works so far.
ShellExecute I found out it cannot be used from a service
and WinExec
You can run applications from a service, but since Vista you won't see them at the users dektop.
Running the taskmanager will show that applications are started nevertheless.
MSDN Interactive Services
There are existing mechanisms to interact with the desktop yet, but that would be beyond the frame.
Launching an interactive process from Windows Service in Windows Vista and later
Services run in session 0, but that's a non-interactive session. So if the other process is interactive you need to make sure that it runs in an interactive session. That's quite trick to arrange, but not impossible. Details can be found here: http://blogs.msdn.com/b/winsdk/archive/2009/07/14/launching-an-interactive-process-from-windows-service-in-windows-vista-and-later.aspx
I built an application that is running as a windows service and is installed through my code.
All is fine except at logon.
When at the first windows xp/2003 server logon screen, I am not sure if the service is running at all. If it is, then it does work as it's not functional (the service IS USING WINPCAP so that could be an issue).
The service settings are set to "interact with desktop" and run as SYSTEM.
How can I ensure the service will start before windows logon? Also how can I make sure it is running even after I log off?
There are a couple of issues to consider.
First, you can check if your service really is running before login and after logout by logging events to the Windows Event Log. Pretty much all services do this whenever they start and stop and yours should do the same.
It may be that WinPcap is part of the problem. There are a couple of golden rules for using WinPcap in a service.
1a) Your service must not do anything that might cause the WinPcap service to try to start up while your own service is starting up because this will cause a deadlock in the Windows Service Control Manager. That means that if the WinPcap service is not already SERVICE_RUNNING when your service begins startup, you must not do anything that might cause it to start until after your service is SERVICE_RUNNING.
There are two ways to ensure this. Either make your service dependent on npf, the Network Packet Filter service. Or do not call any WinPcap function until after your service is SERVICE_RUNNING. I've not tried this latter method. I presume then the WinPcap function will block until npf is SERVICE_RUNNING.
1b) If you make your service dependent on npf, you will also have to make it dependent on nm (Network Monitor Driver) - if and only if nm is installed on the system. nm provides WinPcap with PPP/VPN support, and WinPcap always tries to use it if installed. Obviously, if you make nm a dependency of your service and nm isn't installed then your service will fail to start.
I don't think there is a guaranteed way to ensure that your service starts up before the desktop appears. But you might be able to help things along by creating a Service Control Group, adding it to the end of the existing list of Service Control Groups, and putting your service into this group. I'm not entirely convinced that this is an 'approved' way to get your service to start sooner, because if there was an approved way then everyone would do it and it wouldn't work any more. But there is a suggestion that services in a group are started before services not in a group.
Look at HKEY_LOCAL_MACHINE, "SYSTEM\CurrentControlSet\Control\GroupOrderList" and HKEY_LOCAL_MACHINE, "SYSTEM\CurrentControlSet\Control\ServiceGroupOrder" and do a bit of Googling.
I connect to a running node with the -remsh flag, and I run my usual Common Test sanity tests, but none of the error_logger:info_msg messages appear in the shell. Why?
The SASL default event handler will only write events to console/tty of the local node.
When connecting via "-remsh", you're starting a second node and communicating via
message passing to the first. The output from the "nodes()" BIF can confirm this.
Calls to the error_logger functions will send events to the local 'error_logger'
registered process, which is a gen_event server. You can manipulate it using
error_logger:tty/1 and error_logger:logfile/1, see the reference docs in the "Basic"
Application Group, then the "kernel" application, then the "error_logger" module.
You can also add your own event handler to the 'error_logger' server, which can then
do anything you want with the event. I'd guess that error_logger:logfile/1 might be
sufficient for your purposes, though.
-Scott
I am a seasoned Delphi developer and would like to create something like seamless terminal services where an application is executed on a server but appears on the the desktop of the client.
To someone working on the server I don't want them to see the remote application running (except if they looked in at the list of running processes).
I'm lost as to how to go about this, where to start, how to get an application to render to a surface other than the servers desktop.
Starting from 2008 Terminal Services (which has been rebranded to Remote Desktop Services) offers RemoteApps which do exactly what you describe. Citrix (XenApp) can do this on all windows (server) versions. So you might want to look at those products before deciding to recreate them yourself.
If you do decide to go on, this link might be interesting, it's a sample project called "Extending Microsoft's Terminal Services Client To Provide Seamless Windows"
From what you are describing, I'd say you should be looking at writing a windows service (not terminal services) and using a inter-process-communications (IPC) system to get status information to a "client" application that can be run by the appropriate user, either on the same machine or another over the network.
Myself, I do exactly this using the RemObjects SDK which makes my client application look like it is just making function calls, but actually they go to the server which implements them. The server can then get on with its job in one (or more) thread, and all the user interface is done in the client which finds out what to display using the IPC channel.
I understand that Window's Services have no desktop, and can't access any of the user's desktops directly (indeed, they can run when there is no desktop loaded). Why is it though that launching a form in a Window's Service causes an error?
A service should run without any user interaction, so there is no need for a form. If a service has to wait around for user feedback then it probably isn't going to be doing what it is supposed to.
You have to understand three related concepts: sessions, windows stations and desktops. But because there's a one-to-one relationships between sessions and stations, we can broadly ignore stations for this discussion. A session contains a station (winSta0 being the only interactive station) and stations contain one or more desktops.
Now session architecture differs according to Windows version. For NT <= 5 (XP/2003 and everything before them) services execute in session 0 along with the interactive user's apps. This is why you can configure services to interact with the desktop in these Windows NT versions - they are in the same session. For NT >= 6 (Vista, Server 2008 going forwards), services exists in session 0 but the interactive desktop is in another session. This is what's known as "service hardening", and is basically a security fix.
So since session 0 apps cannot get at the interactive console, it makes no sense for them to attempt to display a user interface of any kind.
Just to make this more confusing, Vista has a temporary kludge to cater for this situation: if an app in session 0 tries to create a dialog, Windows will trap this and present a warning to the user so they switch to a (I presume temporary) desktop where they can interact with the dialog. However this measure is explicitly temporary and you cannot rely upon it being in future Windows releases. I've seen this working in native code, but I suspect you are in managed code and the runtime is being smart enough to catch your behaviour and deliver a metaphorical slap to the hindquarters :-).
Ummm... what and whose desktop is that form going to appear on, exactly? A 'desktop' is an operating system concept: each window handle is owned by a specific desktop within a window station belonging to a single (interactive) user. The process within which the service is executing isn't going to find the user's visible desktop in its window station. For a rather dry reference, look at MSDN.
Actually, it's even nastier. You might be able to configure permissions for the service to be able to create a desktop -- but then nobody will see it! Alternatively, you could grant the process the rights to switch desktops, and confuse the heck out of the user!
There's a setting you must enable in order to allow your Windows Service to access certain folders directly (like desktop) or show forms (including MessageBox pop-ups): "Allow service to interact with desktop"
To see this, right click on My Computer => Manage => Services and Applications => Services. Double-click on a service to access its properties. On the "Log On" tab there is a checkbox for this setting.
Here is an article for how to set it programmatically in C#
[Edit] As Stephen Martin points out in the comments: this is only valid advice for pre-Vista versions of Windows.
Because if nobody is going to see the Form, nobody is going to dismiss it - running a modal dialog is a recipe for a hang - so you want it to complain loudly when this happens rather than sit there quietly until you kill the process (or look at a stack trace to determine what'd going on). (The other obvious problem is, who is going to pick the DialogResult if there is more than one possibility?) You want to know when this is happening. (Assert dialogs that dont throw if they cant show anything are a fun way of making people mad.).
In other words, because you want to know when things are confused enough in your code that a dialog is being shown within a service context.
(I'm assuming you're using Windows Forms on .NET, eve though you didnt tag it as such)
(If you have correctly configured things such that the service is allowed to interact with the desktop, you won't get an Exception)
When a Windows Service is started it is assigned to a Window Station and Desktop according to well documented, though somewhat obscure rules. As mentioned elsewhere it is not assigned to the interactive desktop (unless it is set to interact with the desktop on a pre-Vista OS) but it definitely runs in a desktop.
It is a common misconception that services cannot use UI elements. In fact many services (such as SQL Server) have in the past used hidden windows and windows messages for thread synchronization and work distribution purposes. There is no reason that a Form cannot be shown in a service. If you are getting an error it is due to something you are doing with the form or some component that is on the form. The most likely issues have to do with whether or not you need an STA thread for your form or are you creating a message pump for your form or something similar.
While you certainly can use a form in a Windows Service you almost certainly shouldn't. There will be threading issues, cross apartment call issues, possible blocking UI issues, etc. There are a very few situations where using a window in a service is a good choice but there is a better way, with no UI, in 99.99% of all cases.
Because at the time when the operating system needs to paint the window there is nothing to draw the form on.