Wait for clients to exit on ConPTY shutdown #14282

lhecker · 2022-10-22T23:45:05Z

#14160 didn't fix #14132 entirely. There seems to be a race condition left
where (on my system) 9 out of 10 times everything works correctly,
but sometimes OpenConsole exits, while pwsh and bash keep running.

My leading theory is that the new code is exiting OpenConsole faster than the
old code. This prevents clients from calling console APIs, etc. causing them
to get stuck. The old code (and new code) calls ExitProcess when the ConPTY
pipes break and I think this is wrong: In conhost when you close the window we
only call CloseConsoleProcessState via the WM_CLOSE event and that's it.
Solution: Remove the call to RundownAndExit for ConPTY.

During testing I found that continuously printing text inside msys2 will cause
child processes to only exit slowly one by one every 5 seconds.
This happens because CloseConsoleProcessState calls HandleCtrlEvent without
holding the console lock. This creates a race condition where most of the time
the console IO thread is the one picking up the CTRL_CLOSE_EVENT. But that's
problematic because the CTRL_CLOSE_EVENT leads to a ConsoleControl call of
type ConsoleEndTask which calls back into conhost's IO thread and
so you got the IO thread waiting on itself to respond.
Solution: Don't race conditions.

Validation Steps Performed

Enter-VsDevShell and close the tab
Everything exits after 5s ✅
Run msys2 bash from within pwsh and close the tab
Everything exits instantly ✅
Run cat bigfile.txt and close the tab
Everything exits instantly ✅
Patch conhost.exe with sfpcopy, as well as KernelBase.dll
with the recent changes to winconpty, then launch and exit
shells and applications via VS Code's terminal ✅
On the main branch without this modification remove the call to
TriggerTeardown in RundownAndExit (this speeds up the shutdown).
Run (msys2's) bash.exe --login and hold enter and then press Ctrl+Shift+W
simultaneously. The tab should close and randomly OpenConsole should exit
early while pwsh/bash keep running. Then retry this with this branch and
observe how the child processes don't stick around forever anymore. ✅

DHowett · 2022-10-24T17:59:16Z

Notes from chat on Saturday: pseudoconsole teardown should have the same effect as clicking the X in a conhost window. If that means a process takes a while to release its last console handle after it gets the CTRL_CLOSE_EVENT (or similar), at least we can make Terminal not block on it.

DHowett · 2022-10-24T17:59:57Z

Please check all prior criteria, including VSCode. :)

lhecker · 2022-10-24T22:27:04Z

Please check all prior criteria, including VSCode. :)

I think only VS Code was missing. Seems to work great. Including running bc inside VS Code, etc.

lhecker · 2022-10-26T00:53:44Z

src/host/PtySignalInputThread.cpp

+            if (!_GetData(&msg, sizeof(msg)))
+            {
+                break;
+            }


All of these were missing. _GetData returns a bool after all.

lhecker · 2022-10-26T00:56:26Z

