&#34;Less&#34; pager on Linux closes Windows Terminal #17697

@ghost commented on GitHub (Jun 13, 2022):

Hi there!

Can you please send us feedback with the Feedback Hub with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end?

Thanks!

@ghost commented on GitHub (Jun 13, 2022): Hi there! Can you please send us feedback with the [Feedback Hub](https://support.microsoft.com/en-us/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332) with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end? Thanks! ![image](https://user-images.githubusercontent.com/18356694/140811502-a068f78b-89d2-4587-925a-73e19652b830.png) ![image](https://user-images.githubusercontent.com/18356694/140811557-cdc22a0f-fa6a-4f6a-953e-73b51f5548a3.png) ![image](https://user-images.githubusercontent.com/18221333/62478649-6de55400-b760-11e9-806e-5aab7e085a9f.png)

claunia commented

@azc100 commented on GitHub (Jun 14, 2022):

I have the same problem with Vim (regular vim, not gvim), in Ubuntu 22.04 LTS. After the initial screen of Vim is visualized, the whole Windows Terminal session goes down without any message. I reported the problem on the Feedback Hub, but nobody cared to answer in any way: "WIndows Terminal preview is broken" My version of Windows Terminal Preview is: 1.14.1452.0. Vim is vim 8.2.5085, I recompile it almost every day. Anyway, the problem is present even using the distributed /usr/bin/vim 8.2.3995.

@azc100 commented on GitHub (Jun 14, 2022): I have the same problem with Vim (regular vim, not gvim), in Ubuntu 22.04 LTS. After the initial screen of Vim is visualized, the whole Windows Terminal session goes down without any message. I reported the problem on the Feedback Hub, but nobody cared to answer in any way: "WIndows Terminal preview is broken" My version of Windows Terminal Preview is: 1.14.1452.0. Vim is vim 8.2.5085, I recompile it almost every day. Anyway, the problem is present even using the distributed /usr/bin/vim 8.2.3995.

claunia commented

@zadjii-msft commented on GitHub (Jun 14, 2022):

@azc100 can you find the feedback you filed and share the link to it here? It's kinda hard to find them on the backend without that link 😕

FWIW I'm trying this out with my own Ubuntu 22.04 install over here, with less 590, and I can't repro this with something like less /var/log/dpkg.log.

Idly, I wonder if this is the same crash as #13250. I've got a build that has that PR already merged, so maybe that's why I'm not seeing it.

@zadjii-msft commented on GitHub (Jun 14, 2022): @azc100 can you find the feedback you filed and share the link to it here? It's kinda hard to find them on the backend without that link 😕 FWIW I'm trying this out with my own Ubuntu 22.04 install over here, with `less 590`, and I can't repro this with something like `less /var/log/dpkg.log`. Idly, I wonder if this is the same crash as #13250. I've got a build that has that PR already merged, so maybe that's why I'm not seeing it.

claunia commented

@azc100 commented on GitHub (Jun 14, 2022):

On the Feedback Hub there are no "identifiers". I am attaching an image of the whole thing. I can reproduce the problem at will on my PC. In the Feedback Hub report there is a registration, obtained running "make check" on the vim/src directory, but whatever edit will show the problem.

@azc100 commented on GitHub (Jun 14, 2022): On the Feedback Hub there are no "identifiers". I am attaching an image of the whole thing. I can reproduce the problem at will on my PC. In the Feedback Hub report there is a registration, obtained running "make check" on the vim/src directory, but whatever edit will show the problem. ![Immagine 2022-06-14 130045](https://user-images.githubusercontent.com/19855003/173563035-b5c4bf0a-1baf-42c2-bb98-13e4606b78ec.jpg)

claunia commented

2026-01-31 05:50:39 +00:00

@azc100 commented on GitHub (Jun 14, 2022):

I tried on my PC with less, and indeed it crashes. I don't know about #13250, it does not seem related (to me). Anyway, the problem actually happens if one edits (with vim) a file that is not empty. Just invoking "vim" (without specifying a file) works fine. The bypass is to use gvim instead... The very first invocation is painfully slow, but the further ones are OK.

@azc100 commented on GitHub (Jun 14, 2022): I tried on my PC with less, and indeed it crashes. I don't know about #13250, it does not seem related (to me). Anyway, the problem actually happens if one edits (with vim) a file that is not empty. Just invoking "vim" (without specifying a file) works fine. The bypass is to use gvim instead... The very first invocation is painfully slow, but the further ones are OK.

claunia commented

@zadjii-msft commented on GitHub (Jun 14, 2022):

I bet it's under "Condividi", that looks like the "Share" button ☺️

I'm only guessing it's related, because less and vim are using the alternate screen buffer. Both you and OP mention that it seems to crash on the last line, and the bug at the root of #13183 was an off-by-one at the bottom of the alt buffer.

@zadjii-msft commented on GitHub (Jun 14, 2022): I bet it's under "Condividi", that looks like the "Share" button ☺️ I'm only guessing it's related, because `less` and `vim` are using the alternate screen buffer. Both you and OP mention that it seems to crash _on the last line_, and the bug at the root of #13183 was an off-by-one at the bottom of the alt buffer.

claunia commented

2026-01-31 05:50:39 +00:00

@azc100 commented on GitHub (Jun 14, 2022):

...got it: https://aka.ms/AAh8kuo

@azc100 commented on GitHub (Jun 14, 2022): ...got it: https://aka.ms/AAh8kuo

claunia commented

2026-01-31 05:50:39 +00:00

@azc100 commented on GitHub (Jun 14, 2022):

If I should test something locally, I will gladly do it.

@azc100 commented on GitHub (Jun 14, 2022): If I should test something locally, I will gladly do it.

claunia commented

2026-01-31 05:50:40 +00:00

@zadjii-msft commented on GitHub (Jun 14, 2022):

Hmm. The windowsterminal.exe dump there doesn't actually have a stack track for an exception or crash - it looks like it was running along just fine. Just to be sure - you repro'd the crash while the Feedback Hub was recording, right?

There's like, 3 OpenConsole's and 6 conhosts there though, so maybe one of them has something? I doubt it though, that crashing wouldn't bring down the Terminal.

@zadjii-msft commented on GitHub (Jun 14, 2022): Hmm. The `windowsterminal.exe` dump there doesn't actually have a stack track for an exception or crash - it looks like it was running along just fine. Just to be sure - you repro'd the crash while the Feedback Hub was recording, right? There's like, 3 OpenConsole's and 6 conhosts there though, so maybe one of them has something? I doubt it though, that crashing wouldn't bring down the Terminal.

claunia commented

2026-01-31 05:50:40 +00:00

@azc100 commented on GitHub (Jun 14, 2022):

Yes, the Feedback Hub was recording. And usually I have an authorized Windows Terminal with 5-6 Ubuntus (one of them, root) and a couple of MS-DOS. I could try to reproduce the problem with just one Ubuntu session, if that can help.

@azc100 commented on GitHub (Jun 14, 2022): Yes, the Feedback Hub was recording. And usually I have an authorized Windows Terminal with 5-6 Ubuntus (one of them, root) and a couple of MS-DOS. I could try to reproduce the problem with just one Ubuntu session, if that can help. ![Immagine 2022-06-14 144747](https://user-images.githubusercontent.com/19855003/173580826-b90be4a5-5fb3-49db-90e2-e33b1a573945.jpg)

claunia commented

2026-01-31 05:50:40 +00:00

@azc100 commented on GitHub (Jun 14, 2022):

I tried to get a recording using Vim verbose option, but no file was produced at all, Windows Terminal just went away.

@azc100 commented on GitHub (Jun 14, 2022): I tried to get a recording using Vim verbose option, but no file was produced at all, Windows Terminal just went away.

claunia commented

@Charlweed commented on GitHub (Jun 14, 2022):

I used the feedback app, but I don't use a Microsoft account, so Feedback did not give me a URL to paste.

The behavior does not really "look" like a crash, the Terminal window just closes. I imagine it's as if Less is sending a control sequence that Terminal is interpreting as "Close Window"

@Charlweed commented on GitHub (Jun 14, 2022): I used the feedback app, but I don't use a Microsoft account, so Feedback did not give me a URL to paste. The behavior does not really "look" like a crash, the Terminal window just closes. I imagine it's as if Less is sending a control sequence that Terminal is interpreting as "Close Window"

claunia commented

@azc100 commented on GitHub (Jun 14, 2022):

I agree with Charlweed, in the sense that Windows Terminals closes down, without even worrying about asking the user if it is OK to close all the active sessions. It just shuts down...

@azc100 commented on GitHub (Jun 14, 2022): I agree with Charlweed, in the sense that Windows Terminals closes down, without even worrying about asking the user if it is OK to close all the active sessions. It just shuts down...

claunia commented

@zadjii-msft commented on GitHub (Jun 14, 2022):

Windows Terminals closes down, without even worrying about asking the user if it is OK to close all the active sessions. It just shuts down.

That sounds like a crash to me 😉

@zadjii-msft commented on GitHub (Jun 14, 2022): > Windows Terminals closes down, without even worrying about asking the user if it is OK to close all the active sessions. It just shuts down. That sounds like a crash to me 😉

claunia commented

@azc100 commented on GitHub (Jun 15, 2022):

...more like a hara-kiri.

@azc100 commented on GitHub (Jun 15, 2022): ...more like a hara-kiri.

claunia commented

@zadjii-msft commented on GitHub (Jun 15, 2022):

Hmm. This doesn't repro on the commit before #13250 for me. Lemme do some more bisecting, see if I can even get a repro.

✅ 997b4acce - 1.14.1451
✅ 1de1325cd1 - the commit before the fix
✅ 94e1697a48 - the commit I think fixes it
✅ main

@zadjii-msft commented on GitHub (Jun 15, 2022): Hmm. This doesn't repro on the commit before #13250 for me. Lemme do some more bisecting, see if I can even get a repro. * ✅ 997b4acce - 1.14.1451 * ✅ 1de1325cd1a9ac0c21cdf78750999765c1dfafba - the commit before the fix * ✅ 94e1697a48f08d793a2a852e4f57be790acdeb23 - the commit I think fixes it * ✅ main

claunia commented

@zadjii-msft commented on GitHub (Jun 15, 2022):

Okay, I can't repro this even on the 1.14.1451 commit. I might need someone who can repro it to help confirm if 94e1697a48 fixes it for them.

For folks that are hitting this - Do you have any sort of screen reader running? Narrator, NVDA, JAWS, anything like that? I believe there are other things that try to use the UIA tree, but those are usually the most common

@zadjii-msft commented on GitHub (Jun 15, 2022): Okay, I can't repro this even on the 1.14.1451 commit. I might need someone who can repro it to help confirm if 94e1697a48f08d793a2a852e4f57be790acdeb23 fixes it for them. For folks that are hitting this - Do you have any sort of screen reader running? Narrator, NVDA, JAWS, anything like that? I believe there are other things that try to use the UIA tree, but those are usually the most common

claunia commented

@azc100 commented on GitHub (Jun 15, 2022):

I am not running any software of the above list (Narrator, etc.). I can generate the error (with Vim) very easily, not sure if the Feedback Hub recording could help... If the "hara-kiri" idea holds, one should check when the "close up everything" routine is invoked without a previous prompt for confirmation. If I have to try something locally, I am available.

@azc100 commented on GitHub (Jun 15, 2022): I am not running any software of the above list (Narrator, etc.). I can generate the error (with Vim) very easily, not sure if the Feedback Hub recording could help... If the "hara-kiri" idea holds, one should check when the "close up everything" routine is invoked without a previous prompt for confirmation. If I have to try something locally, I am available.

claunia commented

2026-01-31 05:50:43 +00:00

@azc100 commented on GitHub (Jun 16, 2022):

I reproduced the problem on my PC: see https://aka.ms/AAh8kuo
This time Windows Terminal had only one session running, Ubuntu.

@azc100 commented on GitHub (Jun 16, 2022): I reproduced the problem on my PC: see https://aka.ms/AAh8kuo This time Windows Terminal had only one session running, Ubuntu.

claunia commented

@zadjii-msft commented on GitHub (Jun 16, 2022):

oh ho ho, there was a stowed XAML exception after all!

Looks like uiautomationcore is loaded into all those processes, so someone is using the UIA tree. Dunno if it's possible to find out who.

=========================
@$xamlstowed()                 : 5 ErrorContexts
    length           : 0x5
    [0x0]            : 0x23ac9bce670 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *]
    [0x1]            : 0x23ac9bcc910 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *]
    [0x2]            : 0x23ac9bd3e90 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *]
    [0x3]            : 0x23ac9bd2130 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *]
    [0x4]            : 0x23ac9bd03d0 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *]

