Disable ALT+F4 for C# Console Application?

Question

im using c# .net 2.0 Console Application.

How can i prevent my console application from ALT+F4 shortcut?

is there any way to do that?

everywhere there is winform solution.

I need console app solution.

please help me

Answer 1

@Jeroen Mostert:

i found a final working solution from prevent exiting console app by the user.

Everybody says its not possible. But yes it possible with simple tweak.

Here we go

using C#

                RegistryKey objRegistryKey = Registry.CurrentUser.CreateSubKey(@"Console");
                objRegistryKey.SetValue("AllowAltF4Close", "0" , RegistryValueKind.DWord);

I cant post my full code here due to copyright

but this code works within my application. I tried to make a sample but that not works. But within my full application this works and Nobody can close by pressing ALT+F4.

this is a real solution for all. I don't know which part is required within my all code to make sample.

but this works.

you can just change value 0 to 1 to enable ALT+F4

CMD will not closing if you use this code. try code and launch another cmd. i dont need to launch another CMD. within my code that works for itself.

Answer 2

The answer is "yes, possibly, depending on your version of Windows, but try not to count on it".

At least on my version of Windows 10 (22H2) what works is setting the ENABLE_WINDOW_INPUT flag using SetConsoleMode, while the ENABLE_PROCESSED_INPUT flag is cleared (which is normally used to intercept Ctrl-C and Ctrl-Break only).

ENABLE_WINDOW_INPUT is only documented as "user interactions that change the size of the console screen buffer are reported in the console's input buffer", but experimentally, it also causes Alt-F4 to be treated as regular input rather than a close event (which can then be retrieved using Console.ReadKey, for example). Here's how that goes:

const int STD_INPUT_HANDLE = -10;
const int ENABLE_WINDOW_INPUT = 0x08;

[DllImport("kernel32.dll", SetLastError = true)]
static extern IntPtr GetStdHandle(int nStdHandle);

[DllImport("kernel32.dll", SetLastError = true)]
internal static extern bool GetConsoleMode(IntPtr hConsoleHandle, out int mode);

[DllImport("kernel32.dll", SetLastError = true)]
internal static extern bool SetConsoleMode(IntPtr hConsoleHandle, int mode);

static void Main() {
    Console.TreatControlCAsInput = true;
    IntPtr stdin = GetStdHandle(STD_INPUT_HANDLE);
    GetConsoleMode(stdin, out var mode);
    SetConsoleMode(stdin, mode |= ENABLE_WINDOW_INPUT);
    Console.CancelKeyPress += (o, e) => {
        if (e.SpecialKey == ConsoleSpecialKey.ControlBreak) {
            Console.WriteLine("Control-Break pressed.");
            e.Cancel = true;
        }
    };
    Console.WriteLine("Press Ctrl-C or Alt-F4 or Control-Break as you please.");
    while (true) {
        var keyInfo = Console.ReadKey(intercept: true);
        if (keyInfo.Modifiers == ConsoleModifiers.Control && keyInfo.Key == ConsoleKey.C) {
            Console.WriteLine("Control-C pressed.");
        } else if (keyInfo.Modifiers == ConsoleModifiers.Alt && keyInfo.Key == ConsoleKey.F4) {
            Console.WriteLine("Alt-F4 pressed.");
        } else {
            Console.Write(keyInfo.KeyChar);
            if (keyInfo.KeyChar == '\r') {
                Console.WriteLine();
            }
        }
    }
}

For completeness, we also handle Control-Break here, which otherwise still serves as an unconditional interrupt. Note that Control-C cannot be handled by CancelKeyPress anymore and must be handled as input.

This trick does not work in the new Windows Terminal, which may one day replace the default system terminal, nor is it guaranteed to continue working in other versions of Windows.

The only way to stop this application now is terminating it with the close button or the system menu. Completely preventing this from happening would require direct manipulation of the parent window and is not advisable -- consider writing a regular GUI application or a service instead if you really want something to run in the background with full customization.

That said, it is possible to implement custom handling for at least the first close that can run for as long as you like, to implement cleanup. That relies on even more P/Invoking and dirty tricks and is beyond the scope of this question, however -- the basic idea is to use SetConsoleCtrlHandler yourself and calling ExitThread inside the handler (the .NET CancelKeyPress handler will not do for this, because it does not handle CTRL_CLOSE_EVENT).

Because none of these approaches will prevent the user from killing your application anyway, and because it relies on undocumented behavior that will almost certainly not be replicated in future versions, I would strongly advise against going this way and implementing a service or regular GUI application instead, or making your console application robust against termination by having it implement cleanup/recovery on startup instead, rather than on exit.