src/host/PtySignalInputThread.cpp

    {
-        _Shutdown();
+        return false;


Now that RundownAndExit is missing, we aren't [[noreturn]] anymore and need to return something. Almost didn't catch this...

lhecker · 2022-10-26T00:56:57Z

src/host/VtInputThread.cpp

-    // If we failed to read because the terminal broke our pipe (usually due
-    //      to dying itself), close gracefully with ERROR_BROKEN_PIPE.
-    // Otherwise throw an exception. ERROR_BROKEN_PIPE is the only case that
-    //       we want to gracefully close in.


This comment is a copy/paste from PtySignalInputThread, but it doesn't actually apply to this code. Also there's only 4 uses of _exitRequested in total which makes this code easy to follow anyways IMO.

lhecker · 2022-10-26T01:09:58Z

src/host/PtySignalInputThread.cpp

-        {
-            THROW_HR(E_UNEXPECTED);
-        }
+            return S_OK;


We can't throw an exception here - no one is catching it and it would cross an ABI boundary otherwise. This is also why this function is now noexcept - it should've always been.
Should I add some logging here? If so what would be best? RETURN_HR_MSG?

You could wrap the whole function in a try block and add a CATCH_LOG_RETURN_HR(S_OK); at the end. Then just keep the default case as a THROW_HR(E_UNEXPECTED).

Looks a bit ugly, but it's true, the default: case is definitely unexpected.

lhecker · 2022-10-26T01:10:49Z

src/host/PtySignalInputThread.cpp

+        if (!_GetData(&signalId, sizeof(signalId)))
+        {
+            return S_OK;
+        }


I changed this in the end, so that the _GetData calls are all uniform and consistent. I just felt that this looks better...

lhecker · 2022-10-27T15:38:43Z

src/winconpty/ft_pty/ConPtyTests.cpp

-void ConPtyTests::DiesOnBreakBoth()
-{
-    PseudoConsole pty = { 0 };
-    wil::unique_handle outPipeOurSide;
-    wil::unique_handle inPipeOurSide;
-    wil::unique_handle outPipePseudoConsoleSide;
-    wil::unique_handle inPipePseudoConsoleSide;
-    SECURITY_ATTRIBUTES sa;
-    sa.nLength = sizeof(sa);
-    sa.bInheritHandle = TRUE;
-    sa.lpSecurityDescriptor = nullptr;
-    VERIFY_IS_TRUE(CreatePipe(inPipePseudoConsoleSide.addressof(), inPipeOurSide.addressof(), &sa, 0));
-    VERIFY_IS_TRUE(CreatePipe(outPipeOurSide.addressof(), outPipePseudoConsoleSide.addressof(), &sa, 0));
-    VERIFY_IS_TRUE(SetHandleInformation(inPipeOurSide.get(), HANDLE_FLAG_INHERIT, 0));
-    VERIFY_IS_TRUE(SetHandleInformation(outPipeOurSide.get(), HANDLE_FLAG_INHERIT, 0));
-
-    VERIFY_SUCCEEDED(
-        _CreatePseudoConsole(defaultSize,
-                             inPipePseudoConsoleSide.get(),
-                             outPipePseudoConsoleSide.get(),
-                             0,
-                             &pty));
-    auto closePty1 = wil::scope_exit([&] {
-        _ClosePseudoConsoleMembers(&pty, TRUE);
-    });
-
-    DWORD dwExit;
-    VERIFY_IS_TRUE(GetExitCodeProcess(pty.hConPtyProcess, &dwExit));
-    VERIFY_ARE_EQUAL(dwExit, (DWORD)STILL_ACTIVE);
-
-    wil::unique_process_information piClient;
-    std::wstring realCommand = L"cmd.exe";
-    VERIFY_SUCCEEDED(AttachPseudoConsole(&pty, realCommand, piClient.addressof()));
-
-    VERIFY_IS_TRUE(GetExitCodeProcess(piClient.hProcess, &dwExit));
-    VERIFY_ARE_EQUAL(dwExit, (DWORD)STILL_ACTIVE);
-
-    // Close one of the pipes...
-    VERIFY_IS_TRUE(CloseHandle(outPipeOurSide.get()));
-
-    // ... Wait for a couple seconds, make sure the child is still alive.
-    VERIFY_ARE_EQUAL(WaitForSingleObject(pty.hConPtyProcess, 2000), (DWORD)WAIT_TIMEOUT);
-    VERIFY_IS_TRUE(GetExitCodeProcess(pty.hConPtyProcess, &dwExit));
-    VERIFY_ARE_EQUAL(dwExit, (DWORD)STILL_ACTIVE);
-
-    // Tricky - write some input to the pcon. We need to do this so conhost can
-    //      realize that the output pipe has broken.
-    VERIFY_SUCCEEDED(WriteFile(inPipeOurSide.get(), L"a", sizeof(wchar_t), nullptr, nullptr));
-
-    // Close the other pipe, and make sure conhost dies
-    VERIFY_IS_TRUE(CloseHandle(inPipeOurSide.get()));
-
-    VERIFY_ARE_EQUAL(WaitForSingleObject(pty.hConPtyProcess, 10000), (DWORD)WAIT_OBJECT_0);
-    VERIFY_IS_TRUE(GetExitCodeProcess(pty.hConPtyProcess, &dwExit));
-    VERIFY_ARE_NOT_EQUAL(dwExit, (DWORD)STILL_ACTIVE);
-}
-


This test doesn't work anymore because now conhost will keep running unless all clients have disconnected. But winconpty holds a console client handle inside hPtyReference and it's only closed once you call ClosePseudoConsole. This is already being tracked in the DiesOnClose() test.

lhecker · 2022-10-27T23:17:19Z

src/host/output.cpp

+    LockConsole();
+    const auto unlock = wil::scope_exit([] { UnlockConsole(); });


To quote myself from the PR:

During testing I found that continuously printing text inside msys2 will cause child processes to only exit slowly one by one every 5 seconds.
This happens because CloseConsoleProcessState calls HandleCtrlEvent without holding the console lock. This creates a race condition where most of the time the console IO thread is the one picking up the CTRL_CLOSE_EVENT. But that's problematic because the CTRL_CLOSE_EVENT leads to a ConsoleControl call of type ConsoleEndTask which calls back into conhost's IO thread and so you got the IO thread waiting on itself to respond.
Solution: Don't race conditions.

So wait, calling RundownAndExit is safe to do while holding the console lock? Isn't it another recipe for a deadlock?

I don't think it's safe at all, but the conhost code did exactly that. Window::ConsoleWindowProc acquires the console lock and then calls Window::_CloseWindow which calls CloseConsoleProcessState which potentially calls ServiceLocator::RundownAndExit.
In the past without ConPTY RundownAndExit was trivial since it only did ProcessExit but now with the render flush it has been a disaster recipe for quite a while unfortunately...

src/interactivity/base/ServiceLocator.cpp

DHowett · 2022-10-31T22:15:35Z

src/host/output.cpp

-    //      ctrl event will never actually get dispatched.
-    // So, lock and unlock here, to make sure the ctrl event gets handled.
-    LockConsole();
-    UnlockConsole();


okay just so I understand... the Unlock happening after the scope_exit will have the same effect of making sure the CTRL event gets handled? Can you look up the repro for MSFT-19419231?

DHowett

I think I have to trust this. We've gotten it wrong a number of times, but this must be better?

…tdown-deadlock-part2

carlos-zamora

The changes to each file make sense to me. Full disclosure, I don't get how the functions flow into each other though (like, the overall code flow). If you feel uncomfortable with that, definitely have @zadjii-msft take a look, I won't mind 😊.

Changes look good though and I agree it's an improvement. I added a few comments to add more logging, but that's up to you if you want to follow them.

src/host/PtySignalInputThread.cpp

src/host/PtySignalInputThread.hpp

carlos-zamora · 2022-11-11T21:47:09Z

src/host/PtySignalInputThread.cpp

-        {
-            THROW_HR(E_UNEXPECTED);
-        }
+            return S_OK;


You could wrap the whole function in a try block and add a CATCH_LOG_RETURN_HR(S_OK); at the end. Then just keep the default case as a THROW_HR(E_UNEXPECTED).

Looks a bit ugly, but it's true, the default: case is definitely unexpected.

…tdown-deadlock-part2

DHowett

aaa

lhecker · 2022-11-19T03:08:53Z

With @DHowett supplying me with a patched KernelBase.dll that includes the most recent winconpty changes to ClosePseudoConsole this PR has now underwent quite some testing rounds inside a Windows 11 VM.

The most recent commits contain a fix (fb14982) that caused Ctrl+C to not work in VS Code. This happened because CloseConsoleProcessState() now holds the console lock while calling RundownAndExit. That's problematic, because when RundownAndExit calls TriggerTeardown() on the Renderer it expects it to render the last frame of VT output on another thread, but it can't do that if the RundownAndExit thread is currently holding the console lock.

Furthermore I found a bug in WSL's usage of the pseudoconsole API, which can't be easily patched on our side and is also reproducible on vanilla conhost/kernelbase build 25247:

Run wsl inside conhost.
Inside that run any Windows CLI application that prints 100MB or more of text in a single WriteFile(stdout) call. conhost will take multiple seconds to process that amount of data.
While it prints the text, close the conhost window.
--> both the Windows CLI application and the pseudoconsole conhost that WSL has spawned will deadlock until wsl shuts down.

From what I can tell, WSL is neither reading from, nor closing the output pipe conhost is writing VT/text to, while being stuck waiting on ClosePseudoConsole. ClosePseudoConsole won't ever return because it's waiting on conhost which is waiting to write into the output pipe that isn't being read from. This deadlock can only reliably be resolved on WSL's side, because while we could add timeouts to our writes, they'd be just a worst-case fallback if anything and the issue would still fundamentally exist. The ClosePseudoConsole API documentation mentions this as a requirement in the remarks section ("Failure to drain the buffer may cause the Close call to wait indefinitely until it is drained or the communication channels are broken another way.") and I think WSL already tries to do this correctly, so this is probably just a minor bug that is hopefully easy to fix.

…tdown-deadlock-part2

DHowett · 2022-11-29T19:26:28Z

src/winconpty/winconpty.cpp

@@ -230,6 +230,8 @@ HRESULT _CreatePseudoConsole(const HANDLE hToken,
    pPty->hConPtyProcess = pi.hProcess;
    pi.hProcess = nullptr;

+    // The hPtyReference we create here is used when the PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE attribute is processed.


did we ever solve the issue where conpty looks like a client to conhost?

ghost · 2022-11-29T20:02:47Z

Hello @lhecker!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

where (on my system) 9 out of 10 times everything works correctly, but sometimes OpenConsole exits, while pwsh and bash keep running. My leading theory is that the new code is exiting OpenConsole faster than the old code. This prevents clients from calling console APIs, etc. causing them to get stuck. The old code (and new code) calls `ExitProcess` when the ConPTY pipes break and I think this is wrong: In conhost when you close the window we only call `CloseConsoleProcessState` via the `WM_CLOSE` event and that's it. Solution: Remove the call to `RundownAndExit` for ConPTY. During testing I found that continuously printing text inside msys2 will cause child processes to only exit slowly one by one every 5 seconds. This happens because `CloseConsoleProcessState` calls `HandleCtrlEvent` without holding the console lock. This creates a race condition where most of the time the console IO thread is the one picking up the `CTRL_CLOSE_EVENT`. But that's problematic because the `CTRL_CLOSE_EVENT` leads to a `ConsoleControl` call of type `ConsoleEndTask` which calls back into conhost's IO thread and so you got the IO thread waiting on itself to respond. Solution: Don't race conditions. * `Enter-VsDevShell` and close the tab Everything exits after 5s ✅ * Run msys2 bash from within pwsh and close the tab Everything exits instantly ✅ * Run `cat bigfile.txt` and close the tab Everything exits instantly ✅ * Patch `conhost.exe` with `sfpcopy`, as well as `KernelBase.dll` with the recent changes to `winconpty`, then launch and exit shells and applications via VS Code's terminal ✅ * On the main branch without this modification remove the call to `TriggerTeardown` in `RundownAndExit` (this speeds up the shutdown). Run (msys2's) `bash.exe --login` and hold enter and then press Ctrl+Shift+W simultaneously. The tab should close and randomly OpenConsole should exit early while pwsh/bash keep running. Then retry this with this branch and observe how the child processes don't stick around forever anymore. ✅

where (on my system) 9 out of 10 times everything works correctly, but sometimes OpenConsole exits, while pwsh and bash keep running. My leading theory is that the new code is exiting OpenConsole faster than the old code. This prevents clients from calling console APIs, etc. causing them to get stuck. The old code (and new code) calls `ExitProcess` when the ConPTY pipes break and I think this is wrong: In conhost when you close the window we only call `CloseConsoleProcessState` via the `WM_CLOSE` event and that's it. Solution: Remove the call to `RundownAndExit` for ConPTY. During testing I found that continuously printing text inside msys2 will cause child processes to only exit slowly one by one every 5 seconds. This happens because `CloseConsoleProcessState` calls `HandleCtrlEvent` without holding the console lock. This creates a race condition where most of the time the console IO thread is the one picking up the `CTRL_CLOSE_EVENT`. But that's problematic because the `CTRL_CLOSE_EVENT` leads to a `ConsoleControl` call of type `ConsoleEndTask` which calls back into conhost's IO thread and so you got the IO thread waiting on itself to respond. Solution: Don't race conditions. * `Enter-VsDevShell` and close the tab Everything exits after 5s ✅ * Run msys2 bash from within pwsh and close the tab Everything exits instantly ✅ * Run `cat bigfile.txt` and close the tab Everything exits instantly ✅ * Patch `conhost.exe` with `sfpcopy`, as well as `KernelBase.dll` with the recent changes to `winconpty`, then launch and exit shells and applications via VS Code's terminal ✅ * On the main branch without this modification remove the call to `TriggerTeardown` in `RundownAndExit` (this speeds up the shutdown). Run (msys2's) `bash.exe --login` and hold enter and then press Ctrl+Shift+W simultaneously. The tab should close and randomly OpenConsole should exit early while pwsh/bash keep running. Then retry this with this branch and observe how the child processes don't stick around forever anymore. ✅ (cherry picked from commit b6b1ff8)

#14160 didn't fix #14132 entirely. There seems to be a race condition left where (on my system) 9 out of 10 times everything works correctly, but sometimes OpenConsole exits, while pwsh and bash keep running. My leading theory is that the new code is exiting OpenConsole faster than the old code. This prevents clients from calling console APIs, etc. causing them to get stuck. The old code (and new code) calls `ExitProcess` when the ConPTY pipes break and I think this is wrong: In conhost when you close the window we only call `CloseConsoleProcessState` via the `WM_CLOSE` event and that's it. Solution: Remove the call to `RundownAndExit` for ConPTY. During testing I found that continuously printing text inside msys2 will cause child processes to only exit slowly one by one every 5 seconds. This happens because `CloseConsoleProcessState` calls `HandleCtrlEvent` without holding the console lock. This creates a race condition where most of the time the console IO thread is the one picking up the `CTRL_CLOSE_EVENT`. But that's problematic because the `CTRL_CLOSE_EVENT` leads to a `ConsoleControl` call of type `ConsoleEndTask` which calls back into conhost's IO thread and so you got the IO thread waiting on itself to respond. Solution: Don't race conditions. ## Validation Steps Performed * `Enter-VsDevShell` and close the tab Everything exits after 5s ✅ * Run msys2 bash from within pwsh and close the tab Everything exits instantly ✅ * Run `cat bigfile.txt` and close the tab Everything exits instantly ✅ * Patch `conhost.exe` with `sfpcopy`, as well as `KernelBase.dll` with the recent changes to `winconpty`, then launch and exit shells and applications via VS Code's terminal ✅ * On the main branch without this modification remove the call to `TriggerTeardown` in `RundownAndExit` (this speeds up the shutdown). Run (msys2's) `bash.exe --login` and hold enter and then press Ctrl+Shift+W simultaneously. The tab should close and randomly OpenConsole should exit early while pwsh/bash keep running. Then retry this with this branch and observe how the child processes don't stick around forever anymore. ✅ (cherry picked from commit b6b1ff8) Service-Card-Id: 87207831 Service-Version: 1.15

