After minimizing, unable to restore window with Alt-Tab #18029

@babico commented on GitHub (Jul 25, 2022):

I have same issue I tried change preview to stable version but it didn't change anything, still happening this bug.

@babico commented on GitHub (Jul 25, 2022): I have same issue I tried change preview to stable version but it didn't change anything, still happening this bug.

claunia commented

@zadjii-msft commented on GitHub (Jul 25, 2022):

Does this only happen when running elevated (as Administrator)? this looks similar to #13592 which was just filed. I can't repro this here on Windows 11, but maybe the focus/foreground work attached to #2988 regressed this in Windows 10 😨

@zadjii-msft commented on GitHub (Jul 25, 2022): Does this only happen when running elevated (as Administrator)? this looks similar to #13592 which was just filed. I can't repro this here on Windows 11, but maybe the focus/foreground work attached to #2988 regressed this in Windows 10 😨

claunia commented

@babico commented on GitHub (Jul 25, 2022):

Does this only happen when running elevated (as Administrator)? this looks similar to #13592 which was just filed. I can't repro this here on Windows 11, but maybe the focus/foreground work attached to #2988 regressed this in Windows 10 😨

Yes, it happen on administrator mod I didn't even notice the administrator mod.

@babico commented on GitHub (Jul 25, 2022): > Does this only happen when running elevated (as Administrator)? this looks similar to #13592 which was just filed. I can't repro this here on Windows 11, but maybe the focus/foreground work attached to #2988 regressed this in Windows 10 😨 Yes, it happen on administrator mod I didn't even notice the administrator mod.

claunia commented

@vertigo220 commented on GitHub (Jul 25, 2022):

Sorry, I forgot to mention this in my OP, but it was NOT running as admin at the time. And, if it matters, I had about four or five tabs open, with a mix of PS and cmd.

@vertigo220 commented on GitHub (Jul 25, 2022): Sorry, I forgot to mention this in my OP, but it was NOT running as admin at the time. And, if it matters, I had about four or five tabs open, with a mix of PS and cmd.

claunia commented

@zadjii-msft commented on GitHub (Jul 25, 2022):

Alright, I'm deduping here, this will be the master tracking thread.

Doesn't seem limited to Windows 10 (at least, I can repro this on win11 in an elevated window sometimes)
Only occurs when minimizing to the taskbar, using the taskbar icon itself.
Doesn't seem limited to elevated windows (but seems more frequent)
If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way

There's also MSFT:40530963 tracking internally.

@zadjii-msft commented on GitHub (Jul 25, 2022): Alright, I'm deduping here, this will be the master tracking thread. * Doesn't seem limited to Windows 10 (at least, I can repro this on win11 in an elevated window _sometimes_) * Only occurs when minimizing to the taskbar, using the taskbar icon itself. * Doesn't seem limited to elevated windows (but seems more frequent) * **If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way** There's also MSFT:40530963 tracking internally.

claunia commented

@vertigo220 commented on GitHub (Jul 25, 2022):

Only occurs when minimizing to the taskbar, using the taskbar icon itself.

Ah, and there it is. Kinda surprised I didn't think to try this, but yeah, if I minimize this way, it happens every time, with a non-admin window. Doesn't get stuck though, just have to click the taskbar button again.

@vertigo220 commented on GitHub (Jul 25, 2022): > * Only occurs when minimizing to the taskbar, using the taskbar icon itself. Ah, and there it is. Kinda surprised I didn't think to try this, but yeah, if I minimize this way, it happens every time, with a non-admin window. Doesn't get stuck though, just have to click the taskbar button again.

claunia commented

@lhecker commented on GitHub (Jul 26, 2022):

@zadjii-msft I narrowed it down to 6b936d9a74. Commenting out this line fixes the issue:
feabe41a08/src/cascadia/TerminalControl/ControlCore.cpp (L1929)

I tried various ways to debug this further and fix the issue, but failed at it so far. 😥

@lhecker commented on GitHub (Jul 26, 2022): @zadjii-msft I narrowed it down to 6b936d9a74a5d677387f3edc9a68e6b33d566606. Commenting out this line fixes the issue: https://github.com/microsoft/terminal/blob/feabe41a08604345a1eeb4b38fd1c99b811f8ecd/src/cascadia/TerminalControl/ControlCore.cpp#L1929 I tried various ways to debug this further and fix the issue, but failed at it so far. 😥

claunia commented

@zadjii commented on GitHub (Jul 26, 2022):

