Terminal crashes when dragged to another monitor #4609

@DHowett-MSFT commented on GitHub (Oct 24, 2019):

/feedback

@DHowett-MSFT commented on GitHub (Oct 24, 2019): /feedback

claunia commented

@ghost commented on GitHub (Oct 24, 2019):

Hi there!

Can you please send us feedback with the Feedback Hub with this issue and paste the link here so we can more easily find your crash information on the back end?

Thanks!

@ghost commented on GitHub (Oct 24, 2019): Hi there! Can you please send us feedback with the Feedback Hub with this issue and paste the link here so we can more easily find your crash information on the back end? Thanks! ![image](https://user-images.githubusercontent.com/18221333/62478757-b69d0d00-b760-11e9-9626-1fa33c91e7c5.png) ![image](https://user-images.githubusercontent.com/18221333/62478649-6de55400-b760-11e9-806e-5aab7e085a9f.png)

claunia commented

@9jaGuy commented on GitHub (Oct 24, 2019):

https://aka.ms/AA6eg31

@9jaGuy commented on GitHub (Oct 24, 2019): https://aka.ms/AA6eg31

claunia commented

@aaroneuph commented on GitHub (Oct 24, 2019):

This is also happening for me after upgrading to the latest windows-terminal version. My monitors are all the same resolution though. I can confirm that the issue doesn't occur with multiple tabs open.

Windows build number: Microsoft Windows [Version 10.0.18362.0]
Windows Terminal Version: 0.6.2951.0

@aaroneuph commented on GitHub (Oct 24, 2019): This is also happening for me after upgrading to the latest windows-terminal version. My monitors are all the same resolution though. I can confirm that the issue doesn't occur with multiple tabs open. Windows build number: Microsoft Windows [Version 10.0.18362.0] Windows Terminal Version: 0.6.2951.0

claunia commented

@flickerfly commented on GitHub (Oct 24, 2019):

Same experience on Windows 10 with 0.6.2951.0. Adding another tab is a simple work around (Thanks @skylarnam for noticing that.)

Here's the feedback info that hopefully has the details you need: https://aka.ms/AA6e2dw

@flickerfly commented on GitHub (Oct 24, 2019): Same experience on Windows 10 with 0.6.2951.0. Adding another tab is a simple work around (Thanks @skylarnam for noticing that.) Here's the feedback info that hopefully has the details you need: https://aka.ms/AA6e2dw

claunia commented

@flickerfly commented on GitHub (Oct 24, 2019):

Scenario #1) If I open WSL and close PowerShell, (having one tab with WSL open) then drag over it works fine. If I then open PowerShell and close WSL and drag to any monitor it works until I try dragging from my primary display onto another display.

Scenario #2) If I open Terminal, add a WSL tab, close the PowerShell tab, then open a new PowerShell tab and close WSL. Then drag from the primary display to another it crashes.

Conclusions: This only impacts dragging from the primary display when a PowerShell tab is the only open tab, but not necessarily the first open tab.

@flickerfly commented on GitHub (Oct 24, 2019): _Scenario_ #1) If I open WSL and close PowerShell, (having one tab with WSL open) then drag over it works fine. If I then open PowerShell and close WSL and drag to any monitor it works until I try dragging from my primary display onto another display. _Scenario_ #2) If I open Terminal, add a WSL tab, close the PowerShell tab, then open a new PowerShell tab and close WSL. Then drag from the primary display to another it crashes. _Conclusions:_ This only impacts dragging from the primary display when a PowerShell tab is the only open tab, but not necessarily the first open tab.

claunia commented

@CosmicCatnap commented on GitHub (Oct 24, 2019):

Scenario #1) If I open WSL and close PowerShell, (having one tab with WSL open) then drag over it works fine. If I then open PowerShell and close WSL and drag to any monitor it works until I try dragging from my primary display onto another display.

Scenario #2) If I open Terminal, add a WSL tab, close the PowerShell tab, then open a new PowerShell tab and close WSL. Then drag from the primary display to another it crashes.

Conclusions: This only impacts dragging from the primary display when a PowerShell tab is the only open tab, but not necessarily the first open tab.

Seeing this behavior as well. My default start behavior is to open a WSL session which will die upon letting go of the mouse click after dragging the terminal window to any other monitor. If I have cmd as my first tab then drag+drop works fine. Its clearly dying when letting go of the click, not on the drag.

@CosmicCatnap commented on GitHub (Oct 24, 2019): > > > _Scenario_ #1) If I open WSL and close PowerShell, (having one tab with WSL open) then drag over it works fine. If I then open PowerShell and close WSL and drag to any monitor it works until I try dragging from my primary display onto another display. > > _Scenario_ #2) If I open Terminal, add a WSL tab, close the PowerShell tab, then open a new PowerShell tab and close WSL. Then drag from the primary display to another it crashes. > > _Conclusions:_ This only impacts dragging from the primary display when a PowerShell tab is the only open tab, but not necessarily the first open tab. Seeing this behavior as well. My default start behavior is to open a WSL session which will die upon letting go of the mouse click after dragging the terminal window to any other monitor. If I have cmd as my first tab then drag+drop works fine. Its clearly dying when letting go of the click, not on the drag.

claunia commented

@skylarnam commented on GitHub (Oct 24, 2019):

Hi, I just sent a feedback using the Feedback Hub. Thanks everyone for more details.

https://aka.ms/AA6e9sl

@skylarnam commented on GitHub (Oct 24, 2019): Hi, I just sent a feedback using the Feedback Hub. Thanks everyone for more details. https://aka.ms/AA6e9sl

claunia commented

@waltiam commented on GitHub (Oct 25, 2019):

It has nothing to do with the drag ... the same crash behaviour is exhibited if you use the windows + arrow keys

@waltiam commented on GitHub (Oct 25, 2019): It has nothing to do with the drag ... the same crash behaviour is exhibited if you use the windows + arrow keys

claunia commented

@decstewartje commented on GitHub (Oct 25, 2019):

Nasty bug... thanks for the workaround with the two tabs!

@decstewartje commented on GitHub (Oct 25, 2019): Nasty bug... thanks for the workaround with the two tabs!

claunia commented

@winstonhenke commented on GitHub (Oct 28, 2019):

For me the multiple tabs work around only works if one of the tabs is CMD

edit: Also noticed it's only when moving from my laptop screen(4k) to an external monitor(1080p). Moving between my external monitors seems fine. Maybe due to them using different graphic cards?

@winstonhenke commented on GitHub (Oct 28, 2019): For me the multiple tabs work around only works if one of the tabs is CMD edit: Also noticed it's only when moving from my laptop screen(4k) to an external monitor(1080p). Moving between my external monitors seems fine. Maybe due to them using different graphic cards?

claunia commented

@CosmicCatnap commented on GitHub (Oct 28, 2019):

It has nothing to do with the drag ... the same crash behaviour is exhibited if you use the windows + arrow keys

which is 100% what I said.

@CosmicCatnap commented on GitHub (Oct 28, 2019): > > > It has nothing to do with the drag ... the same crash behaviour is exhibited if you use the windows + arrow keys which is 100% what I said.

claunia commented

@lbalmont commented on GitHub (Oct 30, 2019):

I have open the #3376 bu it's same issue, just I add : when it's on the same Graphic card, it's ok (4K to 1080p ok), but not when I drag and drop from screen on my external card to a screen on my internal card. Same workaround, it's ok with 2 tabs.

@lbalmont commented on GitHub (Oct 30, 2019): I have open the #3376 bu it's same issue, just I add : when it's on the same Graphic card, it's ok (4K to 1080p ok), but not when I drag and drop from screen on my external card to a screen on my internal card. Same workaround, it's ok with 2 tabs.

claunia commented

@adrianmoya commented on GitHub (Oct 30, 2019):

Just hit this bug. The multiple tabs with cmd workaround is the only thing that works for me.

@adrianmoya commented on GitHub (Oct 30, 2019): Just hit this bug. The multiple tabs with cmd workaround is the only thing that works for me.

claunia commented

@zadjii-msft commented on GitHub (Nov 1, 2019):

Based off some other issues, this may or may not be related to #2277.

@zadjii-msft commented on GitHub (Nov 1, 2019): Based off some other issues, this may or may not be related to #2277.

claunia commented

@zadjii-msft commented on GitHub (Nov 6, 2019):

I've certainly been having some difficulty repro'ing this, though this is hitting a good number of people. If someone who can repro this consistently could help debug, that'd be much appreciated :)

@zadjii-msft commented on GitHub (Nov 6, 2019): I've certainly been having some difficulty repro'ing this, though this is hitting a good number of people. If someone who can repro this consistently could help debug, that'd be much appreciated :)

claunia commented

@Julien-Marcou commented on GitHub (Nov 6, 2019):

I can consistently reproduce it when I set Ubuntu-18.04 as the default profile, it does not happen when openning Windows PowerShell or cmd.

Then I also have to quickly drag Terminal to another monitor, while it is still loading Ubuntu, if I wait a few seconds for the command prompt to be ready, then I can safely move Terminal to another monitor without it crashing.

@Julien-Marcou commented on GitHub (Nov 6, 2019): I can consistently reproduce it when I set Ubuntu-18.04 as the default profile, it does not happen when openning Windows PowerShell or cmd. Then I also have to quickly drag Terminal to another monitor, while it is still loading Ubuntu, if I wait a few seconds for the command prompt to be ready, then I can safely move Terminal to another monitor without it crashing.

claunia commented

@LukaszMendakiewicz commented on GitHub (Nov 6, 2019):

Similar here -- it happens when I drag while the script setting up my development environment is running. If I wait for it to finish then it is safe to move. In my case it is PowerShell-based profile.
I can provide a dump on Microsoft-internal share.

@LukaszMendakiewicz commented on GitHub (Nov 6, 2019): Similar here -- it happens when I drag while the script setting up my development environment is running. If I wait for it to finish then it is safe to move. In my case it is PowerShell-based profile. I can provide a dump on Microsoft-internal share.

claunia commented

@zadjii-msft commented on GitHub (Nov 6, 2019):

Woah holy crap, that does it. Thanks @Julien-Marcou!

@zadjii-msft commented on GitHub (Nov 6, 2019): Woah holy crap, that does it. Thanks @Julien-Marcou!

claunia commented

@zadjii-msft commented on GitHub (Nov 6, 2019):

Okay so it's even more challenging that just dragging it to another display while it's starting up. It specifically crashes if the title is changing when you drag it to the other display. I'm not sure if it has to change exactly during the drag, or how it's related, but now that I have a little script repros this consistently, I can investigate more.

@zadjii-msft commented on GitHub (Nov 6, 2019): Okay so it's even more challenging that just dragging it to another display while it's starting up. It specifically crashes if the title is changing when you drag it to the other display. I'm not sure if it has to change exactly during the drag, or how it's related, but now that I have a little script repros this consistently, I can investigate more.

claunia commented

@adrianmoya commented on GitHub (Nov 6, 2019):

Yes, I think this started to happen for me when I set the ubuntu 18.04 terminal as default, so that's a good thing to check.

@adrianmoya commented on GitHub (Nov 6, 2019): Yes, I think this started to happen for me when I set the ubuntu 18.04 terminal as default, so that's a good thing to check.

claunia commented

@skylarnam commented on GitHub (Nov 6, 2019):

Unlike a few of the recent comments, as just a heads-up, I get consistent repros w/o having Ubuntu set up as my default profile. I have powershell and cmd as my profiles and the first is my default one.

@skylarnam commented on GitHub (Nov 6, 2019): Unlike a few of the recent comments, as just a heads-up, I get consistent repros w/o having Ubuntu set up as my default profile. I have powershell and cmd as my profiles and the first is my default one.

claunia commented

@zadjii-msft commented on GitHub (Nov 6, 2019):

Update:

I wrote a little script that changes the title every .25s. If you moved the Terminal window across a DPI border while it was running, it would almost instantly crash into the debugger. However, I had a hypothesis why it was so hard to get this to repro earlier today. I did a quick git bisect to find out why:

✔ This crash doesn't repro in master, fee3fdf
❌ This crash repros in 0.6, d6790c0
❌ This crash repros in 6f36f8b
✔ This crash doesn't repro in 5dfc021 🎉

So it looks like #3394 actually fixes this bug too. Thanks @greg904!

@zadjii-msft commented on GitHub (Nov 6, 2019): Update: I wrote a little script that changes the title every .25s. If you moved the Terminal window across a DPI border while it was running, it would almost instantly crash into the debugger. However, I had a hypothesis why it was so hard to get this to repro earlier today. I did a quick git bisect to find out why: * ✔ This crash _doesn't_ repro in `master`, fee3fdf * ❌ This crash repros in 0.6, d6790c0 * ❌ This crash repros in 6f36f8b * ✔ This crash _doesn't_ repro in 5dfc021 🎉 So it looks like #3394 actually fixes this bug too. Thanks @greg904!

claunia commented

@beviu commented on GitHub (Nov 6, 2019):

@zadjii-msft I think I found a way to reproduce the crash even in master (or maybe it's another bug?):

have primary monitor with 100% scaling and second monitor with 150% scaling
open terminal (it opens in primary monitor)
move it to the second monitor
notice how the min/max/close buttons are blurry (already weird)
put your mouse cursor over the min/max/close buttons and notice how they become sharp again
move the terminal back to the primary monitor
notice how the min/max/close buttons are blurry
put your mouse cursor over the min/max/close buttons and the terminal crashes

There is no crash when multiple tabs are opened.

Also, I don't know if it's related but when it moves from one monitor to another it prints this in the output in Visual Studio:

onecoreuap\windows\wgi\winrt\display\displaycommon.cpp(411)\Windows.Graphics.dll!00007FFF221904B0: (caller: 00007FFF2219017A) ReturnHr(22) tid(19f0) 80070490 Element not found.
onecoreuap\windows\wgi\winrt\display\displaycommon.cpp(411)\Windows.Graphics.dll!00007FFF221904B0: (caller: 00007FFF221901F5) ReturnHr(23) tid(19f0) 80070490 Element not found.

@beviu commented on GitHub (Nov 6, 2019): @zadjii-msft I think I found a way to reproduce the crash even in `master` (or maybe it's another bug?): - have primary monitor with 100% scaling and second monitor with 150% scaling - open terminal (it opens in primary monitor) - move it to the second monitor - notice how the min/max/close buttons are blurry (already weird) - put your mouse cursor over the min/max/close buttons and notice how they become sharp again - move the terminal back to the primary monitor - notice how the min/max/close buttons are blurry - put your mouse cursor over the min/max/close buttons and the terminal crashes There is no crash when multiple tabs are opened. Also, I don't know if it's related but when it moves from one monitor to another it prints this in the output in Visual Studio: ``` onecoreuap\windows\wgi\winrt\display\displaycommon.cpp(411)\Windows.Graphics.dll!00007FFF221904B0: (caller: 00007FFF2219017A) ReturnHr(22) tid(19f0) 80070490 Element not found. onecoreuap\windows\wgi\winrt\display\displaycommon.cpp(411)\Windows.Graphics.dll!00007FFF221904B0: (caller: 00007FFF221901F5) ReturnHr(23) tid(19f0) 80070490 Element not found. ```

claunia commented

@zadjii-msft commented on GitHub (Nov 6, 2019):

@greg904 oh no

I can't get it to repro with those steps at all ;__;

I definitely see the blurriness you're talking about, but I don't get the crash to happen with the same setup.

The logging there is a message I've seen plenty of before - usually it's not fatal, but I never really knew what was causing it.

@zadjii-msft commented on GitHub (Nov 6, 2019): @greg904 oh no I can't get it to repro with those steps at all ;__; I definitely see the blurriness you're talking about, but I don't get the crash to happen with the same setup. The logging there is a message I've seen plenty of before - usually it's not fatal, but I never really knew what was causing it.

claunia commented

@beviu commented on GitHub (Nov 6, 2019):

@zadjii-msft It looks like it depends on the title of the default profile. When I set it to "aaaaaaaaaaaaa" it crashes but with just "aaa" or "aaaaaaaaaaaaaaaaaaaaaaaaaa" it doesn't (I tried multiple times for each one and it seems consistent). Also with the default config ("Windows PowerShell") it crashes.

@beviu commented on GitHub (Nov 6, 2019): @zadjii-msft It looks like it depends on the title of the default profile. When I set it to "aaaaaaaaaaaaa" it crashes but with just "aaa" or "aaaaaaaaaaaaaaaaaaaaaaaaaa" it doesn't (I tried multiple times for each one and it seems consistent). Also with the default config ("Windows PowerShell") it crashes.

claunia commented

@zadjii-msft commented on GitHub (Nov 6, 2019):

aaaaaaaaaaaaa

welp. That's insane, but it works. I'll dig in farther in the morning.

@zadjii-msft commented on GitHub (Nov 6, 2019): > aaaaaaaaaaaaa welp. That's _insane_, but it works. I'll dig in farther in the morning.

claunia commented

357e835f5d/src/cascadia/TerminalApp/TitlebarControl.cpp (L37-L50)

@zadjii-msft commented on GitHub (Nov 7, 2019):

Hokay. So, the problematic line of code here is L48 in TitleBarControl.cpp

Looks like that MaxWidth call is causing a change in some other element of the application, which is then eventually causing the TitlebarControl's root to change size again. Here, ContentRoot is hosting the TabRowControl, which is mostly just a wrapper for the TabView.

That code exists to make sure that that tab row doesn't push the caption buttons off the side of the window. Without it, this doesn't repro anymore. However, this happens:

The "X" has been pushed off the window, and the drag region is partially obscuring the last tab.

So I'll either need to find a way to:

Find way to not have the tab row push the caption buttons off the side of the window
prevent the layout cycle caused by that MaxWidth call.

@zadjii-msft commented on GitHub (Nov 7, 2019): Hokay. So, the problematic line of code here is L48 in TitleBarControl.cpp https://github.com/microsoft/terminal/blob/357e835f5d37492812e33eac1dd995232c19de63/src/cascadia/TerminalApp/TitlebarControl.cpp#L37-L50 Looks like that `MaxWidth` call is causing a change in some other element of the application, which is then eventually causing the TitlebarControl's root to change size again. Here, `ContentRoot` is hosting the `TabRowControl`, which is mostly just a wrapper for the `TabView`. That code exists to make sure that that tab row doesn't push the caption buttons off the side of the window. Without it, this doesn't repro anymore. However, _this_ happens: ![image](https://user-images.githubusercontent.com/18356694/68397723-4031f180-0139-11ea-8d04-eb6b20b5cc28.png) The "X" has been pushed off the window, and the drag region is partially obscuring the last tab. So I'll either need to find a way to: 1. Find way to not have the tab row push the caption buttons off the side of the window 2. prevent the layout cycle caused by that `MaxWidth` call.

claunia commented

@beviu commented on GitHub (Nov 7, 2019):

I actually have already done a PR that does this: #3347 (but I need to fix the merge conflicts and I found a bug with it so I need to fix it).

However I'm not sure if that it fixed the root cause of the crash because the PR patches the crash with the repro I posted just before but I found yet another repro to crash that isn't fixed by the PR:

have primary monitor with 100% scaling and second monitor with 150% scaling
open terminal with default config (it opens in primary monitor)
move it to the second monitor
click on the maximize button
click on the restore button
move the terminal back to the primary monitor
notice how the min/max/close buttons are blurry
put your mouse cursor over the min/max/close buttons and the terminal crashes

@beviu commented on GitHub (Nov 7, 2019): I actually have already done a PR that does this: #3347 (but I need to fix the merge conflicts and I found a bug with it so I need to fix it). However I'm not sure if that it fixed the root cause of the crash because the PR patches the crash with the repro I posted just before but I found yet another repro to crash that isn't fixed by the PR: - have primary monitor with 100% scaling and second monitor with 150% scaling - open terminal with default config (it opens in primary monitor) - move it to the second monitor - click on the maximize button - click on the restore button - move the terminal back to the primary monitor - notice how the min/max/close buttons are blurry - put your mouse cursor over the min/max/close buttons and the terminal crashes

claunia commented

@zadjii-msft commented on GitHub (Nov 7, 2019):

@greg904 haha, I literally just finished merging master into that PR to see if it would be a silver bullet to fix this crash. It unfortunately wasn't.

I've also tried a branch where I replace the Grid in the TabRowControl with a RelativePanel, and shockingly that also repros this crash. I'm starting to think that the MaxWidth call wasn't the real problem here, and there's something else going on.

I might let this sit for a day. I think I've gotten to close to the problem, I might need to take a step back and come at it another direction. Feel free to take a look in the meantime 😜

@zadjii-msft commented on GitHub (Nov 7, 2019): @greg904 haha, I literally just finished merging master into that PR to see if it would be a silver bullet to fix this crash. It unfortunately wasn't. I've also tried a branch where I replace the `Grid` in the `TabRowControl` with a `RelativePanel`, and shockingly that _also_ repros this crash. I'm starting to think that the `MaxWidth` call wasn't the real problem here, and there's something else going on. I might let this sit for a day. I think I've gotten to close to the problem, I might need to take a step back and come at it another direction. Feel free to take a look in the meantime 😜

claunia commented

@beviu commented on GitHub (Nov 7, 2019):

I don't know if that helps but when I set the visibility of the mux:TabView to collapsed or when I force its size to say 400 width and 50 height there is no crash. Maybe it's the mux:TabView resize that causes the bug? Here is what is called on resize: 25acf5b783/dev/TabView/TabView.cpp (L526)
I don't how VS enough to put a breakpoint here though.

@beviu commented on GitHub (Nov 7, 2019): I don't know if that helps but when I set the visibility of the `mux:TabView` to collapsed or when I force its size to say 400 width and 50 height there is no crash. Maybe it's the `mux:TabView` resize that causes the bug? Here is what is called on resize: https://github.com/microsoft/microsoft-ui-xaml/blob/25acf5b783d2b93a8f52cb24569d68fd26dbda57/dev/TabView/TabView.cpp#L526 I don't how VS enough to put a breakpoint here though.

claunia commented

@vsalvino commented on GitHub (Nov 7, 2019):

I can also confirm this bug. My steps to reproduce:

System: Windows 10 1909 build 18363.449
Terminal: 0.6.2951.0

Display 1 is laptop, 1920x1080 14" with 150% scaling.
Display 2 is external monitor (HDMI), 1920x1080 24" with 100% scaling.
Terminal opens on Display 1.
When dragging to Display 2, it does not immediately crash, but trying to initiate text input causes it to crash. The problem seems to come when it needs to redraw the contents of the window.

@vsalvino commented on GitHub (Nov 7, 2019): I can also confirm this bug. My steps to reproduce: System: Windows 10 1909 build 18363.449 Terminal: 0.6.2951.0 1. Display 1 is laptop, 1920x1080 14" with 150% scaling. 2. Display 2 is external monitor (HDMI), 1920x1080 24" with 100% scaling. 3. Terminal opens on Display 1. 4. When dragging to Display 2, it does not immediately crash, but trying to initiate text input causes it to crash. The problem seems to come when it needs to redraw the contents of the window.

claunia commented

@dkryaklin commented on GitHub (Nov 8, 2019):

Hello! Same for me. But I even not dragging terminal to another display. I just connect external display as primary and terminal crash immediately :(

@dkryaklin commented on GitHub (Nov 8, 2019): Hello! Same for me. But I even not dragging terminal to another display. I just connect external display as primary and terminal crash immediately :(

claunia commented

@jhoneill commented on GitHub (Nov 9, 2019):

One more here. Nearly opened a duplicate. I'm sure my home setup doesn't have this problem (200% scale on the primary monitor) but hit it in my office set up (125% scale). And stumbled on the 2 panes solution as well. Initially I thought the solution need cmd to be the second pane, but any 2 panes seem to be OK. Happy to provide extra debug info if it helps, but looks like the cause has been found. Just keen to a fix in the next update.

@jhoneill commented on GitHub (Nov 9, 2019): One more here. Nearly opened a duplicate. I'm sure my home setup doesn't have this problem (200% scale on the primary monitor) but hit it in my office set up (125% scale). And stumbled on the 2 panes solution as well. Initially I thought the solution need cmd to be the second pane, but any 2 panes seem to be OK. Happy to provide extra debug info if it helps, but looks like the cause has been found. Just keen to a fix in the next update.

claunia commented

@sotsoguk commented on GitHub (Nov 9, 2019):

One more here. Nearly opened a duplicate. I'm sure my home setup doesn't have this problem (200% scale on the primary monitor) but hit it in my office set up (125% scale). And stumbled on the 2 panes solution as well. Initially I thought the solution need cmd to be the second pane, but any 2 panes seem to be OK. Happy to provide extra debug info if it helps, but looks like the cause has been found. Just keen to a fix in the next update.

For my setup (4k@125% and wqhd @100%) PowerShell is the default shell. With only PowerShell I can move from 4K to other monitor. As soon as i open the anaconda shell as the second tab it crashes when I move. With only one tab this does not happen. Very strange

@sotsoguk commented on GitHub (Nov 9, 2019): > One more here. Nearly opened a duplicate. I'm sure my home setup doesn't have this problem (200% scale on the primary monitor) but hit it in my office set up (125% scale). And stumbled on the 2 panes solution as well. Initially I thought the solution need cmd to be the second pane, but any 2 panes seem to be OK. Happy to provide extra debug info if it helps, but looks like the cause has been found. Just keen to a fix in the next update. For my setup (4k@125% and wqhd @100%) PowerShell is the default shell. With only PowerShell I can move from 4K to other monitor. As soon as i open the anaconda shell as the second tab it crashes when I move. With only one tab this does not happen. Very strange

claunia commented

@CoskunSunali commented on GitHub (Nov 11, 2019):

I'm having the same issue on my setup. Two tabs workaround doesn't help.

Primary monitor is 2K at 125% and other monitors are 1080p at 100%. The app crashes as soon as I move it from the primary monitor to the others.

@CoskunSunali commented on GitHub (Nov 11, 2019): I'm having the same issue on my setup. Two tabs workaround doesn't help. Primary monitor is 2K at 125% and other monitors are 1080p at 100%. The app crashes as soon as I move it from the primary monitor to the others.

claunia commented

@amkoehler commented on GitHub (Nov 11, 2019):

FWIW, dragging works for me using a single tab if that tab is running a program. For example, when I run npm start to start a local webserver I can then drag the window (and use cmd + [arrow key]).

@amkoehler commented on GitHub (Nov 11, 2019): FWIW, dragging works for me using a single tab if that tab is running a program. For example, when I run `npm start` to start a local webserver I can then drag the window (and use `cmd + [arrow key]`).

claunia commented

@JustinGrote commented on GitHub (Nov 12, 2019):

My notes: Win-Shift-Left and Win-Shift-Right work fine, its just when "dragging" the window.

@JustinGrote commented on GitHub (Nov 12, 2019): My notes: Win-Shift-Left and Win-Shift-Right work fine, its just when "dragging" the window.

claunia commented

@dansanduleac commented on GitHub (Nov 12, 2019):

I'm hitting the exact same issue on 2 monitors, but for me it crashes on startup no matter what.

Specifically it's crashing at the exact same fault offset mentioned in https://github.com/microsoft/terminal/issues/3539, which I see was marked as a dupe of this issue.
This occurs on a clean profile too.

Windows 1.0.1910.3002, any recent terminal version.
FWIW in my normal profile the default shell is a WSL2 Ubuntu installation, if that matters.

https://aka.ms/AA6kfpy

@dansanduleac commented on GitHub (Nov 12, 2019): I'm hitting the exact same issue on 2 monitors, but for me it crashes on startup no matter what. Specifically it's crashing at the exact same fault offset mentioned in https://github.com/microsoft/terminal/issues/3539, which I see was marked as a dupe of this issue. This occurs on a clean profile too. Windows 1.0.1910.3002, any recent terminal version. FWIW in my normal profile the default shell is a WSL2 Ubuntu installation, if that matters. https://aka.ms/AA6kfpy

claunia commented

@T313C0mun1s7 commented on GitHub (Nov 15, 2019):

I hope I am not muddying the waters here, but my issues looks like it could possibly be related.

I just switched from a dual monitor setup (2 x 27" @ 1080p with 100% scaling) to a single monitor (32" @ 4k with 125% scaling) and now if I open terminal it opens the window and then crashes straight away. So I am not actually moving a working terminal window to a different display, but rather launching it into a different display environment with the result being that it crashes immediately.

@T313C0mun1s7 commented on GitHub (Nov 15, 2019): I hope I am not muddying the waters here, but my issues looks like it could possibly be related. I just switched from a dual monitor setup (2 x 27" @ 1080p with 100% scaling) to a single monitor (32" @ 4k with 125% scaling) and now if I open terminal it opens the window and then crashes straight away. So I am not actually moving a working terminal window to a different display, but rather launching it into a different display environment with the result being that it crashes immediately.

claunia commented

@eromoe commented on GitHub (Nov 20, 2019):

@T313C0mun1s7 I think it is because terminal remembered the last postition and tried to restore to original possition , then got crushed . Looks like a new problem .

I saw such behavious on some other programs , though them were usually unreachable(invisible) instead of crash .
Moreover, if you are using displayfustion or some else dual taskbar/monitor softwares, they may be the problem too.

@eromoe commented on GitHub (Nov 20, 2019): @T313C0mun1s7 I think it is because terminal remembered the last postition and tried to restore to original possition , then got crushed . Looks like a new problem . I saw such behavious on some other programs , though them were usually unreachable(invisible) instead of crash . Moreover, if you are using displayfustion or some else dual taskbar/monitor softwares, they may be the problem too.

claunia commented

@zadjii-msft commented on GitHub (Nov 26, 2019):

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!

@zadjii-msft commented on GitHub (Nov 26, 2019): 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!

claunia commented

@IlanVivanco commented on GitHub (Nov 26, 2019):

Same problem here.
Multiple tabs workaround only works if one of the tabs is CMD.

@IlanVivanco commented on GitHub (Nov 26, 2019): Same problem here. Multiple tabs workaround only works if one of the tabs is CMD.

claunia commented