Terminal: BUG: Crash on window resize

Created on 6 Aug 2019  路  17Comments  路  Source: microsoft/terminal

Environment

Windows build number: 
Microsoft Windows [Version 10.0.18362.267]

Windows Terminal version (if applicable):
Windows Terminal (Preview)
Version: 0.3.2142.0

Any other software?
None

Steps to reproduce

Start terminal. Resize. I pretty consistently get a crash when I get to about the point of the single tab going to zero width.

Start terminal. Add multiple tabs. Resize. I get crashes when the third tab starts to slide under the new tab UI.

Sometimes you can shrink all the way down and back. Sometimes you can shrink all the way down, and it'll crash as it is being expanded.

Expected behavior

Window resizes without crash

Actual behavior

Here's one of the entries from my event log.

Faulting application name: WindowsTerminal.exe, version: 1.0.1908.2002, time stamp: 0x5d448424
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18362.267, time stamp: 0x3e916038
Exception code: 0xc000027b
Fault offset: 0x00000000007126f0
Faulting process id: 0x2fa8
Faulting application start time: 0x01d54c269fed96bb
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.3.2142.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
Report Id: 985f1c17-14dc-45a2-9bf2-2e663574efa9
Faulting package full name: Microsoft.WindowsTerminal_0.3.2142.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

Here's the feedback hub entry, which should have dx attached to it:

https://aka.ms/AA5roli

Area-Quality Area-User Interface Help Wanted Issue-Bug Product-Terminal Resolution-Fix-Committed Severity-Crash Tracking-External

Most helpful comment

Hey everyone, just an update here:

I've dug real deep into XAML over the last week, and working with @teap, we were able to find that the source of the E_LAYOUTCYCLE wasn't coming from the Windows Terminal code, it was coming from the TabView code itself. Fortunately, @teap has whipped up a fix for us, which should be available on the next update of Microsoft.UI.Xaml 馃帀.

At the time of writing it's unclear _when_ we'll ingest that update and push an update to the store. We'll keep you posted in this thread when we know more. Thanks all for help with getting repro steps found!

All 17 comments

I came here to post this since this immediately happened to me, and is repeatable. Guess I'm not the only one.

On my system, the crash occurs if the width the terminal window < ~850px, no matter the amount of tabs. This is with 150% display scaling in display options.

The height of the window seems to have no impact on stability.

Terminal people: the error is AG_E_LAYOUT_CYCLE, coming from Windows_UI_Xaml!CLayoutManager::UpdateLayout. That function has a while loop where it does layout, and keeps looping around while the tree is dirty (like something changed size or somesuch), until it hits some arbitrary limit, at which point it throws up its hands with this error.

Perhaps the terminal is adjusting the size of something in response to some size-changed event, and we get into a state where we're oscillating or something like that.

For those of us who can't get Terminal to even launch because of this, is there something we can put in the profiles to set window dimensions to avoid the crash? I tried adding initialCols and initialRows to larger values, such as 200 and 60, resp., but Terminal still crashes on launch for me.

The working theory here in the office is that this is the same bug as #3303. While debugging #3303, I confirmed that #3303 is caused by the same AG_E_LAYOUT_CYCLE error in Windows_UI_Xaml!CLayoutManager::UpdateLayout.

Fortunately, I'm fairly sure that #3394 fixed #3303.

Unfortunately, I can't get this exact scenario to repro myself. For someone who is hitting this one consistently, could you try checking out master and seeing if this goes away? If so, then this was definitely the same root as #3303 and can be closed as well. If not, well, we'll have more debugging to do.

@zadjii-msft is there by chance a published nightly dev binary build off of master that we can use?

@jghal Unfortunately, no.

In the absurdity in #3303 that followed my "this might just be resolved" comment here, there might just be a workaround. Mentioned in #3303 is that some of the crashes are tied to a very specific _width of the tab text_. If you're hitting this super consistently, you might be able to set tabTitle to something other than "Windows Powershell" and have this go away magically.

The root cause of this issue is unfortunately still being investigated. #3394 made the "crash on drag to another monitor" far less prevalent, but there are still ways to repro this E_LAYOUTCYCLE that we're hoping to fix.