That gives me more confidence that this is the thing that #13250 fixed

@zadjii-msft commented on GitHub (Jun 16, 2022): oh ho ho, there was a stowed XAML exception after all! Looks like `uiautomationcore` is loaded into all those processes, so _someone_ is using the UIA tree. Dunno if it's possible to find out who. ``` ========================= @$xamlstowed() : 5 ErrorContexts length : 0x5 [0x0] : 0x23ac9bce670 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *] [0x1] : 0x23ac9bcc910 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *] [0x2] : 0x23ac9bd3e90 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *] [0x3] : 0x23ac9bd2130 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *] [0x4] : 0x23ac9bd03d0 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *] ``` That gives me more confidence that this is the thing that #13250 fixed

claunia commented

2026-01-31 05:50:43 +00:00

@azc100 commented on GitHub (Jun 16, 2022):

I can look into Vim source files, if you tell me what to search for... The only active session under Windows Terminal was Ubuntu (22.04). There was not much else active on the PC, the Feedback Hub, the "cattura e annota" tool, and the usual bunch of system tasks that are usually running (the PC was connected to the Internet).

@azc100 commented on GitHub (Jun 16, 2022): I can look into Vim source files, if you tell me what to search for... The only active session under Windows Terminal was Ubuntu (22.04). There was not much else active on the PC, the Feedback Hub, the "cattura e annota" tool, and the usual bunch of system tasks that are usually running (the PC was connected to the Internet).