#14160 didn't fix #14132 entirely. There seems to be a race condition left where (on my system) 9 out of 10 times everything works correctly, but sometimes OpenConsole exits, while pwsh and bash keep running. My leading theory is that the new code is exiting OpenConsole faster than the old code. This prevents clients from calling console APIs, etc. causing them to get stuck. The old code (and new code) calls `ExitProcess` when the ConPTY pipes break and I think this is wrong: In conhost when you close the window we only call `CloseConsoleProcessState` via the `WM_CLOSE` event and that's it. Solution: Remove the call to `RundownAndExit` for ConPTY. During testing I found that continuously printing text inside msys2 will cause child processes to only exit slowly one by one every 5 seconds. This happens because `CloseConsoleProcessState` calls `HandleCtrlEvent` without holding the console lock. This creates a race condition where most of the time the console IO thread is the one picking up the `CTRL_CLOSE_EVENT`. But that's problematic because the `CTRL_CLOSE_EVENT` leads to a `ConsoleControl` call of type `ConsoleEndTask` which calls back into conhost's IO thread and so you got the IO thread waiting on itself to respond. Solution: Don't race conditions. ## Validation Steps Performed * `Enter-VsDevShell` and close the tab Everything exits after 5s ✅ * Run msys2 bash from within pwsh and close the tab Everything exits instantly ✅ * Run `cat bigfile.txt` and close the tab Everything exits instantly ✅ * Patch `conhost.exe` with `sfpcopy`, as well as `KernelBase.dll` with the recent changes to `winconpty`, then launch and exit shells and applications via VS Code's terminal ✅ * On the main branch without this modification remove the call to `TriggerTeardown` in `RundownAndExit` (this speeds up the shutdown). Run (msys2's) `bash.exe --login` and hold enter and then press Ctrl+Shift+W simultaneously. The tab should close and randomly OpenConsole should exit early while pwsh/bash keep running. Then retry this with this branch and observe how the child processes don't stick around forever anymore. ✅ (cherry picked from commit b6b1ff8) Service-Card-Id: 87207832 Service-Version: 1.16

