I need to prepare a program which runs in the background without a window or anything on the taskbar. You may compare this to the idea of a program which runs in the background and sends a signal every once in a while to keep the computer from sleeping.
So here are the two ideas that I have on my mind
1) Creating a windows Service
2) Spawning a thread and exiting main
Please let me know how viable these are, particularly the second one, and what other possibilities do we have at our disposal.
Thanks in advance!!
Just link your application for windows subsystem, not console
If you're looking to run a background process then go with the service approach. You'll be able to configure it to run even when nobody is logged in and it won't be intrusive to the user.
Related
I have a C++ windows service running on system privileges and I need to make some changes in some of my DLLs that are loaded to several windows processes (explorer.exe, etc.).
The only time to do so is when these processes are down. I'm trying to make to impact to the UX minimal, so I don't wan't to force quit those or to popup any annoying message boxes and ask the user to do so.
I have tried to start this task on the startup of my service, the issue is several of these processes start before I finished it.
I'm trying to understand if there is a way to delay the start of processes on Windows startup, until I finish my task. Is there any event or anything familiar that I can set that will block those?
The other option is to do the needed task on shutdown. I did not find a way to do so yet, and all the related questions seem a bit old (how to delay shutdown and run a process in window service
), and regard to older version of windows.
This solution needs to be compatible with Windows versions greater than 7.
You can do this by using MoveFileEx and setting MOVEFILE_DELAY_UNTIL_REBOOT which will replace the file at the next reboot.
This should be well before any other processes have started, but without more details on your usecase its hard to tell if this'll work for you. Either way, searching for this flag should give you lots of information about this kind of issue.
According to the documentation, this has been supported since XP.
I have an application that opens another process and modifies its memory. What I'd like to have as a part of the GUI is a label that updates (perhaps every second or so) to let the user know if they're attached to the other process.
When the application is found running, I'm creating a handle to it, obtaining the base address of it, and then the rest of the work is done through button clicks and hotkeys. Anyway, for each time the application is found running, I want it to do all the things I have it do to obtain the handle, etc., etc.
This way, the other application can be closed and reopened without my app also needing to be closed/reopened accordingly.
Thus far, my research has led me to CreateThread() and std::async (as well as std::launch::async and std::launch::deferred). The issue I'm having is I can't seem to find examples of infinitely-running asynchronous code (in its own thread, perhaps). I'm having a difficult time wrapping my head around how to make this happen, as everything I've tried still keeps execution from continuing as if I'd just written a while loop in main() or something.
Anything exemplifying the type of functionality I'm looking to achieve would be immensely appreciated! Thanks for your time and help, everyone.
I was sitting around bored and thought of this idea. Is it possible to change the WM_DESTROY code so that it will do something else instead of closing the application. But, I don't think this will work, but does that keep it from closing when you try to close the application from the task manager in windows. Also, is there a way to remove my application from the task manager so they wouldn't be able to do that in the first place? So, is this possible or do you have a better way? I have googled this and have tried this, but I want to ask the experienced here to answer this question.
BTW, I am not making a virus.
Windows Task Manager will use TerminateProcess to "close" a process - which is a good thing if your program has accidentally or on purpose got a broken VM_DESTROY handler.
There are supposedly ways to mess about with the process list that hides a process. But I don't actually know how that is done othat than very fundamentally (the process list is a linked list, and you can "unlink" a process from the list, and it "disappears"). Obviously doing so would be the type of thing that virus, trojan's, spyware, etc does, and I don't see any reason why you would want to do that in a legitimate application.
Edit: And hiding the application just means it doesn't appear in the list of processes in task manager. If you KNOW that the task exists (and you could for example "guess" based on system activity or some such), it can still be killed using it's process ID by some application that has enough privileges to terminate the process.
you shoud read win32 api demo. when mainwindow receives WM_DESTROY message, call postquitmessage([exitcode]) to end message loop。
Is is possible that someone can hide his or her thread from the CreateTool32Help api? I want to know this because I'm building an anti-cheat program for a little game I made. I don't want to go into kernel mode so the only way I can stop intruders injecting threads into my process is by comparing the threads I created with those found in the snapshot.
Could there be ways to circumvent this measure? I've hooked NtSetInformationThread just in case.
If somebody is running code inside your process, then you've already lost. Once they're in your process, they can patch your code that tries to detect them!
unfortunately many times the Flash plugin at Google's Chrome crashes. But fortunately, they just present a message box and a sad face.
My question is, how do they do it? my first thought is that they use structured exception handling but then again, how they know its Flash that crashed?
thanks for any ideas!
Lior
Chrome runs plugins in an entirely separate process from the rest of the page.
If the process ever crashes or locks up, then the plugin must be dead.
they run it in a separate process. when the child process terminates, the parent is notified by the operating system. the parent can then query the system about the nature of the termination.