Conemu: ctrl-c not working in powershell windows 10 15007 on latest conemu

[yuvalk]

ConEmu build: Tested with both 161206 and 170118. 64bit
OS version: Windows Problem started with Windows Insider build 15002 and exists in current 15007. (64bit)
Used shell version (Far Manager, git-bash, cmd, powershell, cygwin, whatever): powershell

Problem description

Run a powershell program that uses ctrl-c to break (dotnet run in my case)
ConEmu does not break. Requires a "Kill Active Process" to exit
Running in native powershell ctrl-c breaks correctly.

[Maximus5]

Please read what you posted.
Third-party application problems

[yuvalk]

The problem is with ConEMU.
When using power-shell outside ConEMU - ctrl-c works just fine.
this is not a third party issue.

[Maximus5]

Please read what you posted.
The issue (first message) contains rubbish.
Please edit it.
Bad Issues

[nwykes]

I'm experiencing this issue as well. I can either add full details in the comments here or create a new bug.

Short version:

Tested with both 161206 and 170118.
Problem started with Windows Insider build 15002 and exists in current 15007.
Run a powershell program that uses ctrl-c to break (dotnet run in my case)
ConEmu does not break. Requires a "Kill Active Process" to exit
Running in native powershell ctrl-c breaks correctly.

[yuvalk]

I'll edit that in

[Maximus5]

Does Ctrl+C work if you run the following?

ConEmu64.exe -basic -run {cmd}

[nwykes]

ConEmu64.exe -basic -run dotnet run

Ctrl-C does not break.

[Maximus5]

I didn't ask that.
https://github.com/Maximus5/ConEmu/issues/1018#issuecomment-273846370

[nwykes]

Sorry, I didn't think this is what was expected:

[Maximus5]

1. Press Win+R
2. Type ConEmu64.exe -basic -run {cmd}
3. Than try Ctrl+C
4. Report the result

[nwykes]

OK, I understand now.

Ctrl+C still does not break.

[Maximus5]

@miniksa Can you check this? Seems like conhost window doesn't process WM_KEYDOWN message anymore? I don't know other way to emulate Ctrl+C.

[miniksa]

There have been a lot of Ctrl+C bugs in the console lately. We've been fixing them, but our feature branch is unfortunately a few weeks ahead of the code in the insiders branch. @Maximus5, you shouldn't spend too much of your time debugging/working around problems in 15002 or 15007. There's lots of known issues we fixed and are making their way up.

[nwykes]

Thanks for the info @miniksa.

ctrl-alt-break works as a workaround for now.

[yuvalk]

wow, that's workaround a real life saver!

[miniksa]

In before someone reports this is still broken in 15014.....
The fix for WM_KEYDOWN problems in general is still a few weeks away.

