I have a C++ Win32 application that was written as a Windows GUI project, and now I'm trying to figure out to make it into a Service / GUI hybrid. I understand that a Windows Service cannot / should not have a user interface. But allow me to explain what I have so far and what I'm shooting for.
WHAT I HAVE NOW is a windows application. When it is run it places an icon in the system tray that you can double-click on to open up the GUI. The purpose of this application is to process files located in a specified directory on a nightly schedule. The GUI consists of the following:
A button to start an unscheduled scan/process manually.
A button to open a dialog for modifying settings.
A List Box for displaying status messages sent from the processing thread.
A custom drawn window for displaying image data (the file processing includes the creation and saving of images).
A status bar - while a process is not running, it shows a countdown to the next scheduled scan. During a scan it also provides some status feedback, including a progress bar.
WHAT I'M SHOOTING FOR is a service that will run on boot-up and not require a user to login. This would consist of the scheduled file processing. However, when a user logs in I would still like the tray icon to be loaded and allow them to open up a GUI as I described above to monitor the current state of the service, change settings, start a scan manually, and monitor the progress of a scan.
I'm sure that I have seen applications like this - that function as a service even when I'm not logged in, but still give me a user interface to work with once I do log in.
I'm thinking that instead of having a single multi-threaded application that sends messages to the GUI thread from the processing thread, I need two applications - a Service to perform the processing and a GUI application to provide visual feedback from the Service and also send messages to the Service (for example, to start a scan manually). But I am new to Windows Services and have no idea how this is done.
It is also possible that I'm completely off base and a Service is not what I'm looking for at all.
Any help / ideas / suggestions would be greatly appreciated! Thank you.
You can't do this as a service.
You'll need to make your Windows Service as a normal service application. This will startup on system startup, and run the entire time the system is up.
You'd then make a completely separate GUI application, which "talks" to the service. This can be set to run when a user logs in, in the user's account.
In order to make them "talk" to each other, you'll need to use some form of IPC. Since these run on the same system (but in different accounts, typically), named pipes or sockets both work quite well.
There is a simple way of doing it.
You can’t have the service access any user’s session (session 1,2,3..) since services are isolated and can access session 0 only. This is a change from 2011.
You should write a win32 program to be launched by your service per each user who logs in using https://msdn.microsoft.com/en-us/library/windows/desktop/ms682429(v=vs.85).aspx
The service can continue performing any task that isn’t user specific.
Related
In a command line application which is single threaded, I want to know when user closes (by clicking on red cross on top right) shutdowns PC or Logoff without logging out of my application first, so that I can clear the cookies that I am storing in window's registry.
Is there any way I can know when user has done the events mentioned above and call a function within my application or call a separate EXE or a Batch file following the event ?
I need this functionality because I want to prevent a possible scenario where in Registry is full of unwanted thrash created by not logging out of application properly.
Since my application runs over command prompt likeC:\Users\admin\Desktop>Application.exe -task "ConnectServer" --ip 127.0.0.1 I am looking out for some way to either manage cookies in efficient way or to delete the cookies after catching the events mentioned above.
You could use SetConsoleCtrlHandler()
So I wanted to create a windows service that runs a few commands in a batch file.
However, while I assume I can redirect stdout from the subprocess and read out an error message, I can't seem to find out how I would get that to display to the screen.
when starting a windows service, it gives errors when the service fails to start, so ideally I would like to just use the interface that pops up the other service errors rather than popping up some window of my own or writing a log file.
I used this to get started but it doesn't seem to have anything on error processing.
http://www.codeproject.com/Articles/499465/Simple-Windows-Service-in-Cplusplus
He just outputs to a debugger. I can definitely do that, but ideally the person starting the service would want to know if there was an error starting.
Yes, you can redirect the STDOUT of the spawned process. MSDN has an article on that topic:
Creating a Child Process with Redirected Input and Output
You can use ReportEvent(), EventWrite(), or TraceEvent() to write log messages to the System Event Log (which is located within Windows' Control Panel), depending on which logging API you decide to use. Refer to MSDN for more details:
Event Logging
Windows Event Log
A service is a background task, it should not display its own UIs. Use the system Event Viewer to view log messages. The popup the user sees if the service fails to start is not displayed by the service itself, but by the Service Control Manager.
Starting with Windows Vista, services do not run in the same desktop session as logged in users (Session 0 Isolation), so they cannot display their own UI anymore. If your service must display a popup message, it can use WTSSendMessage() for that. For more complex UIs, it is best to implement that as a separate non-service GUI app that runs in the user's session, and then the service can launch/communicate with that app as needed.
I want to make a tool that runs on win32 to monitor our online game servers. The servers actually are .exe files. I need to know whether they have crashed so I can restart them. Therefore, the tool will have 2 main features:
Frequently check a list of the server programs to see whether they are running or not
Reopen the executable of any server that has crashed
Does anyone have any idea or knows an API to start with?
If you're in Win32, you can start out with C# using System.Diagnostics
using System.Diagnostics;
Then get a process list:
Process[] processlist = Process.GetProcesses();
foreach(Process theprocess in processlist){
Console.WriteLine(“Process: {0} ID: {1}”, theprocess.ProcessName, theprocess.Id);
}
And from there it's up to you what you want to do with the info.
Game servers should produce logs. You should make a service / cron job to monitor the logs. Depends on the contents of logs, your service should act respective actions, e.g. restart service, trigger alarms, etc.
I realize that this is not exactly what you asked for, but what about doing the monitoring with a fully-fledged monitoring tool such as Nagios? You would of course have to "teach" the monitoring tool about the processes that shall be monitored but you would also profit from its more advanced functions. In the case of Nagios, for example, these would comprise automatic e-mail notifications, an online dashboard of process status, notifications via SMS etc.
You should start the game servers using CreateProcess or similar in the win32 api.
You will get back a process handle in the lpProcessInformation parameter.
You can use WaitForSingleObject to WaitForMultipleObjects to wait until that handle is notified which will happen when the process terminates for any reason.
I need a certain process to be constantly running in every user’s computer. If that .exe is killed, I must be able to restart it and send an alert.
I immediately thought of building a Windows Service as the ideal solution, but I am facing a problem:
The process started by that service needs to be able to interact with the user, e.g. be able to show him a GUI.
my application also sets a keyboard hook in order to monitor the user's typing rhythms, and when I start the .exe from a service, that information is not accessible.
From the service I am able to launch the process "as the user" (using the LogonUser and CreateProcessAsUser functions), but still can’t see the GUI.
Is this possible? If not, what can I use to achieve the desired functionality?
tia
By default the GUI .exe will be run in the service session, which is separate from the interactive session of the user. You need to look into techniques for building an interactive service.
I have written a Windows service that allows me to remotely run and stop applications. These applications are run using CreateProcess, and this works for me because most of them only perform backend processing. Recently, I need to run applications that present GUI to the current log in user. How do I code in C++ to allow my service to locate the currently active desktop and run the GUI on it?
Roger Lipscombe's answer, to use WTSEnumerateSessions to find the right desktop, then CreateProcessAsUser to start the application on that desktop (you pass it the handle of the desktop as part of the STARTUPINFO structure) is correct.
However, I would strongly recommend against doing this. In some environments, such as Terminal Server hosts with many active users, determining which desktop is the 'active' one isn't easy, and may not even be possible.
But most importantly, if an application will suddenly appear on a user's desktop, this may very well occur at a bad time (either because the user simply isn't expecting it, or because you're trying to launch the app when the session isn't quite initialized yet, in the process of shutting down, or whatever).
A more conventional approach would be to put a shortcut to a small client app for your service in the global startup group. This app will then launch along with every user session, and can be used start other apps (if so desired) without any juggling of user credentials, sessions and/or desktops.
Also, this shortcut can be moved/disabled by administrators as desired, which will make deployment of your application much easier, since it doesn't deviate from the standards used by other Windows apps...
The short answer is "You don't", as opening a GUI program running under another user context is a security vulnerability commonly known as a Shatter Attack.
Take a look at this MSDN article: Interactive Services. It gives some options for a service to interact with a user.
In short you have these options:
Display a dialog box in the user's session using the WTSSendMessage function.
Create a separate hidden GUI application and use the CreateProcessAsUser function to run the application within the context of the interactive user. Design the GUI application to communicate with the service through some method of interprocess communication (IPC), for example, named pipes. The service communicates with the GUI application to tell it when to display the GUI. The application communicates the results of the user interaction back to the service so that the service can take the appropriate action. Note that IPC can expose your service interfaces over the network unless you use an appropriate access control list (ACL).
If this service runs on a multiuser system, add the application to the following key so that it is run in each session: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. If the application uses named pipes for IPC, the server can distinguish between multiple user processes by giving each pipe a unique name based on the session ID.
WTSEnumerateSessions and CreateProcessAsUser.
Several people suggested WTSEnumerateSessions and CreateProcessAsUser. I wonder why no one suggested WTSGetActiveConsoleSessionId, since you said you only want to target one logged in user.
Several people sure are right to suggest CreateProcessAsUser though. If you call plain old CreateProcess the way you said, then the application's GUI will run with your service's privileges instead of the user's privileges.
That problems Session 0 , Interactive Services ,
Windows Service Allow Service To Interact With Desktop
on Windows 7 or Windows Vista
You can read this article
http://www.codeproject.com/KB/vista-security/SubvertingVistaUAC.aspx
I try explained here it's working on Windows 7
On Win2K, XP and Win2K3 the console user is logged on in Session 0, the same session the services live in. If a service is configured as interactive, it'll be able to show the UI on the user's desktop.
However, on Vista, no user can be logged on in Session 0. Showing UI from a service there is a bit trickier. You need to enumerate the active sessions using WTSEnumerateSessions API, find the console session and create the process as that user. Of course, you need also a token or user credentials to be able to do that. You can read more details about this process here.
I think as long as you have only one user logged in, it will automatically display on that user's desktop.
Anyway, be very careful when having a service start an exe.
If the write access to the folder with the exe is not restricted, any user can replace that exe with any other program, which will then be run with sytem rights. Take for example cmd.exe (available on all windows sytems). The next time the service tries to start your exe, you get a command shell with system rights...
If you launch a GUI from your service it will show up on the currently active desktop.
But only if you adjusted the service permissions: You need to allow it to interact with the desktop.
Important Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code.
This is taken from : http://msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx