2bd5791feb
Persist inbox conhost; delegate control activities to it via a pipe ## PR Checklist * [x] Closes #10194 - WSL Debug Tap doesn't work * [x] Closes #10134 - WSL Parameter is Incorrect * [x] Closes #10413 - Ctrl+C not passed to client * [x] Closes #10414 - Leftover processes on abrupt termination * [x] Might help #10251 - Win+X Powershell sometimes fails to attach * [x] I work here * [x] Manually tested with assorted launch scenarios ## Detailed Description of the Pull Request / Additional comments It turns out that there's a bit of ownership that goes on with the original inbox `conhost.exe` and the operating system/driver. The PID of that original `conhost.exe` is stowed when the initial connection is established and it is verified for several activities. This means that the plan of letting it go completely away and having the `OpenConsole.exe` take over all of its activities must be slightly revised. I have tested the following two alternatives to keeping `conhost.exe` around and they do not work: 1. Replacing the original owner `conhost.exe` with `OpenConsole.exe` - A.) The driver does not allow this. Once the owner is registered, it cannot be replaced. B.) There's no way of updating this information inside the client process space and it is kept there too in the `kernelbase`/`conclnt` data from its initial connection. 2. Attempting to pick up the first packet (to determine headed/headless and other initial connection information that we use to determine whether handoff is appropriate or not) prior to registering any owner at all. - The driver doesn't allow this either. The owner must be registered prior to a packet coming through. Put this mental model in your head: CMD --> Conhost (inbox) --> OpenConsole (WT Package) --> Terminal (WT Package) So since the `conhost.exe` needs to stick around, here's what I'm doing in this PR: - `conhost.exe` in the OS will receive back the `OpenConsole.exe` process handle on a successful handoff and is expected to remain alive until the `OpenConsole.exe` exits. It's now waiting on that before it terminates itself. - `conhost.exe` in the OS will establish a signal channel pipe and listen for control commands from `OpenConsole.exe` in a very similar fashion to how the `ConPTY` signal pipe operates between the Terminal and the PTY (provided by `OpenConsole.exe` in this particular example.) When `OpenConsole.exe` needs to do something that would be verified by the OS and rejected... it will instead signal the original `conhost.exe` to do that thing and it will go through. - `conhost.exe` will give its own handle through to `OpenConsole.exe` so it can monitor its lifetime and cleanup. If the owner is gone, the session should end. - Assorted handle cleanup that was leading to improper exits. I was confused between `.reset()` and `.release()` for some of the `wil::unique_any<T>` handling and it lead to leaked handles. The leaked handles meant that threads weren't aware of the other sides collapsing and wouldn't cleanup/terminate appropriately. How does this fix things? - For the WSL cases... WSL was specifically looking up the owner PID of the console session from the driver. That was the `conhost.exe` PID. If it exits, that PID isn't valid and is recycled. Thus the parameter is incorrect or other inappropriate WSL setup behaviors. - Ctrl+C not passed... this is a signal the operating system rejects from a PID that is not the owner. This is now relayed through the original owner and it works. - Leftover processes... I believe I explained this was both not-enough-monitoring of each others' process lifetimes coupled with mishandling of release/resetting handles and leaking them. - Powershell sometimes fails to attach... my theory on this one is that it's a race that became upset when the `conhost.exe` disappeared while something about Powershell/.NET was still starting, much like the WSL one. I believe now that it is sticking around, it will be fine. Also, this WILL require an OS update to complete improvement of functionality and I have revised the interface ID. This is considered an acceptable breaking change with no mitigation because we said this feature was an alpha preview. ## Validation Steps Performed - Launched WSL with defapp set, it works - Launched WSL with defapp set and the debug tap on, it works and opens in two tabs - Launched CMD, ran ping, did Ctrl+C, it now receives it - Launched Win+X powershell a ton of times. It seems fine now - Launched cmd, powershell, wsl, etc. Killed assorted processes in the chain (client/conhost/openconsole/windowsterminal) and observed in Process Explorer (with a long delta timer so I could see it) that they all successfully tear down now without leftovers.
81 lines
3.8 KiB
C++
81 lines
3.8 KiB
C++
// Copyright (c) Microsoft Corporation.
|
|
// Licensed under the MIT license.
|
|
|
|
#include "precomp.h"
|
|
|
|
#include "CConsoleHandoff.h"
|
|
|
|
#include "srvinit.h"
|
|
|
|
// Routine Description:
|
|
// - Helper to duplicate a handle to ourselves so we can keep holding onto it
|
|
// after the caller frees the original one.
|
|
// Arguments:
|
|
// - in - Handle to duplicate
|
|
// - out - Where to place the duplicated value
|
|
// Return Value:
|
|
// - S_OK or Win32 error from `::DuplicateHandle`
|
|
static HRESULT _duplicateHandle(const HANDLE in, HANDLE& out)
|
|
{
|
|
RETURN_IF_WIN32_BOOL_FALSE(DuplicateHandle(GetCurrentProcess(), in, GetCurrentProcess(), &out, 0, FALSE, DUPLICATE_SAME_ACCESS));
|
|
return S_OK;
|
|
}
|
|
|
|
// Routine Description:
|
|
// - Takes the incoming information from COM and and prepares a console hosting session in this process.
|
|
// Arguments:
|
|
// - server - Console driver server handle
|
|
// - inputEvent - Event already established that we signal when new input data is available in case the driver is waiting on us
|
|
// - msg - Portable attach message containing just enough descriptor payload to get us started in servicing it
|
|
// - inboxProcess - Handle to the inbox process so we can watch it to see if it disappears on us.
|
|
// - process - Handle to our process for waiting for us to exit
|
|
HRESULT CConsoleHandoff::EstablishHandoff(HANDLE server,
|
|
HANDLE inputEvent,
|
|
PCCONSOLE_PORTABLE_ATTACH_MSG msg,
|
|
HANDLE signalPipe,
|
|
HANDLE inboxProcess,
|
|
HANDLE* process)
|
|
try
|
|
{
|
|
RETURN_HR_IF(E_INVALIDARG, !process);
|
|
|
|
// Fill the descriptor portion of a fresh api message with the received data.
|
|
// The descriptor portion is the "received" packet from the last ask of the driver.
|
|
// The other portions are unnecessary as they track the other buffer state, error codes,
|
|
// and the return portion of the api message.
|
|
// We will re-retrieve the connect information (title, window state, etc.) when the
|
|
// new console session begins servicing this.
|
|
CONSOLE_API_MSG apiMsg{};
|
|
apiMsg.Descriptor.Identifier.HighPart = msg->IdHighPart;
|
|
apiMsg.Descriptor.Identifier.LowPart = msg->IdLowPart;
|
|
apiMsg.Descriptor.Process = static_cast<decltype(apiMsg.Descriptor.Process)>(msg->Process);
|
|
apiMsg.Descriptor.Object = static_cast<decltype(apiMsg.Descriptor.Object)>(msg->Object);
|
|
apiMsg.Descriptor.Function = msg->Function;
|
|
apiMsg.Descriptor.InputSize = msg->InputSize;
|
|
apiMsg.Descriptor.OutputSize = msg->OutputSize;
|
|
|
|
// Duplicate the handles from what we received.
|
|
// The contract with COM specifies that any HANDLEs we receive from the caller belong
|
|
// to the caller and will be freed when we leave the scope of this method.
|
|
// Making our own duplicate copy ensures they hang around in our lifetime.
|
|
RETURN_IF_FAILED(_duplicateHandle(server, server));
|
|
RETURN_IF_FAILED(_duplicateHandle(inputEvent, inputEvent));
|
|
RETURN_IF_FAILED(_duplicateHandle(signalPipe, signalPipe));
|
|
RETURN_IF_FAILED(_duplicateHandle(inboxProcess, inboxProcess));
|
|
|
|
// Now perform the handoff.
|
|
RETURN_IF_FAILED(ConsoleEstablishHandoff(server, inputEvent, signalPipe, inboxProcess, &apiMsg));
|
|
|
|
// Give back a copy of our own process handle to be tracked.
|
|
RETURN_IF_WIN32_BOOL_FALSE(DuplicateHandle(GetCurrentProcess(),
|
|
GetCurrentProcess(),
|
|
GetCurrentProcess(),
|
|
process,
|
|
SYNCHRONIZE,
|
|
FALSE,
|
|
0));
|
|
|
|
return S_OK;
|
|
}
|
|
CATCH_RETURN();
|