I wonder if it's because that results in a xproc call (sending a message to OpenConsole.exe via a pipe) on the main thread. I wonder if user32 doesn't like us doing that... A resume_background right before that would be an interesting experiment

@zadjii commented on GitHub (Jul 26, 2022): I wonder if it's because that results in a xproc call (sending a message to OpenConsole.exe via a pipe) on the main thread. I wonder if user32 doesn't like us doing that... A resume_background right before that would be an interesting experiment

claunia commented

@gradyalexis commented on GitHub (Jul 26, 2022):

I have the same issue. when run as Administrator, is not restored if it was minimized

@gradyalexis commented on GitHub (Jul 26, 2022): I have the same issue. when run as Administrator, is not restored if it was minimized

claunia commented

@Shdwfx commented on GitHub (Jul 26, 2022):

i can always reproduce if i double click terminal icon on taskbar when its minimized. (in administrator mode)

@Shdwfx commented on GitHub (Jul 26, 2022): i can always reproduce if i double click terminal icon on taskbar when its minimized. (in administrator mode)

claunia commented

@philipphutterer commented on GitHub (Jul 26, 2022):

Same problem here, windows 10, elevated terminal.
Though this hint was pretty helpful since I closed many windows with multiple tabs and sessions open so far. Thanks for that.

If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way

@philipphutterer commented on GitHub (Jul 26, 2022): Same problem here, windows 10, elevated terminal. Though this hint was pretty helpful since I closed many windows with multiple tabs and sessions open so far. Thanks for that. > If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way

claunia commented

@zadjii-msft commented on GitHub (Jul 26, 2022):

Notes (ongoing)

I was able to get an unelevated dev build of the Terminal into this state, on Windows 11.
In that state, we only get a few messages when alt-tabbing to the window:
- 0x7f
- WM_WINDOWPOSCHANGING
  - the flags are: 0x13 = SWP_NOACTIVATE | SWP_NOMOVE | SWP_NOMOVE
  - hwndInsertAfter is not a special value.
- WM_WINDOWPOSCHANGED
- and that's it. There's nothing else, no ShowWindow or anything...
We don't even get into ControlCore::_focusChanged even remotely. Checks out, the window never gets shown so no duh it's not getting focused.
The current window styles are... 34CF0000 -> WS_VISIBLE | WS_MINIMIZE is set...
The ConPty HWND seems to be owned correctly, and WS_VISIBLE | WS_MINIMIZE are both set

Below is two tabs worth of messages on attempted alt-tabbing:

MessageHandler: 0x00000046 WM_WINDOWPOSCHANGING
InteractivityFactory::PseudoWindowProc 0x00000047 WM_WINDOWPOSCHANGED
InteractivityFactory::PseudoWindowProc 0x0000000d WM_GETTEXT
InteractivityFactory::PseudoWindowProc 0x00000047 WM_WINDOWPOSCHANGED
InteractivityFactory::PseudoWindowProc 0x0000000d WM_GETTEXT
MessageHandler: 0x00000047 WM_WINDOWPOSCHANGED
InteractivityFactory::PseudoWindowProc 0x0000001c WM_ACTIVATEAPP
InteractivityFactory::PseudoWindowProc 0x00000086 WM_NCACTIVATE
InteractivityFactory::PseudoWindowProc 0x0000000d WM_GETTEXT
InteractivityFactory::PseudoWindowProc 0x0000000d WM_GETTEXT
InteractivityFactory::PseudoWindowProc 0x00000006 WM_ACTIVATE
InteractivityFactory::PseudoWindowProc 0x00000281 WM_IME_SETCONTEXT
InteractivityFactory::PseudoWindowProc 0x00000282 WM_IME_NOTIFY
InteractivityFactory::PseudoWindowProc 0x00000007 WM_SETFOCUS
MessageHandler: 0x0000001e WM_TIMECHANGE
InteractivityFactory::PseudoWindowProc 0x0000001e WM_TIMECHANGE
InteractivityFactory::PseudoWindowProc 0x0000001e WM_TIMECHANGE

