Repository navigation
Description
Windows Terminal version
1.13.11431.0
Windows build number
10.0.19044.0
Other Software
bash (inside WSL, Debian)
Steps to reproduce
Do normal work, switch between being connected locally and remotely via RDP (I think the main point here is probably a change in the available displays, e.g. I have 5 monitors at the office and 2 at home - if that for some reason could matter).
In some cases, there will be a lot of text missing (some of it perhaps visible when scrolling back up).
Expected Behavior
I'd expect that executing clear should clear up the window viewport and recover the shell to a fresh state so I could keep working.
Actual Behavior
Resizing the window sometimes forces a redraw and (at least partially) fixes the problem, but running clear in the bash shell to "recover" the terminal to a normal working state in most cases just causes the Terminal window to crash and disappear.
Activity
tovine commentedon Jul 13, 2022
The tricky part about this is that it's not 100% reproducible, but it's happened often enough that I'm fairly certain it's the same issue.
I have captured Event Log files from 3 separate days when this happened, not sure where I can upload them to you (might contain sensitive info, so not suited for attaching here?)
tovine commentedon Jul 13, 2022
Event log details from the crash today:
Previous report is exactly the same (apart from Process ID, time and report id)
zadjii-msft commentedon Jul 13, 2022
There's a small chance that we might be able to look this crash up on the backend if you file feedback via the Feedback Hub, and share the link here: /feedback
If not, I'd recommend the following steps, to try and collect an automatic crash dump of the Terminal:
Can you try following the steps in this post to set up automatic crash dumps? (For more info, see this link) If that works, then you should be able to automatically get a
.dmpof the terminal when it crashes. Then, can you zip that dump up and send it to us, so we can investigate? Thanks!tovine commentedon Jul 13, 2022
I tried recording using the Feedback Hub earlier, but for some reason it wouldn't start (also I guess it'd have to be recording until the issue happened, so that could be running for a while...)
Just enabled WER dumping like the guide in the blog post said:

Does it look correct, or should I add/change anything? Also, where do I send the dump once I get it?
tovine commentedon Jul 15, 2022
It crashed again just now, but no dumps were found in the AppData\Local folder, not even the CrashDumps folder itself - do you have to create that manually first for it to work?
EDIT: could it be related to reaching the end of the scrollback buffer or something? It usually happens when I
clearthe terminal after having had quite a bit of text scroll by. BTW, my History size setting is at 32.6k lines - not sure if that's relevant...briceo commentedon Jul 26, 2022
Mine crashes when I had a large scrollback history. I have my bash terminal set to keep
9999999lines, and when I get a large number of lines in the scrollback buffer, that's whenclearcrashes my windows terminal. And by crash, I should say, it actually freezes, and won't even redraw (becomes unresponsive), and the only thing I can do is to force close the terminal and restart the terminal applicationDHowett commentedon Jul 26, 2022
Interesting. We are supposed to ignore history sizes > 32000 . . .
zadjii-msft commentedon Aug 1, 2022
HMM which distro are you using? I think the
clearimplementation changed between Ubuntu 18.04 and Ubuntu 22.04. Knowing which one in particular might help ID the root cause.FWIW I can't repro this with
historySize: 9999999andclearwith either Ubuntu, but maybe there's something else I'm missing. I'm testing with Terminal 1.16 and there's quite a few changes here since 1.13. Do you have anything like magnifier, narrator, NVDA, anything that listens for UIA events at all? There were a PILE of crashes related to UIA fixed in the last few months...41 remaining items
zadjii-msft commentedon May 5, 2023
Addenda: MSFT:43308096 looks like the inverse frequency - the crashes started going up around 4/12. Interesting. That one's a
~ControlCorea/v, which is kinda similar. No repros of that one in 1.17 either, so that's good.microsoft-github-policy-service commentedon May 9, 2023
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.
microsoft-github-policy-service commentedon May 9, 2023
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.
microsoft-github-policy-service commentedon May 9, 2023
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.
tovine commentedon May 11, 2023
Ok, guess I'll have to chime in to prevent the bot from auto closing?
Nice to see that you're tracking it internally and making progress! :)
FWIW I haven't had any crashes of this kind recently, so you've at least fixed something 🤗
PS: I'm currently on version
1.16.10261.0, installed from the Storezadjii-msft commentedon May 11, 2023
Oh I mean, this seems fixed, you say it's fixed, no one else has chimed in - I think it's just fixed 😄