ghost · 2022-12-14T20:42:21Z

🎉Windows Terminal v1.15.3465.0 and v1.15.3466.0 has been released which incorporates this pull request.:tada:

Handy links:

ghost · 2022-12-14T20:44:34Z

🎉Windows Terminal Preview v1.16.3463.0 and v1.16.3464.0 has been released which incorporates this pull request.:tada:

Handy links:

2 new ConPTY APIs were added as part of this commit: * `ClosePseudoConsoleTimeout` Complements `ClosePseudoConsole`, allowing users to override the `INFINITE` wait for OpenConsole to exit with any arbitrary timeout, including 0. * `ConptyReleasePseudoConsole` This releases the `\Reference` handle held by the `HPCON`. While it makes launching further PTY clients via `PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE` impossible, it does allow conhost/OpenConsole to exit naturally once all console clients have disconnected. This makes it unnecessary to having to monitor the exit of the spawned shell/application, just to then call `ClosePseudoConsole`, while carefully continuing to read from the output pipe. Instead users can now just read from the output pipe until it is closed, knowing for sure that no more data will come or clients connect. This is especially useful in combination with `ClosePseudoConsoleTimeout` and a timeout of 0, to allow conhost/OpenConsole to exit asynchronously. These new APIs are used to fix an array of bugs around Windows Terminal exiting either too early or too late. They also make usage of the ConPTY API simpler in most situations (when spawning a single application and waiting for it to exit). Depends on #13882, #14041, #14160, #14282 Closes #4564 Closes #14416 Closes MSFT-42244182 ## Validation Steps Performed * Calling `FreeConsole` in a handoff'd application closes the tab ✅ * Create a .bat file containing only `start /B cmd.exe`. If WT stable is the default terminal the tab closes instantly ✅ With these changes included the tab stays open with a cmd.exe prompt ✅ * New ConPTY tests ✅