Activating the child conhost seems... weird? But maybe harmless
This repros way more frequently in a win10 VM. There, the first time I try to minimize by clicking on the taskbar, it doesn't do anything. Like, the window just stays open. If I click the taskbar again, it does minimize. THAT is when the window gets stuck. Friggen weird.
Debugging with Evan:
- When we first click the taskbar icon, the kernel tries to SwitchToWindow to the main terminal window. That's by itself not that weird. Maybe the OS doesn't think the Terminal window is active & FG. Not terribly uncommon, but still weird.
- The next click: The main terminal window minimizes, via xxxminmaximizeex.
- The conpty window minimizes as a result (unclear how exactly. Presumably, due to conpty minimizing itself via ConhostInternalGetSet::ShowWindow's call to ::ShowWindowAsync(hwnd, showOrHide ? SW_SHOWNOACTIVATE : SW_MINIMIZE)
- At this point, both windows are minimized.
- You alt-tab to the window.
- xxxSwitchToThisWindow gets called ON THE CONPTY HWND. Why that one?
- Why doesn't that end up restoring the terminal HWND? If anything, it restores the conpty hwnd, so it should cause the Terminal to get SC_RESTORE'd
Even outside of the repro case:
- We hit IslandWindow::ShowWindowChanged(false) every time we minimize with the taskbar. What? why. That doesn't make sense, right? Like
- we DONT get a IslandWindow::ShowWindowChanged(true) on restore. wat
In the repro case:
- We don't get a TerminalPage::_ShowWindowChanged on the attempted restore. I suspect we never get it out of conpty.
- Nope we don't get bp Microsoft_Terminal_control!winrt::Microsoft::Terminal::Control::implementation::ControlCore::_terminalShowWindowChanged.
- Nor do we hit a bp Microsoft_Terminal_control!Microsoft::Console::VirtualTerminal::AdaptDispatch::WindowManipulation. So it's not even getting out of the conpty.

@zadjii-msft commented on GitHub (Jul 26, 2022): Notes (_ongoing_) * I was able to get an unelevated dev build of the Terminal into this state, on Windows 11. * In that state, we only get a few messages when alt-tabbing to the window: - `0x7f` - `WM_WINDOWPOSCHANGING` - the flags are: `0x13` = `SWP_NOACTIVATE | SWP_NOMOVE | SWP_NOMOVE` - `hwndInsertAfter` is not a special value. - `WM_WINDOWPOSCHANGED` - and that's it. There's nothing else, no ShowWindow or anything... * We don't even get into `ControlCore::_focusChanged` even remotely. Checks out, the window never gets shown so no duh it's not getting focused. * The current window styles are... `34CF0000` -> `WS_VISIBLE | WS_MINIMIZE` _is_ set... * The ConPty HWND seems to be owned correctly, and `WS_VISIBLE | WS_MINIMIZE` are both set * Below is two tabs worth of messages on attempted alt-tabbing: ``` MessageHandler: 0x00000046 WM_WINDOWPOSCHANGING InteractivityFactory::PseudoWindowProc 0x00000047 WM_WINDOWPOSCHANGED InteractivityFactory::PseudoWindowProc 0x0000000d WM_GETTEXT InteractivityFactory::PseudoWindowProc 0x00000047 WM_WINDOWPOSCHANGED InteractivityFactory::PseudoWindowProc 0x0000000d WM_GETTEXT MessageHandler: 0x00000047 WM_WINDOWPOSCHANGED InteractivityFactory::PseudoWindowProc 0x0000001c WM_ACTIVATEAPP InteractivityFactory::PseudoWindowProc 0x00000086 WM_NCACTIVATE InteractivityFactory::PseudoWindowProc 0x0000000d WM_GETTEXT InteractivityFactory::PseudoWindowProc 0x0000000d WM_GETTEXT InteractivityFactory::PseudoWindowProc 0x00000006 WM_ACTIVATE InteractivityFactory::PseudoWindowProc 0x00000281 WM_IME_SETCONTEXT InteractivityFactory::PseudoWindowProc 0x00000282 WM_IME_NOTIFY InteractivityFactory::PseudoWindowProc 0x00000007 WM_SETFOCUS MessageHandler: 0x0000001e WM_TIMECHANGE InteractivityFactory::PseudoWindowProc 0x0000001e WM_TIMECHANGE InteractivityFactory::PseudoWindowProc 0x0000001e WM_TIMECHANGE ``` * Activating the child conhost seems... weird? But maybe harmless * This repros way more frequently in a win10 VM. There, **the first time I try to minimize by clicking on the taskbar, it doesn't do anything**. Like, the window just stays open. If I click the taskbar again, it does minimize. THAT is when the window gets stuck. Friggen weird. * Debugging with Evan: * When we first click the taskbar icon, the kernel tries to SwitchToWindow to the main terminal window. That's by itself not that weird. Maybe the OS doesn't think the Terminal window is active & FG. Not terribly uncommon, but still weird. * The next click: The main terminal window minimizes, via `xxxminmaximizeex`. * The conpty window minimizes as a result (unclear how exactly. Presumably, due to conpty minimizing itself via `ConhostInternalGetSet::ShowWindow`'s call to `::ShowWindowAsync(hwnd, showOrHide ? SW_SHOWNOACTIVATE : SW_MINIMIZE)` * At this point, both windows are minimized. * You alt-tab to the window. * `xxxSwitchToThisWindow` gets called ON THE CONPTY HWND. Why that one? * Why doesn't that end up restoring the terminal HWND? If anything, it restores the conpty hwnd, so it should cause the Terminal to get `SC_RESTORE`'d * Even outside of the repro case: * We hit `IslandWindow::ShowWindowChanged(false)` every time we minimize with the taskbar. What? why. That doesn't make sense, right? Like * we DONT get a `IslandWindow::ShowWindowChanged(true)` on restore. wat * In the repro case: * We don't get a `TerminalPage::_ShowWindowChanged` on the attempted restore. I suspect we never get it out of conpty. * Nope we don't get `bp Microsoft_Terminal_control!winrt::Microsoft::Terminal::Control::implementation::ControlCore::_terminalShowWindowChanged`. * Nor do we hit a `bp Microsoft_Terminal_control!Microsoft::Console::VirtualTerminal::AdaptDispatch::WindowManipulation`. So it's not even getting out of the conpty.

claunia commented

@zadjii-msft commented on GitHub (Jul 27, 2022):

In the 10 VM, the taskbar icon is not immediately highlighted when launching the Terminal. As if it doesn't know that the terminal is in the FG. That would explain the initial SwitchToWindow

But then after the "restore", the terminal is indicated as being active. Hmm.

@zadjii-msft commented on GitHub (Jul 27, 2022): In the 10 VM, the taskbar icon is not immediately highlighted when launching the Terminal. As if it doesn't know that the terminal is in the FG. That would explain the initial SwitchToWindow ![gh-13589-000](https://user-images.githubusercontent.com/18356694/181360423-7716a04d-6e37-4144-9ec0-1d813e0c443e.gif) But then after the "restore", the terminal is indicated as being active. Hmm.

claunia commented

@zadjii-msft commented on GitHub (Jul 27, 2022):

#13158

    // BODGY
    //
    // GH#13158 - At least temporarily, only allow the PTY to HIDE the terminal
    // window. There seem to be many issues with this so far, and the quickest
    // route to mitigate them seems to be limiting the interaction here to
    // allowing ConPTY to minimize the terminal only. This will still allow
    // applications to hide the Terminal via GetConsoleWindow(), but should
    // broadly prevent any other impact of this feature.
    //
    // Should we need to restore this functionality in the future, we should
    // only do so with great caution.

Oh hey look, that came back to bite 😠

@zadjii-msft commented on GitHub (Jul 27, 2022): #13158 ```c++ // BODGY // // GH#13158 - At least temporarily, only allow the PTY to HIDE the terminal // window. There seem to be many issues with this so far, and the quickest // route to mitigate them seems to be limiting the interaction here to // allowing ConPTY to minimize the terminal only. This will still allow // applications to hide the Terminal via GetConsoleWindow(), but should // broadly prevent any other impact of this feature. // // Should we need to restore this functionality in the future, we should // only do so with great caution. ``` Oh hey look, that came back to bite 😠

claunia commented

@YueLu0116 commented on GitHub (Jul 28, 2022):

Same problem here, windows 10 (20H2), elevated terminal.
This afternoon, every time after I built a project in vs2019, the terminal suddenly disappear.

@YueLu0116 commented on GitHub (Jul 28, 2022): Same problem here, windows 10 (20H2), elevated terminal. This afternoon, every time after I built a project in vs2019, the terminal suddenly disappear.

claunia commented

@satyapramodh commented on GitHub (Aug 5, 2022):

@zadjii-msft If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way

this doesnt work for me on windows 11. my cmd prompt is elevated. this happens to me every day more than once everyday of the week.
I am on windows 11 21H2, Win Terminal v1.14.1963.0

@satyapramodh commented on GitHub (Aug 5, 2022): @zadjii-msft **If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way** - this doesnt work for me on windows 11. my cmd prompt is elevated. this happens to me every day more than once everyday of the week. I am on windows 11 21H2, Win Terminal v1.14.1963.0 ![image](https://user-images.githubusercontent.com/3414042/183208140-636fcff4-f44e-41b7-8e32-834666b764ee.png)

claunia commented

@vertigo220 commented on GitHub (Aug 5, 2022):

@satyapramodh Your screenshot only shows you hovering over the thumbnail. Did you actually right-click on the thumbnail and select restore from the menu that pops up? Granted, I'm on W10, but that does work for me and others, and it looks like zadjii is on Win11, like you, so it seems it should work for you as well.

@vertigo220 commented on GitHub (Aug 5, 2022): @satyapramodh Your screenshot only shows you hovering over the thumbnail. Did you actually right-click _on the thumbnail_ and select restore from the menu that pops up? Granted, I'm on W10, but that _does_ work for me and others, and it looks like zadjii is on Win11, like you, so it seems it should work for you as well.

claunia commented

@aaronedev commented on GitHub (Aug 11, 2022):

Ok - restoring the window does actually work, but is quite annoying. Shouldn't have updated the terminal at all, the old version was working quite fine. 😅

@aaronedev commented on GitHub (Aug 11, 2022): Ok - restoring the window does actually work, but is quite annoying. Shouldn't have updated the terminal at all, the old version was working quite fine. 😅

claunia commented

@rpodric commented on GitHub (Aug 12, 2022):

Just to chime in that it happens on Win11 22H2, too

The "right-click on the thumbnail and select restore" trick, which may be the only thing I hadn't tried, does get it back, but it's almost impossible to remember not to minimize it from the taskbar, so it keeps happening.

@rpodric commented on GitHub (Aug 12, 2022): Just to chime in that it happens on Win11 22H2, too The "right-click on the thumbnail and select restore" trick, which may be the only thing I hadn't tried, does get it back, but it's almost impossible to remember not to minimize it from the taskbar, so it keeps happening.

claunia commented

@pimpace commented on GitHub (Aug 14, 2022):

@zadjii-msft said:
If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way

No need to wait for preview of the window, for this "hover thing", simply shift-rightclick on the Terminal taskbar button and
click restore. A little bit simpler. :)

@pimpace commented on GitHub (Aug 14, 2022): @zadjii-msft said: **If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way** No need to wait for preview of the window, for this "hover thing", simply shift-rightclick on the Terminal taskbar button and click restore. A little bit simpler. :)