@Maximus5, can you tell me exactly how you are emulating Ctrl+C WM_KEYDOWN (like the exact SendMessage/PostMessage structs you're giving us)? I want to stick your use case into our test pass if it's different from what's already in there.

[mcquiggd]

@miniksa , @Maximus5

Really pleased to see this is being actively worked on - thanks for all the effort.

I am in the same position as @nwykes - using Microsoft's dotnet CLI. It uses ctrl-c to stop the default web server.

ConEmu has a third party integration with Visual Studio, which is used by millions of developers... the ability to support sending ctrl-c to the wrapped cmd would, IMHO, be exceptionally useful for many people.

As it also supports macros, it's ideal for development on windows, in Microsoft's 'next big thing'.

If I use Menu> Debug > Real Console, then ctrl-c functions normally and the ConEmu window correctly reflects the state of the underlying console. Might be another workaround for some... perhaps I can add that as a macro to do that for now.. Keys should work but not sure how to send that to a specific child window.

More than happy to alpha / beta test, just ask. I have a variety of environments that I can test on...

[Maximus5]

@miniksa I just post C key supposing the Ctrl is pressed at the moment.

~
SendMessage(ghConWnd, WM_KEYDOWN, r.Event.KeyEvent.wVirtualKeyCode /it's 'C' or 67/, 0);
~

It worked previously on all Windows versions. However, some users reported this method has large lags in some undefined cases.

Yep, this method looks like a dirty hack - it's asynhronous and uses assumptions.
But GenerateConsoleCtrlEvent(0,0) just does not work as expected. It may terminates ping for example (same as Ctrl+C), but it does not break ReadConsole function which cmd.exe uses for prompt reading.

Actually, it would be much better, if GenerateConsoleCtrlEvent(0,0) behave the same as real Ctrl+C keypress, than ConEmu will use official way to post break events.

[Maximus5]

Is there a way to install fresh insider build? Have tried three times to update clean installation from 14393 to 15014.
It just hangs after rebooting, and if I reset the PC, 14393 is back.

[yuvalk]

try to use the upgrade troubleshooter:
https://support.microsoft.com/en-us/instantanswers/512a5183-ffab-40c5-8a68-021e32467565/windows-update-troubleshooter

it fixed similar issue for me..

[mcquiggd]

I had a same problem on two machines, one 15002, the other 15007... and each time it failed, it would redownload the whole update again - at least a dozen times on each machine. I tried all sorts of tricks, uninstalling video drivers, updating drivers etc, fixing Windows Update...

Reading the hundreds of comments online, sacrificing a chicken while praying to Bill Gates has been found to help, and also turning off 'Give me updates for other Microsoft products when I update windows' (this one did actually help me during the upgrade to 15002 - which turned out to be a complete mess and Microsoft rushed out 15007 the same week)).

Eventually I changed my update settings to be turn off 'Updates from more than one place', under Updates > Advanced Options > Choose How Updates are delivered.

Worked on both machines (one a laptop, one a desktop).

Personally having finally got 15014 I have now paused updates. I can wait for something stable.

[miniksa]

I also have to sacrifice a goat to make Windows Update work properly on my machine sometimes. :P If you can get the Windows Insiders ISO, sometimes it's easier to clean install or upgrade install with that using the setup.exe on the disc image.

@Maximus5, using SendMessage should be fine for the majority case. If it always used to work, we should make an effort to keep it working. We're writing tests right now to simulate various SendMessage keys like that anyway, I'll make sure your case is in there as well. The lag might have something to do with the miserable locking mechanism inside the console, but there's not a ton I can do about that anytime soon. Re-working the locks to be more reliable is on my backlog but keeps getting out-prioritized by other stuff.

Regarding GenerateConsoleCtrlEvent, I agree it probably should act the same as pressing it on the keyboard. I'm not sure whether it's intentional or a mistake that the API doesn't release the ReadConsole wait handles. I'm also not sure whether fixing it will cause a compatibility nightmare elsewhere with someone who now relies on the existing behavior. :( I'd have to think about it and dig in a bit. I doubt it is a problem, but I've said that about other things in the past and they bit me later. :P I filed MSFT:10626321 to my backlog to make sure that I think about it at some point in the future.

[Maximus5]

@miniksa Sure, backward compatibility is a hell... Perhaps new flag (e.g. 0x10000) in dwCtrlEvent to break ReadConsole would be a good solution.

[fluffynuts]

Just a heads-up: problem persists in 15014. Ctrl-Alt-Break doesn't seem to do anything for me (perhaps my keybindings are non-standard?), but I can bind Ctrl-C to kill active process, so that works -- though I'd really like an option to not have to confirm the kill. I'm willing to test any unreleased attempt to work around, if it will help.

[Maximus5]

Ctrl-C never asked confirmation to break the process.
So, ConEmu's internal kill process would not as confirmation too.
The idea of the kill it to do kill ASAP to minimize the harm running process may do. Moreover, if the running process voraciously uses CPU or HDD, the confirmation dialog may appear after long delay and the kill would not have any effect.

[fluffynuts]

And yet, it does:

(and it would, at least for me, be far more convenient if it did what you describe, that is to not confirm, as per my original comment)

[nwykes]

The menu item Active Console => Close or kill => Kill active process gives that popup, at least for me when trying to break out of something like a dotnet run. Seems like the default mapping for that is Ctrl-Alt-Break. So if you remap it to Ctrl-C, I'd expect to see the popup as well.

[fluffynuts]

And the other fly in this workaround's ointment is that you can't use ctrl-c to clear the current command that you haven't started yet (which I often do because I'm lazy) -- because then ConEmu offers to kill cmd.exe for you )': Which makes sense, but makes me a sadder panda.

[Maximus5]

@fluffynuts

And yet, it does

You showed screenshot of the "Kill active process". It shows confirmation as expected. The reason is very simple - there is no way to determine active process, ConEmu uses some AI and assumptions to detect it, therefore user have to confirm these assumptions.

I talked about "Terminate (kill) all but shell processes" which proceeds immediately without confirmation.

[fluffynuts]

You're right -- I have bound Ctrl-C to "kill active process". So imagine my delight when you mention the other command, which still has the default binding Win+Shift+Delete... and does quickly kill the current process without confirmation (as you say) -- but also offers to kill cmd.exe if there is no process running (which makes sense because it's a kill command). It's still a not-great workaround. I guess just need to have the patience for you guys to work out how to forward on Ctrl-C properly with the "new", "improved" Win10. Good luck with that :/

[warrenfalk]

While we're all talking about using "Kill active process" as a workaround, I want to remind that it is not the same as "Ctrl+C". Kill works if all you need to do is make the process die, but Ctrl+C gives active processes an opportunity to do a clean shutdown, whereas kill just yanks the rug out from underneath it. This difference affects me a lot because the processes I'm running have to run a recovery on startup if they don't shut down cleanly.

[iantribble]

Thanks for working on this guys. I have a similar issue in that since a recent Windows 10 preview upgrade, ctrl-c doesn't seem to work in a cmd windows when using conemu.

E.g. "ping 1.2.3.4 -t" should keep going unless it receives a ctrl-c but since the upgrade, to stop it i have to close the console. Ctrl-Alt-Break doesn't help in this case.

I'm currently using ConEmu 170118 on Windows 10 Preview Build 1501.

[mainnika]

Some problem.
Ctrl-C works fine in «Bash on Windows», but does nothing in native Powershell or Cmd.

[KayLeung]

Another temp workaround is to enable Clink. But your Alias may not work anymore: https://github.com/mridgers/clink/issues/431

No idea how Clink bind the key behind.

[igorkuzuro]

Looks like with Windows 10 Insider Preview Build 15031 problem is gone.

[yuvalk]

great news, will check later,
but am closing this issue, as it is not a ConEmu issue anyhow

TNX everyone!

[daguej]

Can confirm working.

[7100SW]

Yes, problem is gone. I am running the latest W10 build.