Wait for clients to exit on ConPTY shutdown

8bccc33

lhecker marked this pull request as ready for review October 24, 2022 15:03

carlos-zamora added a commit that referenced this pull request Oct 25, 2022

PRE-MERGE #14282 Wait for clients to exit on ConPTY shutdown

8ad1acc

lhecker commented Oct 26, 2022

View reviewed changes

Fix code that used to rely on [[noreturn]], Fix hPtyReference

6f177cf

lhecker force-pushed the dev/lhecker/14132-shutdown-deadlock-part2 branch from 6c09273 to 6f177cf Compare October 27, 2022 15:36

lhecker commented Oct 27, 2022

View reviewed changes

lhecker added 3 commits October 27, 2022 17:45

Fix build

a7db7a9

Fix typo

688a587

Fix another deadlock on shutdown

d693df4

lhecker commented Oct 27, 2022

View reviewed changes

src/interactivity/base/ServiceLocator.cpp Outdated Show resolved Hide resolved

DHowett reviewed Oct 31, 2022

View reviewed changes

DHowett approved these changes Oct 31, 2022

View reviewed changes

DHowett added the Needs-Second It's a PR that needs another sign-off label Oct 31, 2022

Merge remote-tracking branch 'origin/main' into dev/lhecker/14132-shu…

f5f22ff

…tdown-deadlock-part2

DHowett mentioned this pull request Nov 9, 2022

Pane history not being saved (GitBash) #11697

Open

carlos-zamora approved these changes Nov 11, 2022

View reviewed changes

Merge remote-tracking branch 'origin/main' into dev/lhecker/14132-shu…

