^C sent to the stdin of a program running under a pseudo console does not generate break

Question

^C sent to the stdin of a program running under a pseudo console does not generate break

Jonathan Gilbert 0

I've written a program that launches a console application within a pseudoconsole. Following the documentation, I:

Create two anonymous pipes.
Call CreatePseudoConsole, passing in the appropriate end of each of the pipes for standard input & standard output.
Create a process thread attribute list and stash the hPC value in it.
Link to the process thread attribute list from a STARTUPINFOEX structure.
Call CreateProcessW, passing in that STARTUPINFOEX.
Start reading bytes from the parent end of the standard output pipe and interpreting escape sequences. This seems to be working well. :-)
Receive keyboard input events from my front-end, translate them to byte sequences and send them to the parent end of the standard input pipe. This is also mostly working well, arrow keys and such functioning just fine.

Everything I've read indicates that if a byte 0x03 ("ETX"?) is sent to the child process' standard input, this will effectively become a ^C console control event. But, when I do this, no break results.

If the child process is cmd and I'm at a prompt, then when I send byte 0x03, it cancels the input and goes to the next line, looking exactly like cmd does in a regular console window. But, if I run e.g. ping and it is waiting between pings, in a regular console window, pressing ^C results in the process being interrupted, and in fact writing the strings Control-C and ^C to its output before terminating. When my code sends byte 0x03 to its child ping process, though, it doesn't appear to have any effect at all. This happens whether ping is a direct child process of my application or I run cmd as a child process of my application and then launch ping from the command-line.

Searches tell me that what's missing is the console mode flag ENABLE_PROCESSED_INPUT, but as far as I can tell, that can only be set with a direct call to the SetConsoleMode API with the process attached to the console. It doesn't seem to be applicable in the context of interacting with the child process via ConPTY.

I must be missing something, but I haven't been able to figure out the next step to take to uncover it. Does anybody know what's going on?

ETA:

I've been doing further investigation on my end, and I'm pretty sure the AI response is just 100% factually incorrect. It states that the stdin pipe is just a raw character sequence for the target application to process, but with ConPTY, the stdin stream is processed by the console host to translate terminal escape sequences representing input keys into KEY_INPUT_RECORD structures to be written to the traditional console input queue. I haven't found the source of my problem yet, but I have found loads of code within the Microsoft Terminal codebase specifically oriented to the handling of non-textual keys, including control keys and including special handling for Ctrl+C specifically. This handling runs when ETX, or byte 3, is read from the pipe -- and on the other end, in the Terminal GUI app which acts as a client, Ctrl-letter key combinations are translated to (letter - 0x40) bytes, so that Ctrl-C produces byte (0x43 - 0x40) == 3.

Here's the ConPTY code that does, in fact, "synthesize control events from characters", following the sequence of calls down the call stack:

Interestingly, as can be seen at that final point in the code, the ConPTY code does explicitly read & check the ENABLE_PROCESSED_INPUT flag in the traditional Win32 consoles world, as is normally exposed via SetConsoleMode/GetConsoleMode (that's what IsInProcessedInputMode returns). If ENABLE_PROCESSED_INPUT isn't set, then it doesn't call HandleCtrlEvent.

So, one possible explanation for the symptoms I'm seeing is that, for some reason, when my process launches a cmd.exe or ping.exe child process, it is ending up with ENABLE_PROCESSED_INPUT off. I'm not sure how that would happen, though, or why it'd be different from, say, Start->Run cmd.exe or ping.exe.

Jonathan Gilbert 0 Reputation points

2026-03-23T00:56:19.51+00:00

(There was initially an AI autoresponse that was 100% factually wrong. I tried to reply to it, but commenting on it was disabled and so the button I clicked on actually added an "Answer". The AI response has been removed, so I have collapsed by "Answer" that wasn't really an answer into the question body.)
Viorel 126.8K Reputation points

2026-03-23T03:29:53.9533333+00:00
Meanwhile, I adapted the EchoCon example from https://github.com/microsoft/terminal. It already contains a thread for intercepting and displaying the output. A new thread was added for simulating user input:

void __cdecl InputThreadProc( LPVOID pipe ) { HANDLE hPipe{ pipe }; Sleep( 3333 ); DWORD n; BOOL r = WriteFile( hPipe, "\x03", 1, &n, NULL ); }

The command was also changed to ping -t localhost.

In this experiment, the output was interrupted and “Control-C” was displayed as expected. It seems that 0x03 had an effect.
Jonathan Gilbert 0 Reputation points

2026-03-23T05:07:56.52+00:00

For some reason I don't seem to be able to @ you Viorel, but thanks very much for taking an interest. :-)

Your investigation shows that it is possible for character 3 to be interpreted as ^C, but the EchoCon test application is far removed from my code and written in a different language.

I've just isolated a reproduction of the issue by copying out just the pertinent code from my main project, and in the reproduction, I see the same behaviour that I reported. So, there's something different between EchoCon and my code. It is of course most likely a bug or oversight of some sort in my code. I haven't been able to figure out what it is yet, though. :-(

Here's the repro, if you (or anyone else :-) ) have the time to investigate:

https://github.com/logiclrd/CtrlCRepro

Thanks again!
Taki Ly (WICLOUD CORPORATION) 150 Reputation points Microsoft External Staff Moderator

2026-03-23T08:27:38.6366667+00:00

Hi @Jonathan Gilbert ,

I am looking into this and will response back to you as soon as possible.
Viorel 126.8K Reputation points

2026-03-23T09:43:56.12+00:00

Is NewProcessGroup really needed? Try to remove it.
Jonathan Gilbert 0 Reputation points

2026-03-23T10:37:21.29+00:00

If I remove the NewProcessGroup flag, then the ^C signal starts working. But, what are the side-effects of removing the flag? The documentation suggests that without it, events that happen to the child process could affect the parent as well. Does that only apply if the parent process is attached to a console that the child process can inherit?? The documentation explicitly suggests that a ^C received by a child process could terminate the parent, but that doesn't happen to my GUI parent with NewProcessGroup removed. That's the outcome I want but I want to understand why I'm getting it to be confident about it. :-)
Jonathan Gilbert 0 Reputation points

2026-03-23T11:24:13.4333333+00:00

I think I understand the direct cause. Looking at the code, I see that the conhost process is created in the call to CreatePseudoConsole, and that code doesn't supply any flags to CreateProcessW (other than EXTENDED_STARTUPINFO_PRESENT). If I then subsequently create my child process with CREATE_NEW_PROCESS_GROUP, then the conhost and the process whose console it is presenting as a PTY are in different process signalling groups, so when conhost tries to deliver the ^C signal (using the internal API call ConsoleControl, I don't know what relation this has to GenerateConsoleCtrlEvent), it doesn't reach the new child.

I just don't know what the implications are for my parent process. I suppose if I really need a new process group, I could create an intermediate process using CREATE_NEW_PROCESS_GROUP, and then create the pseudo console and the child attached to it normally from that intermediate process. But, I don't know if I really need a new process group or not.
Jonathan Gilbert 0 Reputation points

2026-03-23T12:09:00.0666667+00:00
I found this fascinating discussion on an unrelated issue:

https://github.com/microsoft/Terminal/issues/335

I came across this doing various searches related to things I observed in the Terminal codebase. When a ^C event is received, there's a whole chain of events that take place. Picking up from where my previous analysis stopped:

HandleCtrlEvent in input.cpp sets flag CONSOLE_CTRL_C_FLAG in the CtrlFlags field of CONSOLE_INFORMATION

This gets picked up by the next call to ProcessCtrlEvents, which calls ConsoleControl::EndTask.

This in turn calls the aforementioned ConsoleControl, and this is as far as I got.

The discussion in that issue explains what ConsoleControl is doing: It makes an LPC call to CSRSS, and the code it calls goes through each of the processes in the process group and creates a new thread in it to execute CtrlRoutine, exported by kernelbase.dll.

I don't have access to the source code to the server it's calling into (I think?), but experimentally neither GenerateConsoleCtrlEvent nor ConsoleControl(EndTask) cause CtrlRoutine to execute in a GUI process (even if it calls AllocConsole after startup). It's a bit hand-wavy, but this feels like perhaps it is safe to not worry about process groups since my parent process is not a console application... maybe? :-)

1 answer

Your answer

Jonathan Gilbert 0 Reputation points

2026-03-23T00:56:19.51+00:00

(There was initially an AI autoresponse that was 100% factually wrong. I tried to reply to it, but commenting on it was disabled and so the button I clicked on actually added an "Answer". The AI response has been removed, so I have collapsed by "Answer" that wasn't really an answer into the question body.)
Viorel 126.8K Reputation points

2026-03-23T03:29:53.9533333+00:00

Meanwhile, I adapted the EchoCon example from https://github.com/microsoft/terminal. It already contains a thread for intercepting and displaying the output. A new thread was added for simulating user input:

void __cdecl InputThreadProc( LPVOID pipe ) { HANDLE hPipe{ pipe }; Sleep( 3333 ); DWORD n; BOOL r = WriteFile( hPipe, "\x03", 1, &n, NULL ); }

The command was also changed to ping -t localhost.

In this experiment, the output was interrupted and “Control-C” was displayed as expected. It seems that 0x03 had an effect.
Jonathan Gilbert 0 Reputation points

2026-03-23T05:07:56.52+00:00

For some reason I don't seem to be able to @ you Viorel, but thanks very much for taking an interest. :-)

Your investigation shows that it is possible for character 3 to be interpreted as ^C, but the EchoCon test application is far removed from my code and written in a different language.

I've just isolated a reproduction of the issue by copying out just the pertinent code from my main project, and in the reproduction, I see the same behaviour that I reported. So, there's something different between EchoCon and my code. It is of course most likely a bug or oversight of some sort in my code. I haven't been able to figure out what it is yet, though. :-(

Here's the repro, if you (or anyone else :-) ) have the time to investigate:

https://github.com/logiclrd/CtrlCRepro

Thanks again!
Taki Ly (WICLOUD CORPORATION) 150 Reputation points Microsoft External Staff Moderator

2026-03-23T08:27:38.6366667+00:00

Hi @Jonathan Gilbert ,

I am looking into this and will response back to you as soon as possible.
Viorel 126.8K Reputation points

2026-03-23T09:43:56.12+00:00

Is NewProcessGroup really needed? Try to remove it.
Jonathan Gilbert 0 Reputation points

2026-03-23T10:37:21.29+00:00

If I remove the NewProcessGroup flag, then the ^C signal starts working. But, what are the side-effects of removing the flag? The documentation suggests that without it, events that happen to the child process could affect the parent as well. Does that only apply if the parent process is attached to a console that the child process can inherit?? The documentation explicitly suggests that a ^C received by a child process could terminate the parent, but that doesn't happen to my GUI parent with NewProcessGroup removed. That's the outcome I want but I want to understand why I'm getting it to be confident about it. :-)
Jonathan Gilbert 0 Reputation points

2026-03-23T11:24:13.4333333+00:00

I think I understand the direct cause. Looking at the code, I see that the conhost process is created in the call to CreatePseudoConsole, and that code doesn't supply any flags to CreateProcessW (other than EXTENDED_STARTUPINFO_PRESENT). If I then subsequently create my child process with CREATE_NEW_PROCESS_GROUP, then the conhost and the process whose console it is presenting as a PTY are in different process signalling groups, so when conhost tries to deliver the ^C signal (using the internal API call ConsoleControl, I don't know what relation this has to GenerateConsoleCtrlEvent), it doesn't reach the new child.

I just don't know what the implications are for my parent process. I suppose if I really need a new process group, I could create an intermediate process using CREATE_NEW_PROCESS_GROUP, and then create the pseudo console and the child attached to it normally from that intermediate process. But, I don't know if I really need a new process group or not.
Jonathan Gilbert 0 Reputation points

2026-03-23T12:09:00.0666667+00:00

I found this fascinating discussion on an unrelated issue:

https://github.com/microsoft/Terminal/issues/335

I came across this doing various searches related to things I observed in the Terminal codebase. When a ^C event is received, there's a whole chain of events that take place. Picking up from where my previous analysis stopped:

HandleCtrlEvent in input.cpp sets flag CONSOLE_CTRL_C_FLAG in the CtrlFlags field of CONSOLE_INFORMATION

This gets picked up by the next call to ProcessCtrlEvents, which calls ConsoleControl::EndTask.

This in turn calls the aforementioned ConsoleControl, and this is as far as I got.

The discussion in that issue explains what ConsoleControl is doing: It makes an LPC call to CSRSS, and the code it calls goes through each of the processes in the process group and creates a new thread in it to execute CtrlRoutine, exported by kernelbase.dll.

I don't have access to the source code to the server it's calling into (I think?), but experimentally neither GenerateConsoleCtrlEvent nor ConsoleControl(EndTask) cause CtrlRoutine to execute in a GUI process (even if it calls AllocConsole after startup). It's a bit hand-wavy, but this feels like perhaps it is safe to not worry about process groups since my parent process is not a console application... maybe? :-)

Answer 1

Jonathan Gilbert 0

(I initially accidentally wrote an "Answer" that was intended to be a reply to an AI "Answer".)

Share via

^C sent to the stdin of a program running under a pseudo console does not generate break

1 answer

Your answer