claunia commented

2026-01-31 05:50:43 +00:00

@zadjii-msft commented on GitHub (Jun 16, 2022):

~~Any chances this is a touchscreen laptop?~~ wait nevermind, that ususally triggers TSF, not UIA.

I wouldn't be surprised if the screen capture tool invokes UIA. Magnifier and Cursor Highlighting are two other common tools. Unfortunately, it seems like there's not really a good way to try and figure out what invoked UIA 😕

I'd really doubt this is something specific to vim, I'd bet it's anything that uses the alt buffer.

@zadjii-msft commented on GitHub (Jun 16, 2022): ~Any chances this is a touchscreen laptop?~ wait nevermind, that ususally triggers TSF, not UIA. I wouldn't be surprised if the screen capture tool invokes UIA. Magnifier and Cursor Highlighting are two other common tools. Unfortunately, it seems like there's not really a good way to try and figure out _what_ invoked UIA 😕 I'd really doubt this is something specific to `vim`, I'd bet it's anything that uses the alt buffer.

claunia commented

@azc100 commented on GitHub (Jun 25, 2022):

When will a release of Windows Terminal that does not break using Vim be available? Can I build it locally? It is rather annoying not being able to use Vim, especially since I use it everyday. I am presently forced to call it from MS-DOS or to run it on a real Linux PC... Thanks in advance.

