terminal
terminal copied to clipboard
microsoft
Windows Terminal Freezes on Resize
Windows Terminal version
1.11.2921.0
Windows build number
10.0.22000
Other Software
No response
Steps to reproduce
Open terminal with some Ubuntu WSL2 tabs. Work for a bit to populate the terminal tab contents. Resize window or change the screen resolution.
Expected Behavior
Terminal window continues to function and allow input.
Actual Behavior
Windows Terminal tabs no longer accept input and hang.
Do you have a consistent set of steps of how you're populating the Terminal that repro's this, or is it just random? When the window is hung like this, is the tab hung, or the entire window? Like, can you open new tabs that work fine, it's just the original tab that's hung?
When the Terminal is frozen like this, could you grab a dump with Task Manager and send it to us?
That might be helpful in trying to figure out what's hung.
@zadjii-msft The content is random. All the tabs are frozen, but I can open new tabs in the same terminal window and they work fine. Next time this happens (which will be sooner rather than later) I'll create a dump file.
@zadjii-msft Please message me directly to get this file. It's 5gb uncompressed.
It's 5gb uncompressed
wow holy crap. Okay, that's probably infeasible to send over email or the other usual channels. The simplest solution here might be to have you open the dump yourself in WinDBG. Give it a while to load the symbols, and then type ~*k in the Command Window. That'll print a stack trace of all the threads. Paste the output here, it should be immediately obvious where the stack overflow is occurring. (I'm guessing it's a SO with that much RAM usage), Sorry for the delay in responding over the holiday season!
I'm currently experiencing the same issue. The WSL instance seems to freeze, but I can open new tabs that work just fine.
Additionally, sometimes with multiple tabs if I use one for so long and then come back to the other, it has also frozen. I suspect something might be halting when not in use that fails to wake back up when required.
I'm currently experiencing the same issue. The WSL instance seems to freeze, but I can open new tabs that work just fine.
Additionally, sometimes with multiple tabs if I use one for so long and then come back to the other, it has also frozen. I suspect something might be halting when not in use that fails to wake back up when required.
I'm seeing the same behavior
I'm currently experiencing the same issue. The WSL instance seems to freeze, but I can open new tabs that work just fine. Additionally, sometimes with multiple tabs if I use one for so long and then come back to the other, it has also frozen. I suspect something might be halting when not in use that fails to wake back up when required.
I'm seeing the same behavior
Turns out in my case it was oh-my-zsh was causing the issue. Disabling it in .zshrc resolved this for me.
This started to happen to me in the past few months. Never happened before that.
I primarily work in WSL, and I also noticed that during resize, sometimes the Bash PS1 prompt is not displayed correctly; I only get partial output from the prompt.
Windows Terminal Version: 1.14.1962.0
Hmm. Just linking some other posts that all come to mind:
- #12607
- #12176
- #13386
- #13705
I'm starting to think this whole nexus of issues is related.
The stack from functionportal was unfortunately uninteresting.
Main thread looked like:
. 0 Id: 48b0.7054 Suspend: 0 Teb: 00000027`01e5f000 Unfrozen
# Child-SP RetAddr Call Site
00 00000027`01d1f918 00007ffc`5fc1464e win32u!NtUserGetMessage+0x14
01 00000027`01d1f920 00007ffc`0d0d00e9 user32!GetMessageW+0x2e
02 00000027`01d1f980 00007ff6`54218827 Graphics_Hook64!dummy_debug_proc+0xa629
03 00000027`01d1f9c0 00007ff6`5421bf72 WindowsTerminal+0x8827
04 00000027`01d1fb80 00007ffc`5fb454e0 WindowsTerminal+0xbf72
05 00000027`01d1fbc0 00007ffc`6052485b kernel32!BaseThreadInitThunk+0x10
06 00000027`01d1fbf0 00000000`00000000 ntdll!RtlUserThreadStart+0x2b
But there weren't any other symbols. None of the other stacks really looked interesting. There were like, 390 threads total, 362 were in nvwgf2umx_cfg!OpenAdapter12 or above (weird). There were 7 TerminalConnection threads, so that's like 50 graphics threads per tab/pane. That's crazy high.
Does anyone in this thread have OBS studio installed? just a curiosity.
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.
@zadjii-msft This is still a problem that's specific to MS Terminal, so it's not stale nor should it be closed. I switched to mostly using the terminal in IntelliJ and have not hit this issue there. Terminal still has this problem when used.
wait hold the phone https://github.com/microsoft/terminal/issues/11903#issuecomment-991447692
That's a 5GB windowsterminal.exe? That's WAY bigger than expected. That's a crazy memory leak. Terminal should never be running anywhere close to that. But there's no stack overflow, there's no obvious loop without looking at the real symbols.
None of the other deadlocks are anything like that kind of a leak.
Any chance, are you running magnifier, or Narrator, or any other sort of accessibility / UIA tool?
note to self: 1.11 did include the ticket_lock
I think there's a way to upload a .dmp to feedback hub, without making FH try to take the dump itself. If you just drag/drop the dmp to the "Attached" section of FH, it should upload it.
Can you try that, and share the link here? Hopefully my debugger can pull the symbols
Hi @zadjii-msft
I've been experiencing a similar behavior since recently, where I would minimize the Windows Terminal window and later when trying to return to it, I would discover it got stuck - cannot be restored and can be only closed. I suspect this might be some Windows Store App idling behavior gone bad.
I can start a new Windows Terminal window, no problem there. It's just the one that was minimized that I cannot recover. In this case, I had a Powershell 7 tab running as the only running tab, and wasn't doing anything fancy there.
I've captured a few shots of the process (via Task Manager and Process Explorer), as well as a dump file. My process doesn't have memory runaway like the OP's, but the mem dump is still big - around 300 MB.
Windows Terminal version: 1.14.1962.0 Windows OS version: Windows 10 Enterprise, 20H2, OS build 19042.1889
Let me know if I can send a link with the dump file via OneDrive or similar.
Thanks! Angel
@sc-angeluzunov you're seeing #13589, which already has a fix available.
Oops, apologies! So that one goes out with 1.16 - good to know. @zadjii-msft Thanks for the quick reply!
@sc-angeluzunov it's actually already available for 1.14 in https://github.com/microsoft/terminal/releases/tag/v1.14.2281.0
I've been having the same freezing issue, it happens most often when changing screen resolution, or connecting via remote desktop. Here's a dump file: https://1drv.ms/u/s!AhK2CLItkDrhgbhVq3DTXs29a0c3bA?e=tRnWDZ
Also happening to me, too, when resizing the window the terminal contents no longer updates, however it is still processing inputs as I can write my vim buffer and quit before opening a new, working, tab.
I'm having a different problem, sometimes the whole window hangs on minimize. when i kill terminal, then, i will have un unresponsive "openconsole.exe" on the top left of the screen that is very small and only has the close button. can't consinstently reproduce, it's random. it's been doing that since the latest update on ms store (which is 1.16.2642.0 i think). processes in the window keep going (i could finish my android rom flash with no problems lol)
screen of what appears after i kill terminal
I've experienced the same issue, terminal hangs after resizing my window. (was running 2 terminal tabs and 1 ubuntu wsl) Not sure when it exactly happened, as I just restarted terminal and it seems to be OK now (resizing is OK) so it seems a bit random.
@ElDavoo FWIW what you're seeing is some vatiation on #13640, which I think is related to #13388.
We've got a running theory that the Atlas Rendering Engine, enabled by default on 1.16 Preview, should resolve this, or at least mitigate it greatly.
it's actually already available for 1.14 in
@zadjii-msft I have 1.15.2875.0 but it still freezes a zsh shell terminal :(
@Slapbox The comment you quoted, about 1.14, was for an unrelated bug that got roped into this thread. As I said above, we've got a theory that this is fixed in 1.16 Preview, with the atlas engine, but we can't say for sure without a consistent repro.
@zadjii-msft sorry I meant to update here - it turned out to be the known issue with Git For Windows.
@Slapbox The comment you quoted, about 1.14, was for an unrelated bug that got roped into this thread. As I said above, we've got a theory that this is fixed in 1.16 Preview, with the atlas engine, but we can't say for sure without a consistent repro.
Still happens :( Can't have consistent steps to reproduce. happens sometimes when minimizing.