f24689f

…tdown-deadlock-part2

DHowett requested changes Nov 14, 2022

View reviewed changes

ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Nov 14, 2022

ghost requested a review from PankajBhojwani November 14, 2022 22:21

lhecker added 4 commits November 15, 2022 01:34

Fix build failure

0a1da70

Dustin found a bug!

fb14982

Improve documentation

2644816

Improve documentation

a0d0e68

Merge remote-tracking branch 'origin/main' into dev/lhecker/14132-shu…

4c2da9e

…tdown-deadlock-part2

lhecker force-pushed the dev/lhecker/14132-shutdown-deadlock-part2 branch from 64eb22f to 4c2da9e Compare November 29, 2022 19:18

DHowett reviewed Nov 29, 2022

View reviewed changes

DHowett approved these changes Nov 29, 2022

View reviewed changes

lhecker added the AutoMerge Marked for automatic merge by the bot when requirements are met label Nov 29, 2022

lhecker merged commit b6b1ff8 into main Nov 29, 2022

lhecker deleted the dev/lhecker/14132-shutdown-deadlock-part2 branch November 29, 2022 20:15

lhecker mentioned this pull request Dec 1, 2022

Reported hang when minimized during a razzle build #14134

Closed

Tyriar mentioned this pull request Dec 2, 2022

Some shells don't remember history microsoft/vscode#151105

Open

This was referenced Dec 13, 2022

Program does not stop when windows terminal is closed. #13586

Closed

Add support for start /B and FreeConsole #14544

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Wait for clients to exit on ConPTY shutdown #14282

Wait for clients to exit on ConPTY shutdown #14282

lhecker commented Oct 22, 2022 •

edited

Loading

DHowett commented Oct 24, 2022

DHowett commented Oct 24, 2022

lhecker commented Oct 24, 2022 •

edited

Loading

lhecker Oct 26, 2022

lhecker Oct 26, 2022 •

edited

Loading

lhecker Oct 26, 2022

lhecker Oct 26, 2022 •

edited

Loading

carlos-zamora Nov 11, 2022

lhecker Oct 26, 2022

lhecker Oct 27, 2022 •

edited

Loading

lhecker Oct 27, 2022 •

edited

Loading

DHowett Oct 28, 2022

lhecker Oct 28, 2022 •

edited

Loading

DHowett Oct 31, 2022

DHowett left a comment

carlos-zamora left a comment

carlos-zamora Nov 11, 2022

DHowett left a comment

lhecker commented Nov 19, 2022 •

edited

Loading

DHowett Nov 29, 2022

ghost commented Nov 29, 2022

ghost commented Dec 14, 2022

ghost commented Dec 14, 2022

		LockConsole();
		const auto unlock = wil::scope_exit([] { UnlockConsole(); });

Wait for clients to exit on ConPTY shutdown #14282

Wait for clients to exit on ConPTY shutdown #14282

Conversation

lhecker commented Oct 22, 2022 • edited Loading

Validation Steps Performed

DHowett commented Oct 24, 2022

DHowett commented Oct 24, 2022

lhecker commented Oct 24, 2022 • edited Loading

Choose a reason for hiding this comment

lhecker Oct 26, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lhecker Oct 26, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lhecker Oct 27, 2022 • edited Loading

Choose a reason for hiding this comment

lhecker Oct 27, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lhecker Oct 28, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DHowett left a comment

Choose a reason for hiding this comment

carlos-zamora left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DHowett left a comment

Choose a reason for hiding this comment

lhecker commented Nov 19, 2022 • edited Loading

Choose a reason for hiding this comment

ghost commented Nov 29, 2022

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

ghost commented Dec 14, 2022

ghost commented Dec 14, 2022

lhecker commented Oct 22, 2022 •

edited

Loading

lhecker commented Oct 24, 2022 •

edited

Loading

lhecker Oct 26, 2022 •

edited

Loading

lhecker Oct 26, 2022 •

edited

Loading

lhecker Oct 27, 2022 •

edited

Loading

lhecker Oct 27, 2022 •

edited

Loading

lhecker Oct 28, 2022 •

edited

Loading

lhecker commented Nov 19, 2022 •

edited

Loading

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.