Run arbitrary subprocesses on Windows and still terminate cleanly?

Question

I have an application A that I would like to be able to invoke arbitrary other processes as specified by a user in a configuration file.

Batch script B is one such process a user would like to be invoked by A. B sets up some environment variables, shows some messages and invokes a compiler C to do some work.

Does Windows provide a standard way for arbitrary processes to be terminated cleanly? Suppose A is run in a console and receives a CTRL+C. Can it pass this on to B and C? Suppose A runs in a window and the user tries to close the window, can it cancel B and C?

TerminateProcess is an option, but not a very good one. If A uses TerminateProcess on B, C keeps running. This could cause nasty problems if C is long-running, since we might start another instance of C to operate on the same files while the first instance of C is still secretly at work. In addition, TerminateProcess doesn't result in a clean exit.

GenerateConsoleCtrlEvent sounds nice, and might work when everything's running in a console, but the documentation says that you can only send CTRL+C to your own console, and so wouldn't help if A were running in a window.

Is there any equivalent to SIGINT on Windows? I would love to find an article like this one: http://www.cons.org/cracauer/sigint.html for Windows.

Kindling

+1 for good question. Funny there have been no answers... I am not aware of a signal-like mechanism in Win32. When I needed to notify child processes I posted a WM_CLOSE message to GUI apps. For console applications I created them by attaching input and output streams to the main application and when I wanted to terminate them I just closed the input stream. As for children of children etc, I relied on my direct children to cleanup their dependencies :). – Piroshki

Here's what the gitlab runner does; they have two mechanisms, first, GenerateConsoleCtrlEvent, and when that fails, they try unclean kill with taskkill. Implemented in gitlab.com/gitlab-org/gitlab-runner/-/blob/… – Boltrope

Answer 1

I guess I'm a bit late on this question but I'll write something anyway for anyone having the same problem.

My problem is similar in that I'd like my application to be a GUI application but the processes executed should be run in the background without any interactive console window attached.

I managed to solve this using GenerateConsoleCtrlEvent(). The tricky part is just that the documentation is not really clear on exactly how it can be used and the pitfalls with it.

My solution is based on what is described here. But that didn't really explain all the details either, so here is the details on how to get it working.

1. Create a new helper application "Helper.exe". This application will sit between your application (parent) and the child process you want to be able to close. It will also create the actual child process. You must have this "middle man" process or GenerateConsoleCtrlEvent() will fail.

2. Use some kind of IPC mechanism to communicate from the parent to the helper process that the helper should close the child process. When the helper get this event it calls "GenerateConsoleCtrlEvent(CTRL_BREAK, 0)" which closes down itself and the child process. I used an event object for this myself which the parent completes when it wants to cancel the child process.

To create your Helper.exe create it with CREATE_NO_WINDOW and CREATE_NEW_PROCESS_GROUP. And when creating the child process create it with no flags (0) meaning it will derive the console from its parent. Failing to do this will cause it to ignore the event.

It is very important that each step is done like this. I've been trying all different kinds of combinations but this combination is the only one that works. You can't send a CTRL_C event. It will return success but will be ignored by the process. CTRL_BREAK is the only one that works. Doesn't really matter since they will both call ExitProcess() in the end.

You also can't call GenerateConsoleCtrlEvent() with a process groupd id of the child process id directly allowing the helper process to continue living. This will fail as well.

I spent a whole day trying to get this working. This solution works for me but if anyone has anything else to add please do. I went all other the net finding lots of people with similar problems but no definite solution to the problem. How GenerateConsoleCtrlEvent() works is also a bit weird so if anyone knows more details on it please share.

Dennis

Note that there is no guarantee that processes B or C will exit cleanly on receipt of Ctrl+C. – Poisonous

Although there's no guarantee an abritrary application will respond to Ctrl+C, if it is given that the target application is in fact known to terminate cleanly in response to ctrl+c, then it is important to know about this method, which can cause any such known application to terminate cleanly. – Sham

The accepted answer should be the one from @Ketti – Chassis

Answer 2

As @Shakta said GenerateConsoleCtrlEvent() is very tricky, but you can send Ctrl+C without helper process.

void SendControlC(int pid)
{
    FreeConsole(); // detach from the current console
    AttachConsole(pid); // attach to process console
    SetConsoleCtrlHandler(NULL, TRUE); // disable Control+C handling for our app
    GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0); // generate Control+C event
}

Ketti

This was very helpful! Only one thing missing - you have to call FreeConsole before you use AttachConsole, otherwise you'll get ERROR_ACCESS_DENIED (5) since the calling process is already attached to a console. – Radioactivate

This is the only answer across a dozen questions that has had ANY success for me, thank you! – Nicholas