I created a C# console application to handle Ctrl-C by subscribing it to Console.CancelKeyPress event. When I executed (debug version) the application, there were 14 threads already created in the process. When I pressed Ctrl-C a new, 15th thread was created and my handler was invoked. I used process explorer from sysinternals to view the state of the process.
I am curious to know the internals on how the Ctrl-C message is delivered to a process and how the additional thread gets created? I guess, even if I do not subscribe to an event, it will still create an additional thread and exit the process. How is the default mechanism for handling Ctrl-C is setup for an application.
I am a .net developer but want to understand on how the windows operating system works under the hood. The above question is only out of curiosity to learn windows operating system.
When Windows needs to notify a console program of an external event, there is no window message loop to send the notification to, so Windows will create a thread in the target process to execute whatever callback function is defined. The default handler for the CTRL+C event just calls ExitProcess, but hooking the CancelKeyPress event calls the Win32 SetConsoleCtrlHandler function with a handler function.
The documentation for the handler function explains how it works:
An application-defined function used with the SetConsoleCtrlHandler function. A console process uses this function to handle control signals received by the process. When the signal is received, the system creates a new thread in the process to execute the function.
Note that the thread that Windows injects into your process has a fairly small stack, so the CLR handler routine actually queues up a Threadpool work item to execute your event handler. This means that the thread injected by Windows and a worker thread could both be created, causing you to see up to 2 additional threads during the processing of the CTRL+C event.