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()
Related
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 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.
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.
I have a single thread that I'd like to run as an administrator in my application. The rest of the application I can happily run as the default user level (asInvoker). Is this possible? I notice there is an "ImpersonateLoggedOnUser" function. Can I somehow use this to log the administrator on and then get the thread to impersonate that person?
It seems as though this ought to be something pretty trivial to do ... but there doesn't appear to be any obvious way to do it. Can anyone help me out?
Edit: So if I have to fire off a seperate process is there any way I can CreateProcess a new process and have it launch from a specific entry point. I can, of course use command line processing to do it, but i'd really rather I could stop the user from entering the command line and starting an unclosable process!
No, elevation is per process, not thread.
If the rest of the application has to run non-elevated, you could run yourself elevated with some parameter (myapp.exe /uac "ipcparamhere") and use some sort of Inter-process communication to communicate back to the "main instance" of your app. (If the elevated process only performs a simple operation, you could probably check for success by using the exit code of the process)
This is not possible. You'll need to gain admin privileges by including a manifest in the app. Google "requireAdministrator" to find the manifest you'll need. Your user will probably quickly tire of doing this over and over again, your best bet is to spin-off the task that requires these privileges into a separate process. A service for example.
You can launch a separate exe and have a manifest on it saying it requires administrator. Then be sure to launch it with shell execute, which uses manifests, and you're all set. As a thoughtful touch, put a UAC shield on the button that kicks off that thread. (Send it a BCM_SETSHIELD message if you're doing this all by hand.)
You can decided whether you want a visible window or not on the separate process. Meanwhile the user can still drag and drop into the main app.