Not sure if I will be able to do a build myself to test. We haven't officially rolled out 1903 internally, so I had upgrade my laptop and dev VM, and of course Terminal is working out of the box on the dev VM, but other software is not working with 1903 so IT is on track to destroy and redploy the VM with 1803. So while I may be able to get the dev tools setup and build from master on the VM before they do that, it wouldn't really serve to validate the fix since Terminal works there.

If you're hitting this super consistently, you might be able to set tabTitle to something other than "Windows Powershell" and have this go away magically.

Consistently crashes on launch, draws a window frame but I never see the terminal application actually load inside it, and the window just goes away after a few seconds. I just tried playing with setting tabTitle on every profile, and cycled through every profile as the defaultProfile, no luck.

{
    "$schema": "https://aka.ms/terminal-profiles-schema",

    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",

    "profiles":
    [
        {
            "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
            "name": "Windows PowerShell",
            "commandline": "powershell.exe",
            "hidden": false,
            "tabTitle": "PWSH"
        },
        {
            "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
            "name": "cmd",
            "commandline": "cmd.exe",
            "hidden": false,
            "tabTitle": "CMD"
        },
        {
            "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
            "hidden": false,
            "name": "PowerShell Core",
            "source": "Windows.Terminal.PowershellCore",
            "tabTitle": "PWSH Core"
        },
        {
            "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
            "hidden": false,
            "name": "Ubuntu",
            "source": "Windows.Terminal.Wsl",
            "tabTitle": "WSL"
        },
        {
            "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
            "hidden": true,
            "name": "Azure Cloud Shell",
            "source": "Windows.Terminal.Azure",
            "tabTitle": "AZSH"
        }
    ],

    "schemes": [],

    "keybindings": []
}

I also noticed above this error is also reported for font sizes smaller than 10 so I tried adding "fontSize": 12 to all profiles, still no luck.

Hey everyone, just an update here:

I've dug real deep into XAML over the last week, and working with @teap, we were able to find that the source of the E_LAYOUTCYCLE wasn't coming from the Windows Terminal code, it was coming from the TabView code itself. Fortunately, @teap has whipped up a fix for us, which should be available on the next update of Microsoft.UI.Xaml 馃帀.

At the time of writing it's unclear _when_ we'll ingest that update and push an update to the store. We'll keep you posted in this thread when we know more. Thanks all for help with getting repro steps found!

For me the crash on launch has been resolved in the released 0.7.3291.0 build. 馃槃

True, it doesn't crash when I move between windows now, but if I then maximize it, it immediately crashes. As before, if I open a second tab before maximizing, it does not crash.

Not yet resolved, but getting better.

:tada:This issue was addressed in #3832, which has now been successfully released as Windows Terminal Preview v0.7.3382.0.:tada:

Handy links:

:tada:This issue was addressed in #3181, which has now been successfully released as Windows Terminal Preview v0.8.10091.0.:tada:

Handy links:

This keeps happening without failure when I am :

  • Resizing Windows Terminal which contains at least three Ubuntu 20.04 LTS (for my case) terminal in it horizontally and vertically.
  • Opening a new tab when the existing Ubuntu terminal has been running several commands for quite some time.

Version

Windows Terminal 1.0.1811.0
Windows Terminal Preview 1.1.1812.0

Screenshot

windows_terminal_resizing_bug

@fevernova90 That looks like a new crash to me - would you mind filing a new issue for it? I don't want to muddle up this existing thread with a new crash who's source might be unrelated to the original. Thanks!

@zadjii-msft I have figured out the cause of the my Windows Terminal crashing with multiple tabs after seeing the event logs.

There's one app that hooked up into Windows Terminal, it is RivaTuner Statistics Server (which comes bundled when you installed MSI Afterburner).
RivaTuner may have detected that Windows Terminal is a full screen application and try to display hardware statistics in it.

I guess this issue is not relevant to everyone who does not tinkering with their GPU using MSI Afterburner.

Pasting my log here for info

Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.0.1811.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Program Files (x86)\RivaTuner Statistics Server\RTSSHooks64.dll
Report Id: 2ce30154-a6d4-4db0-9d6d-21f916c290a5
Faulting package full name: Microsoft.WindowsTerminal_1.0.1811.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

Ah, that makes sense. We've seen a few crashes like that with people using RivaTuner before. Thanks for following up!

Was this page helpful?
0 / 5 - 0 ratings