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.
Related
I need to write a C++ application that should read firewall status of Windows, and then need to keep an eye continuously if admin/someuser
changes the firewall status (lets say when my program was started firewall was disabled and after sometime Admin enabled it).
To implement this, I have created a thread that periodically(10 seconds) poll the code that checks Windows firewall status, but this doesn't look an efficient solution to me as continuous polling is required.
Is there a way to get event automatically in my program if firewall status changes (for example, FindFirstChangeNotification, using this I can get notification if any change in directory)? This will avoid continuous polling and will make program more efficient I think.
Any help is appreciated.
I know there is Windows ETW which anti-viruses use and which has all the info you need. It is a big system log where you subscribe to log/event providers. Pretty much everything that happens in system gets reported there via event which you can listen/wait for. I don't know the links to more useful pages with a list of loggers connected to ETW so here is the more general page: https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/event-tracing-for-windows--etw-. You need to find out how to use C++ ETW API and the name/ID of the firewall events provider with a list of event types, then using API subscribe to this provider and setup a callback for when an event that interests you (here change of firewall status) occurs and that is it.
Is there some way to launch a process in non-elevated way from an elevated one. My setup is launched elevated and when it finalizes, it will just launch the main application. Because the setup is elevated, the main process will be elevated as well which is not desirable. What is the best solution to this?
That's a problem, Vista/Win7 don't appear to have an API to obtain the unprivileged user token you need to call CreateProcessAsUser(). The only solutions I've found involve using the task scheduler to launch the program. That doesn't strike me as very practical.
An easy solution that jumps to mind is to use a small non-elevated helper process. It can in turn launch the elevated setup process and wait for a confirmation from that one to launch the non-elevated one. The handshake is simple enough to do this with a named mutex.
The only way to do this without hacks is to have two processes (Can be implemented in the same .exe)
Instance A starts Instance B with ShellExecute and the runas verb.
B does the installing, when its time to start your app on the "finish page", it uses some form of inter processes communication (RPC, shared memory+events etc) with A telling it to start a process on its behalf.
This seems like a nice way to do it, provided you don't care about situations where the Shell is not running (e.g. possibly some Terminal Services application-only setups, perhaps, though I'm not sure):
http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-for-you-part-2-how/
It gets an interface to Explorer.exe, which should be running in the user's normal context, and asks Explorer to execute a command in its behalf. This is done just using simple, documented COM interfaces and without having to mess around with process tokens or code/DLL injection.
I have a service which constantly checks some application and assures that it wasn't closed. If this app closed - service launches it again.
The problem starts when user decides to log off the session. During logoff all applications are closing including the mine one. But the service is still running and constantly trying to start it again.
The questions is how to notify the service that user is going to log off and the application doesn't need to be restarted anymore? I've tried to make it using SERVICE_CONTROL_SESSIONCHANGE notification. But in accordance to MSDN they come to services when all apps already closed and logging off procedure completed. It is too late for me. Is there any way to programmatically find out that current session is in process of logging off?
My service launched under LocalSystem account.
Thanks.
p.s. I don't have the access to application source code. The goal need to be achieved without modifying it.
Have your service run two applications: the one it is a watchdog for, and a second one which you implement yourself. This second one can then respond to the log-off event by sending a message to the service (a la David Heffernan's answer), and the service will then know not to restart the watched job.
Open a communication channel between your app and your service and arrange for the app to tell the service that it is closing because of a logoff event.
You may not have access to the source code of the executable, but that doesn't mean that you can't affect the process. For instance, you could inject a DLL. Using SetWindowsHookEx, you'd catch the WM_ENDSESSION sent to the apps main window.
Why don't you create your service under the user that is running the App and tell it to startup automatic? In this case you should get the SERVICE_CONTROL_SHUTDOWN message when your user is logging off since the service would also be terminated.
How Can I execute a function when Windows shutdown. Here is my scenario, I am mounting a drive using WNetAddConnection2 function in my application. Now I want user to set the option if the drive will be mounted on next system startup or not.
If he selects , not to mount on next startup , then I need to remove the drive using WNetCancelConnection2 , but this should only happen when user shutdown the system.
I can only think of only solution. Create a service which will check the user option and then decide whether to mount the drive or not.
Are there any other ways to go ahead with it?
If you have a main window (even an invisible one) that can process messages, you can handle the WM_ENDSESSION message.
See: http://msdn.microsoft.com/en-us/library/aa376889(v=VS.85).aspx
If you can make your app into a Windows service (or have your app communicate state with one that you provide) you can perform required actions on receipt of SERVICE_CONTROL_SHUTDOWN in your service control handler function. This would decouple your app that handles user interaction from the shutdown handling, which requires something to be running all the time (what if the user logs off?).
explorer.exe is the GUI process of windows which usually only gets shut down if Windows shuts down (exceptions have to be made for certain error conditions). You could listen on the WM_DESTROY window message for the process ID of explorer.exe and dismount then.
The way I can think of is to:
Register your program to auto Start up (when PC starts). Here's a tutorial on howto.
Store the user option (as mentioned above) in a repository or registry (if you know how). When your app would have started, you can read your registry and act accordingly.
For shutdown, your application will have to hook itself on a SystemEvent to detect shutdown (then you can act accordingly). Here's an example on howto (C#). For C++, you can listen to WM_ENDSESSION message.
I hope that my 2 cents can help you.
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.