claunia commented

@ghost commented on GitHub (Aug 18, 2022):

:tada:This issue was addressed in #13624, which has now been successfully released as Windows Terminal v1.14.228.🎉

Handy links:

@ghost commented on GitHub (Aug 18, 2022): :tada:This issue was addressed in #13624, which has now been successfully released as `Windows Terminal v1.14.228`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.14.228) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)

claunia commented

@ghost commented on GitHub (Aug 18, 2022):

:tada:This issue was addressed in #13624, which has now been successfully released as Windows Terminal Preview v1.15.228.🎉

Handy links:

@ghost commented on GitHub (Aug 18, 2022): :tada:This issue was addressed in #13624, which has now been successfully released as `Windows Terminal Preview v1.15.228`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.15.228) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)

claunia commented

@vertigo220 commented on GitHub (Aug 18, 2022):

Those "handy" links are 404. They're missing the ".0" on the end.

@vertigo220 commented on GitHub (Aug 18, 2022): Those "handy" links are 404. They're missing the ".0" on the end.

claunia commented

@pheu commented on GitHub (Aug 22, 2022):

Those "handy" links are 404. They're missing the ".0" on the end.

Yup, both links are very "handy". One misses .0 and another points to the store where they still keep older buggy version (200). 😁

@pheu commented on GitHub (Aug 22, 2022): > Those "handy" links are 404. They're missing the ".0" on the end. Yup, both links are very "handy". One misses .0 and another points to the store where they still keep older buggy version (200). 😁

claunia commented

@rpodric commented on GitHub (Aug 25, 2022):

The Store just got 1.14.2282.0.

@rpodric commented on GitHub (Aug 25, 2022): The Store just got 1.14.2282.0.

claunia commented

@aaronedev commented on GitHub (Aug 25, 2022):

The Store just got 1.14.2282.0.

thanks for letting us know

@aaronedev commented on GitHub (Aug 25, 2022): > The Store just got 1.14.2282.0. thanks for letting us know

claunia commented