starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Cannot set SetConsoleCtrlHandler #14503

New Issue
Closed
opened 2026-01-31 04:12:01 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 04:12:01 +00:00
Owner
Copy Link

Originally created by @blacklightpy on GitHub (Jul 13, 2021).

Windows Terminal version (or Windows build number)

1.9.1523.0

Other Software

I wrote a console application in C++ and wanted to handle CTRL_CLOSE_EVENT.
I set my default terminal as Windows Terminal, so the app launched in it by default.
I wasn't sure why the method wasn't working and after a while I decided to try out running the program in conhost and it worked.

Here's the code:

BOOL WINAPI CtrlHandler(DWORD fdwCtrlType)
{
    switch (fdwCtrlType)
    {
    case CTRL_C_EVENT:
        printf("Ctrl-C event\n\n");
        Beep(750, 300);
        return TRUE;

    case CTRL_CLOSE_EVENT:
        Beep(600, 200);
        printf("Ctrl-Close event\n\n");
        return TRUE;

    case CTRL_BREAK_EVENT:
        Beep(900, 200);
        printf("Ctrl-Break event\n\n");
        return FALSE;

    case CTRL_LOGOFF_EVENT:
        Beep(1000, 200);
        printf("Ctrl-Logoff event\n\n");
        return FALSE;

    case CTRL_SHUTDOWN_EVENT:
        Beep(750, 500);
        printf("Ctrl-Shutdown event\n\n");
        return FALSE;

    default:
        return FALSE;
    }
}
int main()
{
    SetConsoleCtrlHandler((CtrlHandler, TRUE);
    while(1)
    {
        std::cin.get();
    }
}

I guessed this could be because Windows Terminal uses Win32 windows, but this could cause compatibility issues with existing console apps.

Steps to reproduce

Run the program and try to trigger a CTRL_C_EVENT

Expected Behavior

CtrlHandler handles the event

Actual Behavior

CtrlHandler is not invoked

Originally created by @blacklightpy on GitHub (Jul 13, 2021). ### Windows Terminal version (or Windows build number) 1.9.1523.0 ### Other Software I wrote a console application in C++ and wanted to handle CTRL_CLOSE_EVENT. I set my default terminal as Windows Terminal, so the app launched in it by default. I wasn't sure why the method wasn't working and after a while I decided to try out running the program in conhost and it worked. Here's the code: ``` BOOL WINAPI CtrlHandler(DWORD fdwCtrlType) { switch (fdwCtrlType) { case CTRL_C_EVENT: printf("Ctrl-C event\n\n"); Beep(750, 300); return TRUE; case CTRL_CLOSE_EVENT: Beep(600, 200); printf("Ctrl-Close event\n\n"); return TRUE; case CTRL_BREAK_EVENT: Beep(900, 200); printf("Ctrl-Break event\n\n"); return FALSE; case CTRL_LOGOFF_EVENT: Beep(1000, 200); printf("Ctrl-Logoff event\n\n"); return FALSE; case CTRL_SHUTDOWN_EVENT: Beep(750, 500); printf("Ctrl-Shutdown event\n\n"); return FALSE; default: return FALSE; } } int main() { SetConsoleCtrlHandler((CtrlHandler, TRUE); while(1) { std::cin.get(); } } ``` I guessed this could be because Windows Terminal uses Win32 windows, but this could cause compatibility issues with existing console apps. ### Steps to reproduce Run the program and try to trigger a CTRL_C_EVENT ### Expected Behavior CtrlHandler handles the event ### Actual Behavior CtrlHandler is not invoked
claunia commented 2026-01-31 04:12:04 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jul 23, 2021):

Very high chance this is resolved with #10415

@miniksa commented on GitHub (Jul 23, 2021): Very high chance this is resolved with #10415
claunia commented 2026-01-31 04:12:04 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 23, 2021):

@blacklightpy Would you mind testing on Windows 22000.65 or higher with Windows Terminal Preview 1.10?

@DHowett commented on GitHub (Jul 23, 2021): @blacklightpy Would you mind testing on Windows 22000.65 or higher with Windows Terminal Preview 1.10?
claunia commented 2026-01-31 04:12:04 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 27, 2021):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Jul 27, 2021): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.
claunia commented 2026-01-31 04:12:05 +00:00
Author
Owner
Copy Link

@blacklightpy commented on GitHub (Jul 28, 2021):

