Spurious ";1_" printed to screen when clicking on Terminal in a Hyper-V basic session

[DHowett]

This has been happening for quite a while, and I bet there's a pretty simple explanation.

It might happen when you activate the Hyper-V vmconnect window.

Admittedly, I can't reproduce it on the Windows Evaluation VM with 1.17 to grab a screenshot, but it has happened to me enough times that I know it's lurking in there.

---

1. Start a VM running Windows 11+
2. Connect to it in Virtual Machine Connection, rejecting the enhanced session prompt
3. Launch Terminal
4. Focus on something other than the VMC window.
5. Click on the Terminal window within the VMC window.
6. Observe ;1_ is typed.

[elsaco]

Screenshot using Win10 and latest WinDev2308Eval vm:

[zadjii-msft]

Hey @elsaco since you can get a live repro - can you grab a debug tap trace? That should include the actual key that's causing this in red text.

[joncarmsft]

PS␣C:\Users\Jon>␣␛[9;15;9;0;0;1_␛[16;42;0;0;0;1_␛[16;54;0;0;256;1_␛[17;29;0;0;0;1_␛[17;29;0;0;256;1_␛[9;15;9;0;0;1_␛[18;56;0;0;0;1_␛[9;15;9;0;0;1_␛[18;56;0;0;0;1_␛[9;15;9;0;0;1_␛[9;15;9;0;0;1_␛[16;42;0;0;0;1_␛[16;54;0;0;256;1_␛[17;29;0;0;0;1_␛[17;29;0;0;256;1_␛[9;15;9;0;0;1_␛[18;56;0;0;0;1_␛[9;15;9;0;0;1_␛[18;56;0;0;0;1_␛[9;15;9;0;0;1_␛[37m;␛[93m1_␛[m␛[9;15;9;0;0;1_␛[16;42;0;0;0;1_␛[16;54;0;0;256;1_␛[17;29;0;0;0;1_␛[17;29;0;0;256;1_␛[9;15;9;0;0;1_␛[18;56;0;0;0;1_␛[9;15;9;0;0;1_␛[18;56;0;0;0;1_␛[9;15;9;0;0;1_␛[44;55;0;0;256;1_␛[9;15;9;0;0;1_␛[16;42;0;0;0;1_␛[16;54;0;0;256;1_␛[17;29;0;0;0;1_␛[17;29;0;0;256;1_␛[9;15;9;0;0;1_␛[18;56;0;0;0;1_␛[9;15;9;0;0;1_␛[18;56;0;0;0;1_␛[9;15;9;0;0;1_␛[9;15;9;0;0;1_␛[16;42;0;0;0;1_␛[16;54;0;0;256;1_␛[17;29;0;0;0;1_␛[17;29;0;0;256;1_␛[9;15;9;0;0;1_␛[18;56;0;0;0;1_␛[9;15;9;0;0;1_␛[18;56;0;0;0;1_␛[9;15;9;0;0;1_␛[O

In the above everything is red, except PS␣C:\Users\Jon> and ␛[37m;␛[93m1_␛[m is white.

[zadjii-msft]

everything before the ;1_

Vk	Sc	Uc	Kd	Cs
VK_TAB	15	9	up	0
VK_SHIFT	42	0	up	0
VK_SHIFT	54	0	up	256
VK_CONTROL	29	0	up	0
VK_CONTROL	29	0	up	256
VK_TAB	15	9	up	0
VK_MENU	56	0	up	0
VK_TAB	15	9	up	0
VK_MENU	56	0	up	0
VK_TAB	15	9	up	0
VK_TAB	15	9	up	0
VK_SHIFT	42	0	up	0
VK_SHIFT	54	0	up	256
VK_CONTROL	29	0	up	0
VK_CONTROL	29	0	up	256
VK_TAB	15	9	up	0
VK_MENU	56	0	up	0
VK_TAB	15	9	up	0
VK_MENU	56	0	up	0
VK_TAB	15	9	up	0

[zadjii-msft]

I'm trying to find the thread I'm thinking of

• not Random parsing/rendering bugs when input arrives slowly #3086, this is specifically output related
• I think it's terminal/parser: determine what to do when split escape sequence writes show up #4037

It might not be that exactly. Looks like this was a super long input sequence that got chopped at some point, and then conpty only got a part of a sequence. Interesting to me that ;1_ was all that got printed. Does that mean conpty read the preceeding ␛[9;15;9;0;0, got to the end of the input , then just ignored the sequence? Maybe. I'd have to cache that back in.

There's some other silly things we might be able to do to mitigate this:

• The buffer in VtInputThread::DoReadInput is 256 chars. It looks to me like there was about 317 that got written before the input sequence got chopped.
• We could maybe be even smarter, and if we read a whole buffer worth of chars, then keep reading till we run out, then pump the string into the state machine to process.
• More aggressively flush the WriteFile on the Terminal side?

[zadjii-msft]

As @DHowett observed in chat:

There is a ;1_ that lines up exactly with the 255 boundary. I should have been looking that way, not at the length before it was echoed to the screen.