I have a Win32 service, that needs to run a .NET executable on service stop (for cleanup reasons). I recently discovered that the cleanup never happens on shutdown, because the process creation gets blocked by OS. Does anyone know a way to override this? Process, I am spawning is not invasive and should only run a fraction of a second.
The only way I could find to do it was: pre-create a child process suspended, and them un-suspend it on shutdown.
Related
Related to a question I asked here -- I have a process that I launched which is in a "suspended" state. I cannot kill or resume this process through any of the normal means (process explorer, task manager, WinDbg).
Logging-out of my session DOES kill this process though. How? What mechanism is the OS using when I log out that is somehow different to what Process Explorer is trying to do?
Edit: To clarify - I am assuming that Process Explorer is calling the TerminateProcess API function when it tries to kill a process. Something in the process state is stopping this from working though. Logging out obviously invokes some different behaviour and Windows ignores whatever was blocking TerminateProcess, and kills the process due to my session ending.
As a user, is there any different way to try and terminate a process other than calling the TerminateProcess API?
Process Explorer can't kill a process itself; it can only ask the OS to do so. The OS itself doesn't have to play by its own rules.
Remember, it's the OS itself which defines what a process is. It might very well define a process as part of a logon session. This would imply that if you clean up the whole session then you don't need to clean up individual processes. Just like you don't need to bother with CloseHandle before ExitProcess either.
I am writing a normal, innocent C++/Qt program in Windows 7/MinGW.
It is the second time in two days that after closing the program the executable remains among the active processes, and there is no way to kill it (I try both from the command line and from Windows Task Manager).
One inconvenience is that I cannot re-link my code, because the binary code cannot be overwritten, being running.
The reason is that the executable was running under the control of the debugger, and this protected the process against any attempt to kill it. Stopping it through the debugger has been successful.
I did not know that the debugger could shield a process from any external attempt to kill it so well...
I'm working with CreateProcess to run a process/application of mine.
The purpose is to run it, do something, wait for some indication, and close it (Using TerminateProcess).
What I noticed is that this application/process creates sub-processes.
Additionally, when terminating the created process, the sub-processes do not terminate, and still remain for a period of time.
I wanted to ask if there's an option to somehow kill all the sub-processes with the main process.
It causes issues, since when I do CreateProcess again, there are leftovers from previous processes, and I think they're causing some issues.
I really appreciate your help!
Use Windows Job Objects. Jobs are like process groups; the operating system will take care of terminating all processes in the job once the job leader (your initial process) is terminated. This even works if the proess leader crashes.
When you create a process using CreateProcess you'll get a LPPROCESS_INFORMATION-pointer.
It contains the process handle. You'll need to close the processes manually, as there is no such thing as a process hierarchy as in Linux/Unix.
See here for CreateProcess and here for the PROCESS_INFORMATION-structure.
My application creates a suspended process, gets process's information via VirtualQueryEx() ,but fails getting process's module information using EnumProcessModules().
The task above is completed ONLY if the process is NOT created suspended and a breakpoint is hit in the debugger(so the program runs, before the call is executed).
I'm trying to write a very decent disassembler and for that I would need to run a target process suspended, but EnumProcessModules() does not work on suspended processes.
Is there an alternative?
I dealt with something like this several years ago. If I remember right, what I ended up doing was creating the task suspended, then GetThreadContext, set its trap flag, SetThreadContext, resume the thread (which runs one instruction), then use EnumProcessModules.
Of course, there may be other ways to handle this, but at least if memory serves, that's what I came up with at the time and I seem to recall its working.
How to reload a crashed process on Windows? Of course, I can run a custom monitoring Win service process. But, for example, Firefox: it doesn't seem to install such a thing, but still it can restart itself when it crashes.
On Vista and above, you can use the RegisterApplicationRestart API to automatically restart when it crashes or hangs.
Before Vista, you need to have a top level exception filter which will do the restart, but be aware that running code inside of a compromised process isn't entirely secure or reliable.
Firefox constantly saves its state to the hard disk, every time you open a tab or click a link, or perform some other action. It also saves a flag saying it shut down safely.
On startup, it reads this all back, and is able to "restore" based on that info.
Structured exception handling (SEH) allows you to catch program crashes and to do something when it happens.
See: __try and __except
SEH can be very dangerous though and could lead to your program hanging instead. Please see this article for more information.
If you write your program as an NT service then you can set the first, second and subsequent failure actions to "Restart the service".
For Windows 2008 server and Windows Vista and Windows 7 you can use the Win32 API RegisterApplicationRestart
Please see my answer here for more information about dealing with different types of program crashes.
If I recall correctly Windows implements at least some subset of POSIX and so "must" have the signal interface (things like SIGKILL, SIGSEGV, SIGQUIT etc.).
I've never done this but on linux, but you could try setting the unexpected termination trap with signal() (signal.h).
From quick scan of docs it seems that very few things can be done while handling signal, it may be possible that even starting a new process is on forbidden list.
Now that I've thought about it, I'd probably go with master/worker pattern, very simple parent thread that does nothing but spawns the worker (that does all the UI / other things). If it does not set a specific "I'm gonna die now" bit but still dies (parent process always gets message / notification that spawned process died) then master respawns the worker. The main theme is keep master very simple and hard to die due to own bugs.