@azc100 commented on GitHub (Jun 25, 2022): When will a release of Windows Terminal that does not break using Vim be available? Can I build it locally? It is rather annoying not being able to use Vim, especially since I use it everyday. I am presently forced to call it from MS-DOS or to run it on a real Linux PC... Thanks in advance.

claunia commented

@zadjii-msft commented on GitHub (Aug 1, 2022):

Hey the fix that I think fixed this shipped in Stable https://github.com/microsoft/terminal/releases/tag/v1.14.1861.0, Preview https://github.com/microsoft/terminal/releases/tag/v1.15.1862.0 - can you confirm that one of the 1.*.186*.0 builds fixes this for you/?

@zadjii-msft commented on GitHub (Aug 1, 2022): Hey the fix that I think fixed this shipped in Stable https://github.com/microsoft/terminal/releases/tag/v1.14.1861.0, Preview https://github.com/microsoft/terminal/releases/tag/v1.15.1862.0 - can you confirm that one of the `1.*.186*.0` builds fixes this for you/?

claunia commented

@azc100 commented on GitHub (Aug 4, 2022):

Hi Mike,

Sorry for the delay in answering!

Yes, the problem is now gone with version 1.15.2003.0 of Windows Terminal
Preview (July 26, 2022) (not sure about the git version, I just got it from
the Microsoft Store).

Thanks for everything!

Antonio

@azc100 commented on GitHub (Aug 4, 2022): Hi Mike, Sorry for the delay in answering! Yes, the problem is now gone with version 1.15.2003.0 of Windows Terminal Preview (July 26, 2022) (not sure about the git version, I just got it from the Microsoft Store). Thanks for everything! Antonio

claunia commented