Terminal cannot be closed when the defterm client closes too quickly (and creates a window with no tabs)

[floppyhammer]

---

[!IMPORTANT]
📌 Pinned comment: https://github.com/microsoft/terminal/issues/15936#issuecomment-1710747811 We're pretty sure this comes down to two effects:

• The client app closes before the Terminal can accept the handoff and create a tab for it.
• The Terminal can't be closed when it has no tabs open.

We should really fix both of these at the same time.

---

Windows Terminal version

1.17.12191.0

Windows build number

25941.1000

Other Software

No response

Steps to reproduce

There's no routine to easily reproduce it. It happens occasionally when I use some command line tools (like npm) that will invoke another terminal/cmd console. When the process is done, the invoked terminal will not close successfully (only the tab is closed, which results in an empty terminal with no tab), and you are unable to close it manually (because there's no tab).

Expected Behavior

A terminal losing any tabs should not exist.

Actual Behavior

[lhecker]

There's no routine to easily reproduce it. It happens occasionally when I use some command line tools (like npm) that will invoke another terminal/cmd console.

I don't think anyone on the team has encountered this before. Are there some steps we could follow to attempt to reproduce it? (For instance if you list the tools and commands that cause the issue for you.)

[tusharsnx]

I happened to hit this bug many times. The strange terminal window (without any tabs on it) is invoked with -Embedding arg in the background by something, not sure what but ~I've a feeling~ (I've lost the feeling 😄) that it's VS.

[tusharsnx]

More Info:

It seems to be invoked by ~wininit.exe~ svchost.exe?

[tusharsnx]

This is quite funny, but we have a repro right in our test suite 😂 (So I was correct, VS was related in this, maybe indirectly)

Step to reproduce:

• Set Windows Terminal as the "Default Terminal application".
• Open VS and run the test named "WindowsTerminal.UIA.Tests".
• You should see a blank WT window pop up in the background.

video demo: https://youtu.be/lNJOSjXioOY

[zadjii-msft]

My theory is that if the client application exits fast enough, we start a defterm window, but we never get it to the point of making an actual tab.

I see this sometimes (but usually only when I have a horribly busted defterm install).

I wonder if this repros after the process model changes in 1.18 EDIT: #16234 would imply that yes, this repros on 1.18

[floppyhammer]

My repro case:

1. Run npm run dev to start a server.
2. Force close it by pressing ctrl+c once, and no need to confirm the ensued prompt Terminate batch job (Y/N)?.
3. Normally, a terminal window pops up and closes itself quickly. Sometimes there's a second window following, but it will stay and it contains no tab.

[DanielHabenicht]

I can also reproduce with:

• Set Windows Terminal as the "Default Terminal application".
• Add a pretty short running Task To Task Scheduler executing a .cmd file on logon.
• At every Logon you are greeted by a terminal window with no body (see the background of the picture)

For me it looks even more odd, as the windows don't even have a fill:

[tusharsnx]

@DanielHabenicht I suppose you're Win10, and the fill we can see in other repros is Mica which isn't available on Win10. Therefore, no fill? 🤔

[DanielHabenicht]

Yes, I am on windows 10. You can see the version in the issue linked above.

[danielniccoli]

Here is another repro. Steps inside: https://github.com/microsoft/terminal/issues/16281

I noticed that sometimes when this happens, in addition to Windows Terminal launching without a tab (the reported bug) it does also start the classic shell that then runs the actual PowerShell command/script.

Edit: By the way, this is the script I'm running.