@DHowett Sorry for the delay, I was sick for a while.
I'm now on 22000.100 and on Terminal Preview 1.10.1933.0
Still, the same result.

I noticed that I can hear a beep sound when I'm closing the window, meaning CTRL_CLOSE_EVENT is triggered.
But CTRL_C_EVENT and CTRL_BREAK_EVENT are still not triggered in the terminal. I didn't try the logoff and shutdown events.

The beep sound wasn't working the last time, but it wasn't working in conhost too then. Now it's working on both.

CTRL_CLOSE_EVENT too is working differently from what's expected. In conhost, the program exists only after the beep is performed. In Terminal however, the tab is close immediately and the beep is heard afterwards. So if there are any print statements in the control handler, they won't be seen. I tried setting 2 beeps and a print statement between them, and both beeps were still executed.

@blacklightpy commented on GitHub (Jul 28, 2021): @DHowett Sorry for the delay, I was sick for a while. I'm now on 22000.100 and on Terminal Preview 1.10.1933.0 Still, the same result. I noticed that I can hear a beep sound when I'm closing the window, meaning CTRL_CLOSE_EVENT is triggered. But CTRL_C_EVENT and CTRL_BREAK_EVENT are still not triggered in the terminal. I didn't try the logoff and shutdown events. The beep sound wasn't working the last time, but it wasn't working in conhost too then. Now it's working on both. CTRL_CLOSE_EVENT too is working differently from what's expected. In conhost, the program exists only after the beep is performed. In Terminal however, the tab is close immediately and the beep is heard afterwards. So if there are any print statements in the control handler, they won't be seen. I tried setting 2 beeps and a print statement between them, and both beeps were still executed.
claunia commented 2026-01-31 04:12:05 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Aug 12, 2021):

I'll look into this when I get a chance.

@miniksa commented on GitHub (Aug 12, 2021): I'll look into this when I get a chance.
claunia commented 2026-01-31 04:12:05 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Aug 20, 2021):

Okay. So far...

CTRL_BREAK_EVENT is coming in as a break if started within the Terminal, but as a CTRL_C if started from DefApp. So that one is DefApp related.

CTRL_CLOSE_EVENT seems to behave the same for both and makes the noise after the tab goes away. That slightly tracks with how tab handing works and we'd likely have to introduce a delay/ordering of sorts there to stop that one and is likely NOT DefApp related.

CTRL_C_EVENT just works in both.

Now trying to figure out how to do CTRL_LOGOFF_EVENT and CTRL_SHUTDOWN_EVENT as I think those are weird/difficult.

@miniksa commented on GitHub (Aug 20, 2021): Okay. So far... CTRL_BREAK_EVENT is coming in as a break if started within the Terminal, but as a CTRL_C if started from DefApp. So that one is DefApp related. CTRL_CLOSE_EVENT seems to behave the same for both and makes the noise after the tab goes away. That slightly tracks with how tab handing works and we'd likely have to introduce a delay/ordering of sorts there to stop that one and is likely NOT DefApp related. CTRL_C_EVENT just works in both. Now trying to figure out how to do CTRL_LOGOFF_EVENT and CTRL_SHUTDOWN_EVENT as I think those are weird/difficult.
claunia commented 2026-01-31 04:12:05 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Aug 20, 2021):

There's another issue with CTRL_CLOSE_EVENT related to CloseTest.exe (from our tools folder). It is not propagating to all the children...

@miniksa commented on GitHub (Aug 20, 2021): There's another issue with CTRL_CLOSE_EVENT related to CloseTest.exe (from our tools folder). It is not propagating to all the children...
claunia commented 2026-01-31 04:12:06 +00:00
Author
Owner
Copy Link

@HXXZA commented on GitHub (Oct 21, 2024):

now is 2024, Any progress on this issue? @zadjii-msft

@HXXZA commented on GitHub (Oct 21, 2024): now is 2024, Any progress on this issue? @zadjii-msft
claunia commented 2026-01-31 04:12:06 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Oct 21, 2024):

Good point. Progress seems to have been achieved and the issue can be closed now. I'm not sure what fixed it, but it definitely beeps and boops in Windows Terminal 1.20.

@lhecker commented on GitHub (Oct 21, 2024): Good point. Progress seems to have been achieved and the issue can be closed now. I'm not sure what fixed it, but it definitely beeps and boops in Windows Terminal 1.20.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-DefApp Issue-Bug Needs-Attention Needs-Tag-Fix Priority-1 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#14503
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?