Start-Sleep 1  # Try to work around https://github.com/microsoft/terminal/issues/15936
if((Test-Path "C:\code") -and $env:OneDriveCommercial -and (Test-Path $env:OneDriveCommercial)) {
    # With monitoring
    # robocopy "C:\code" (Join-Path $env:OneDriveCommercial code_backup) /MIR /TIMFIX /MON:1 /MOT:1 /DCOPY:DAT /XD venv .venv node_modules __pycache__ /NFL /NDL /R:10 /W:1
    # Without monitoring
    $p = Start-Process robocopy -ArgumentList "C:\code `"$(Join-Path $env:OneDriveCommercial code_backup)`" /MIR /TIMFIX /DCOPY:DAT /XD venv .venv node_modules __pycache__ /NFL /NDL /R:10 /W:1" -NoNewWindow -Wait -PassThru
    Start-Sleep 1  # Try to work around https://github.com/microsoft/terminal/issues/15936
    exit $p.ExitCode
} else {
    Start-Sleep 1  # Try to work around https://github.com/microsoft/terminal/issues/15936
    exit 1
}

[PaprikaBoyTheOneAndOnly]

Hi, are there any updates on this?

[zadjii-msft]

I'm investigating this currently. I could have swore I used to have a minimal repro for this, but I'm having a hard time currently 😕

[zadjii-msft]

If someone who's seeing this consistently could Capture a Debug ETL Trace and share it here, that would help immensely. I'm guessing there's one of two things going on:

• We're failing to initialize the intermediate OpenConsole, after starting the terminal for handoff.
  • In this case, I'd expect to see the following on the Microsoft.Windows.Console.Host provider
  • SrvInit_PrepareToCreateDelegationTerminal
  • SrvInit_CreatedDelegationTerminal
  • but then not a SrvInit_DelegateToTerminalSucceeded, nor a ReceiveTerminalHandoff_Failed (this would be logged to Microsoft.Windows.Terminal.Connection)
• We're failing to accept the handoff from the Terminal.
  • this is like the above, but we would actually log a ReceiveTerminalHandoff_Failed

If we for whatever reason see a ReceiveTerminalHandoff_Success, then that would be surprising to me.

---

notes

First things first: * Conhost starts up. It finds that it's got a delegation **console**, and it starts that. (we can assume this works, because a terminal does get started) * OpenConsole starts up, as the target of a defcon handoff. * `ConsoleEstablishHandoff`: * It finds the target terminal to _also_ delegate to. * Does quite a bit of pipe manipulation, to get ready to call the terminal. (we can assume this works, because a terminal does get started) * We open a handle to the target client process. We hang onto that handle until after the end of `ConsoleEstablishHandoff`. * Calls `CoCreateInstance(g.delegationPair.terminal,...`. (this instantiates terminal, below.) * gets our connection info: Icon, lnk, settings. * **⚠️ yikes** there's a `RETURN_IF_NTSTATUS_FAILED(ConsoleInitializeConnectInfo(...))` in here. If that does fail, we've started terminal, but failed to do a handoff. * We call `handoff->EstablishPtyHandoff` * This will get handled in `CTerminalHandoff::EstablishPtyHandoff`, which is broken down below. _now, over in the terminal, our registered default terminal handoff target. The following occurs when the terminal is launched as a COM server_ These paths to `_StartInboundListener` take care of both glomming and non glomming. * In the glomming scenario, the monarch tells the MRU window to `ExecuteCommandline`, and that will start the inbound listener * in the non-glomming, `TerminalWindow::Initialize` sets the inbound listener. In both cases, the inbound listener is started immediately if the page already laid out, or we set a flag and wait till the first layout to accept the handoff. * `TerminalWindow::Initialize`, if `_appArgs.IsHandoffListener` OR `TerminalWindow::ExecuteCommandline`, again, if `_appArgs.IsHandoffListener` * `TerminalPage::SetInboundListener` * sets `_shouldStartInboundListener=true` * If we were already laid out the first time, immediately calls `_StartInboundListener` * `TerminalPage::_OnFirstLayout` called when the page first lays out * process startup actions * call `_StartInboundListener` to possibly start accepting handoff So here, we're already laid out, and we know this window wants to accept the handoff. * `TerminalPage::_StartInboundListener` if `_shouldStartInboundListener`... * registers the `ConptyConnection::NewConnection` callback * calls `ConptyConnection::StartInboundListener` * `CTerminalHandoff::s_StartListening` passes the `ConptyConnection::NewHandoff` function as the callback to: * `CoRegisterClassObject(CTerminalHandoff, us, as a local server, single-use)` * returns _later, when conpty is ready...._ * `CTerminalHandoff::EstablishPtyHandoff` * THROWS if it fails, for ANY reason * **⚠️ Throwing would also just never call the callback, nor signal an error.** * STOPS listening * duplicates handles * calls it's registered callback * `ConptyConnection::NewHandoff` raises the handoff, which is handled in * `TerminalPage::_OnNewConnection` accepts the connection from conpty * possibly `co_await`s to get onto the window thread. * Creates the tab `_CreateNewTabFromPane(MakePane(..., existingConnection))`

[zadjii-msft]

Leonard: if you use the debug version, set a breakpoint during handoff, or just put a Sleep(10000) on the Terminal side, then the conhost will fail out and the close events will fire before the close events get set up

[alzhahir]

Hi, I think I'm facing a similar issue and was able to reproduce it consistently. Not sure if it's related to this bug specifically, but I hope it helps somehow. For the purposes here, I am using Terminal v1.21.2361.0.

1. Close all Terminal windows.
2. Open a Terminal window. (Window 1)
3. Use a command* to launch a second Terminal window, (Window 2) with the command exiting automatically.
4. Use mouse to hold on Window 2 as the command exits. (i.e dragging the window)
5. Press the close button on Window 2 and Window 1 gets closed instead.
6. We are now left with Window 2.
   • Pressing the close button again won't do anything.
   • Launching a new tab on Window 2 works fine but will also not close the window when all tabs are closed, or the close button is pressed.
   • To exit out of this "buggy" state, you would need to end the Terminal process or launch a new Terminal window. (either from external methods, or from within the bugged window itself)

*In my case, I initially used the command wt pwsh -wd "C:\Users" -c {Write-Host "test";} but since I was not sure if this was a PowerShell issue or Terminal issue, I also tested the command wt ping github.com and it worked as well.

Several observations:

• This does not happen if you have more than 1 Terminal window running prior to executing the command.
• If you have another window (Window 0) alongside the other 2 windows mentioned above, everything works just fine on step 5 and Window 2 gets closed properly.
• This also does not work if you use the command above on a "buggy window".
• Terminal Preview (v1.22.2702.0) does not close Window 1 when the close button on Window 2 is pressed.