starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Malformed/Partially destroyed Standard output from Visual studio (& others) #19029

New Issue
Closed
opened 2026-01-31 06:31:43 +00:00 by claunia · 24 comments
claunia commented 2026-01-31 06:31:43 +00:00
Owner
Copy Link

Originally created by @ForgotMyCode on GitHub (Dec 8, 2022).

Windows Terminal version

1.15.2875.0

Windows build number

10.0.22000.1281

Other Software

Microsoft Visual Studio Community 2022 (64-bit) - Current
Version 17.4.2

Steps to reproduce

  1. In Windows Settings, Windows Terminal should be set as default terminal.
  2. In Visual Studio, create new C++ project, with arbitrary name
  3. In arbitrary named .cpp file, insert this sample code:
#include <iostream>

int main() {	
	for(int i = 0; i < 100; ++i) {
		std::cout << i << '\n';

	}
	return 0;
}
  1. Set Release and x64 mode.
  2. Click on "Start Without Debugging" button.
  3. Close the terminal.
  4. Click on "Start Without Debugging" button again.
  5. Scroll up.

Expected Behavior

I would expect to see previous output lines correctly when I scroll up.

Actual Behavior

There is no output above the previously visible text, or the output is malformed.
bug1

Note: Classic console works as expected in this scenario.

Originally created by @ForgotMyCode on GitHub (Dec 8, 2022). ### Windows Terminal version 1.15.2875.0 ### Windows build number 10.0.22000.1281 ### Other Software Microsoft Visual Studio Community 2022 (64-bit) - Current Version 17.4.2 ### Steps to reproduce 1. In Windows Settings, Windows Terminal should be set as default terminal. 2. In Visual Studio, create new C++ project, with arbitrary name 3. In arbitrary named .cpp file, insert this sample code: ``` #include <iostream> int main() { for(int i = 0; i < 100; ++i) { std::cout << i << '\n'; } return 0; } ``` 4. Set Release and x64 mode. 5. Click on "Start **Without** Debugging" button. 6. Close the terminal. 7. Click on "Start **Without** Debugging" button again. 8. Scroll up. ### Expected Behavior I would expect to see previous output lines correctly when I scroll up. ### Actual Behavior There is no output above the previously visible text, or the output is malformed. ![bug1](https://user-images.githubusercontent.com/79061723/206486691-0ea1e283-059e-4667-a28e-461c0b49277f.png) _Note: Classic console works as expected in this scenario._
claunia commented 2026-01-31 06:31:45 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 12, 2022):

I could have sworn there was s dupe for this somewhere on the backlog...

Part of me worries that this is defterm specific. Like, the issue wouldn't repro in the Terminal if you launched the sample exe as wt -- sample.exe.

Does selecting the missing output with the mouse cause it to reappear/? If so, this could be #11214

@zadjii-msft commented on GitHub (Dec 12, 2022): I could have sworn there was s dupe for this somewhere on the backlog... Part of me worries that this is defterm specific. Like, the issue wouldn't repro in the Terminal if you launched the sample exe as `wt -- sample.exe`. Does selecting the missing output with the mouse cause it to reappear/? If so, this could be #11214
claunia commented 2026-01-31 06:31:46 +00:00
Author
Owner
Copy Link

@ForgotMyCode commented on GitHub (Dec 12, 2022):

Does selecting the missing output with the mouse cause it to reappear/?

No, it does not.

I can even select and copy paste everything and the text corresponds to what is visible in the terminal.

In case it has any significance, I did not find a way to reproduce the issue by running the program directly from the terminal (without setting it as default terminal and running it from VS).

@ForgotMyCode commented on GitHub (Dec 12, 2022): > Does selecting the missing output with the mouse cause it to reappear/? No, it does not. I can even select and copy paste everything and the text corresponds to what is visible in the terminal. In case it has any significance, I did not find a way to reproduce the issue by running the program directly from the terminal (without setting it as default terminal and running it from VS).
claunia commented 2026-01-31 06:31:46 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 14, 2022):

This is pretty strange, and I can't reproduce it on VS 17.4.0. Can you share your settings.json? I must be missing something 🙂

@DHowett commented on GitHub (Dec 14, 2022): This is pretty strange, and I can't reproduce it on VS 17.4.0. Can you share your `settings.json`? I must be missing something 🙂
claunia commented 2026-01-31 06:31:46 +00:00
Author
Owner
Copy Link

@ForgotMyCode commented on GitHub (Dec 15, 2022):

Can you share your settings.json?

I figured it may be easier to reproduce if I just reset the settings to default (I erased everything in the settings.json and restarted the terminal). I am still able to reproduce the issue even with default settings. I any case here is my current settings.json:
settings.zip

There is another little detail I have noticed: the scrollbar behaves pretty weird. Before I start scrolling, it is pretty large, as soon as I start scrolling, it gets way smaller:

Before scrolling:

before

When I start scrolling:

after

I can't reproduce it on VS 17.4.0

That is strange, keep in mind it is (usually) necessary to repeat the process (closing terminal and start without debuggin) several times. I have tried reproducing it in a VM, but I could not, although I have a feeling a reason could be the VM is very slow so the text is printed without being buffered or whatever magic is going on behind the scenes.

Edit: Also if I add a little delay (some heavy computation) before the program starts printing, the issue does not occur. Is it possible the terminal is not "initialized" yet?

@ForgotMyCode commented on GitHub (Dec 15, 2022): > Can you share your `settings.json`? I figured it may be easier to reproduce if I just reset the settings to default (I erased everything in the settings.json and restarted the terminal). I am still able to reproduce the issue even with default settings. I any case here is my current settings.json: [settings.zip](https://github.com/microsoft/terminal/files/10239678/settings.zip) There is another little detail I have noticed: the scrollbar behaves pretty weird. Before I start scrolling, it is pretty large, as soon as I start scrolling, it gets way smaller: Before scrolling: ![before](https://user-images.githubusercontent.com/79061723/207938295-6bf51f66-6d5b-4492-a62b-c045a4657811.png) When I start scrolling: ![after](https://user-images.githubusercontent.com/79061723/207938355-4750b64a-2f20-4581-b558-a4c92019dafd.png) > I can't reproduce it on VS 17.4.0 That is strange, keep in mind it is (usually) necessary to repeat the process (closing terminal and start without debuggin) several times. I have tried reproducing it in a VM, but I could not, although I have a feeling a reason could be the VM is very slow so the text is printed without being buffered or whatever magic is going on behind the scenes. Edit: Also if I add a little delay (some heavy computation) before the program starts printing, the issue does not occur. Is it possible the terminal is not "initialized" yet?
claunia commented 2026-01-31 06:31:47 +00:00
Author
Owner
Copy Link

@LucNanquette commented on GitHub (Dec 31, 2022):

I can confirm, that I get exactly the same bug. First I thought it had to do with the 17.5 Preview version of Visual Studio. But even after rolling back from preview, the bug persisted.

I first experienced this bug a few days back. But in that case there was no scrolling involved. Just missing pieces of console output. Like the "Press any key to close this window..." was only displayed as "Press any" and then nothing. But also text in the middle of several outputs was just missing. As I said I fist suspected a bug in Visual Studio, as sometimes the issue could be resolved by switching from debug to release, but then again, this only sometimes worked.

I can reproduce this bug in C# and C++, it doesn't matter.

As has already been stated, a small delay or a Console.Clear() at the beginning solve the issue.

As an example, using Console.WriteLine($"{double.MinValue:N0}\n{double.MaxValue:N0}"); to output the quit large min and max values of doubles: 1st picture without Console.Clear(); 2nd picture with Console.Clear();

image

image

As you can see, in this case some output to the right is just missing. It's not wrapped, but missing.

@LucNanquette commented on GitHub (Dec 31, 2022): I can confirm, that I get exactly the same bug. First I thought it had to do with the 17.5 Preview version of Visual Studio. But even after rolling back from preview, the bug persisted. I first experienced this bug a few days back. But in that case there was no scrolling involved. Just missing pieces of console output. Like the "Press any key to close this window..." was only displayed as "Press any" and then nothing. But also text in the middle of several outputs was just missing. As I said I fist suspected a bug in Visual Studio, as sometimes the issue could be resolved by switching from debug to release, but then again, this only sometimes worked. I can reproduce this bug in C# and C++, it doesn't matter. As has already been stated, a small delay or a Console.Clear() at the beginning solve the issue. As an example, using `Console.WriteLine($"{double.MinValue:N0}\n{double.MaxValue:N0}");` to output the quit large min and max values of doubles: 1st picture without `Console.Clear();` 2nd picture with `Console.Clear();` ![image](https://user-images.githubusercontent.com/63251238/210156203-38e0511f-f9d5-4855-935c-17c50c1d334f.png) ![image](https://user-images.githubusercontent.com/63251238/210156213-adab1bf3-19d7-4698-86a0-0ab236b087d0.png) As you can see, in this case some output to the right is just missing. It's not wrapped, but missing.
claunia commented 2026-01-31 06:31:47 +00:00
Author
Owner
Copy Link

@LucNanquette commented on GitHub (Jan 1, 2023):

Not sure if this helps, but I found that if you leave the terminal window open and then just run the code again, without closing terminal window first, the issue doesn't appear. I can reproduce this all the time; first run = bugs, second run without closing terminal first = no issue.
This also explains, why running the code from the console doesn't get any issues, as the terminal window is already running at that point.
So I guess that @ForgotMyCode is right by assuming it has something to do with the initialization of the terminal. Some sort of buffer problem?
Also I can see, that at the first run, the tab name "Microsoft Visual Studio Debug Console" is followed by some long hex number code? (see screenshot below) This stays for a few seconds before it disappears. On the second run, without closing terminal first, this does not happen.
Also you can see that the test pattern "Testing...{counting}..." is not only cut off at the right, but also misses some chars in between. Scrolling up just reveals empty lines, the first thing displayed being "g...164".

image

@LucNanquette commented on GitHub (Jan 1, 2023): Not sure if this helps, but I found that if you leave the terminal window open and then just run the code again, without closing terminal window first, the issue doesn't appear. I can reproduce this all the time; first run = bugs, second run without closing terminal first = no issue. This also explains, why running the code from the console doesn't get any issues, as the terminal window is already running at that point. So I guess that @ForgotMyCode is right by assuming it has something to do with the initialization of the terminal. Some sort of buffer problem? Also I can see, that at the first run, the tab name "Microsoft Visual Studio Debug Console" is followed by some long hex number code? (see screenshot below) This stays for a few seconds before it disappears. On the second run, without closing terminal first, this does not happen. Also you can see that the test pattern "Testing...{counting}..." is not only cut off at the right, but also misses some chars in between. Scrolling up just reveals empty lines, the first thing displayed being "g...164". ![image](https://user-images.githubusercontent.com/63251238/210162930-d0811ec3-9801-4dea-b23c-d1ef295bf970.png)
claunia commented 2026-01-31 06:31:47 +00:00
Author
Owner
Copy Link

@LucNanquette commented on GitHub (Jan 1, 2023):

But what really puzzles me is the fact, that I have been experiencing this issue first time a few weeks ago. So it could correspond with the release of v1.15.3466.0 2 weeks ago, but going back to v1.15.2875 doesn't solve the issue.
I don't know what I am missing... tried uninstalling/reinstalling, resetting the .json settings... nothing solved the issue yet, appart from switching from terminal to the Windows Console Host, there everything runs fine.

PS: Happy new year to everyone 😁

@LucNanquette commented on GitHub (Jan 1, 2023): But what really puzzles me is the fact, that I have been experiencing this issue first time a few weeks ago. So it could correspond with the release of v1.15.3466.0 2 weeks ago, but going back to v1.15.2875 doesn't solve the issue. I don't know what I am missing... tried uninstalling/reinstalling, resetting the .json settings... nothing solved the issue yet, appart from switching from terminal to the Windows Console Host, there everything runs fine. PS: Happy new year to everyone 😁
claunia commented 2026-01-31 06:31:48 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 3, 2023):

You know what, we play all sorts of silly games on "the first paint" for conpty. I bet there's something fucky going on there with outputting more than a whole screen full of text before ConPTY does it's first frame.

I've been out of the codebase for two weeks, but that's where I'd starts.

#14547 has basically the same repro and side effects. I bet they're the same.

@zadjii-msft commented on GitHub (Jan 3, 2023): You know what, we play all sorts of silly games on "the first paint" for conpty. I bet there's something fucky going on there with outputting more than a whole screen full of text before ConPTY does it's first frame. I've been out of the codebase for two weeks, but that's where I'd starts. #14547 has basically the same repro and side effects. I bet they're the same.
claunia commented 2026-01-31 06:31:48 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 12, 2023):

UNBELEIVABLY[1], I can't repro this on a dev build, but I can on 1.17.3481.0 consistently

I bet this was fixed by the conpty changes in #14544. We don't have that commit in the selfhost build, but we do have it in main.

I guess I could do my diligence and bisect that commit.

  • 165d3edde9 (expected: ✅, actual: ✅)
  • a3c7bc3349 (expected: ❌, actual: ❌) (double checked, this definitely seems ✅ which by all accounts don't make no sense) triple checked, no, this doesn't work
  • (expected: ❌, actual: ❔)
  • b9c3b5cd1e (expected: ❌, actual: ✅) arbitrarily the bottom of page 1
  • (expected: ❌, actual: ❔)
  • da2b80bc0a (expected: ❌, actual: ❌)
  • (expected: ❌, actual: ❔)
  • 4d9a266c12 (expected: ❌, actual: ❌)
  • (expected: ❌, actual: ❔)
  • 0eff8c06e3 (expected: ❌, actual: ❌)
  • (expected: ❌, actual: ❔)
  • 62b34cf6f7 (expected: ❌, actual: ❌) arbitrarily the bottom of page 2

hmm. That's sure weird.

[1]: read as "somehow totally believably"

1/17 update: Did a whole bisect. It finally landed on a3c7bc3349, which is.... nonsense. Seems like the load of the cpu affects this. More likely to hit while building code. Maybe this does still repro on main....

@zadjii-msft commented on GitHub (Jan 12, 2023): UNBELEIVABLY[1], I can't repro this on a dev build, but I can on 1.17.3481.0 consistently I bet this was fixed by the conpty changes in #14544. We don't have that commit in the selfhost build, but we do have it in main. I guess I could do my diligence and bisect that commit. * 165d3edde9ca850f25f7c1e740b5661461fcf175 (expected: ✅, actual: ✅) * a3c7bc3349bfc5bbb07b8295871b06331b5e86b5 (expected: ❌, actual: ❌) ~(double checked, this definitely seems ✅ which by all accounts don't make no sense)~ triple checked, no, this doesn't work * (expected: ❌, actual: ❔) * b9c3b5cd1e72d0509ab3ce2684004122a62ea79c (expected: ❌, actual: ✅) arbitrarily the bottom of page 1 * (expected: ❌, actual: ❔) * da2b80bc0a38f5df49a4b987527decb302d16b7b (expected: ❌, actual: ❌) * (expected: ❌, actual: ❔) * 4d9a266c12d6bdafa88476279e5761f5eb5ff4fc (expected: ❌, actual: ❌) * (expected: ❌, actual: ❔) * 0eff8c06e32bff6c1e8d39e6505ef8a4c6d8ecbf (expected: ❌, actual: ❌) * (expected: ❌, actual: ❔) * 62b34cf6f77199df306999f89a5f57368cfa5059 (expected: ❌, actual: ❌) arbitrarily the bottom of page 2 hmm. That's sure weird. [1]: read as "_somehow totally believably_" <hr> 1/17 update: Did a whole bisect. It finally landed on a3c7bc3349bfc5bbb07b8295871b06331b5e86b5, which is.... nonsense. Seems like the load of the cpu affects this. More likely to hit while building code. Maybe this _does_ still repro on `main`....
claunia commented 2026-01-31 06:31:49 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 17, 2023):

Uhg. I just needed to try more. This must be some strange race, cause I just got this in the current main (4c7879bfb).

How are we gonna debug this? This is intermittent, timing-based, and occurs via defterm. Defterm means we can't use the debug tap. I'd reckon that attaching to VS would probably break the repro.

My assumption from before is where I think I'll start:

You know what, we play all sorts of silly games on "the first paint" for conpty. I bet there's something fucky going on there with outputting more than a whole screen full of text before ConPTY does it's first frame.

We've got two sets of symptoms here:

  • Folks missing lines of output (but the newlines are all seemingly there). This creates blank lines of output in the Terminal
  • Places where the entire line (including the newline) are missing. That results in just skipped numbers, but no blank lines:
    image
@zadjii-msft commented on GitHub (Jan 17, 2023): Uhg. I just needed to try more. This must be some strange race, cause I just got this in the current main (4c7879bfb). How are we gonna debug this? This is intermittent, timing-based, and occurs via defterm. Defterm means we can't use the debug tap. I'd reckon that attaching to VS would probably break the repro. My assumption from before is where I think I'll start: > You know what, we play all sorts of silly games on "the first paint" for conpty. I bet there's something fucky going on there with outputting more than a whole screen full of text before ConPTY does it's first frame. We've got two sets of symptoms here: * Folks missing lines of output (but the newlines are all seemingly there). This creates blank lines of output in the Terminal * Places where the entire line (including the newline) are missing. That results in just skipped numbers, but no blank lines: ![image](https://user-images.githubusercontent.com/18356694/212971412-9aa0e19c-1bbc-49a2-9d76-958d7c697a7f.png)
claunia commented 2026-01-31 06:31:49 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 18, 2023):

I put a test in dev/migrie/b/14512-test-research, but that all passed on main, so maybe this doesn't exactly have to do with the first frame optimizations. I don't think I'll get eyes on this before the 1.17 cutoff.

@zadjii-msft commented on GitHub (Jan 18, 2023): I put a test in `dev/migrie/b/14512-test-research`, but that all passed on `main`, so maybe this doesn't exactly have to do with the first frame optimizations. I don't think I'll get eyes on this before the 1.17 cutoff.
claunia commented 2026-01-31 06:31:49 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 17, 2023):

@zadjii-msft I have the same bug. A simple for loop to print 100 lines will show the first 70 empty (only the ones now in view of the final frame of the console mind you, running it at 120x30, if I increase the height it displays it more correctly to a point).

image

Only with the Windows Terminal, not reproducible choosing Windows Console Host as the default. Only happens at the beginning of the program, if I print 10,000 lines the bug affects the first few hundred.

Tried to reset settings.json to no avail. Reproducible in VStudio, CLion, Codeblocks with msvc, gcc and clang. Not reproducible if debugging.

@ghost commented on GitHub (Apr 17, 2023): @zadjii-msft I have the same bug. A simple for loop to print 100 lines will show the first 70 empty (only the ones now in view of the final frame of the console mind you, running it at 120x30, if I increase the height it displays it _more_ correctly to a point). ![image](https://user-images.githubusercontent.com/114983496/232397523-26a926f1-26eb-44d8-afc3-244f81072332.png) Only with the Windows Terminal, not reproducible choosing Windows Console Host as the default. Only happens at the beginning of the program, if I print 10,000 lines the bug affects the first few hundred. Tried to reset settings.json to no avail. Reproducible in VStudio, CLion, Codeblocks with msvc, gcc and clang. Not reproducible if debugging.
claunia commented 2026-01-31 06:31:50 +00:00
Author
Owner
Copy Link

@LucNanquette commented on GitHub (Apr 17, 2023):

Yeah, still no fix in sight for this?

@LucNanquette commented on GitHub (Apr 17, 2023): Yeah, still no fix in sight for this?
claunia commented 2026-01-31 06:31:50 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 17, 2023):

Scheduled for 1.18 I guess, still no fix. At least it's easy to work around, but it's ugly.

@ghost commented on GitHub (Apr 17, 2023): Scheduled for 1.18 I guess, still no fix. At least it's easy to work around, but it's ugly.
claunia commented 2026-01-31 06:31:50 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 5, 2023):

I think this is fixed in #15298. I want to check that in to 1.18 and actually verify that this issue is resolved in 1.18, before committing that it closes this thread.

@zadjii-msft commented on GitHub (May 5, 2023): I _think_ this is fixed in #15298. I want to check that in to 1.18 and actually verify that this issue is resolved in 1.18, before committing that it closes this thread.
claunia commented 2026-01-31 06:31:51 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 27, 2023):

v1.18.1421.0 fixes the issue for me.

@ghost commented on GitHub (May 27, 2023): [v1.18.1421.0](https://github.com/microsoft/terminal/releases/tag/v1.18.1421.0) fixes the issue for me.
claunia commented 2026-01-31 06:31:51 +00:00
Author
Owner
Copy Link

@whshields commented on GitHub (Jun 6, 2023):

I'm running Visual Studio Community 17.6.2 and I'm getting the same bug. Anything I can add to my code besides Running without Debugging twice to stitch the issue?

@whshields commented on GitHub (Jun 6, 2023): I'm running Visual Studio Community 17.6.2 and I'm getting the same bug. Anything I can add to my code besides Running without Debugging twice to stitch the issue?
claunia commented 2026-01-31 06:31:51 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jun 6, 2023):

I'm running Visual Studio Community 17.6.2 and I'm getting the same bug. Anything I can add to my code besides Running without Debugging twice to stitch the issue?

Why not update the Terminal?

You can add a small delay, that's what I did to work around it. Like 50-60 ms or so before you start printing. Or you can switch to the Windows Console.

@ghost commented on GitHub (Jun 6, 2023): > I'm running Visual Studio Community 17.6.2 and I'm getting the same bug. Anything I can add to my code besides Running without Debugging twice to stitch the issue? Why not update the Terminal? You can add a small delay, that's what I did to work around it. Like 50-60 ms or so before you start printing. Or you can switch to the Windows Console.
claunia commented 2026-01-31 06:31:52 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 5, 2023):

@whshields which Terminal version are you using? This is totally just a bug in the Terminal, regardless of VS version.

I'm really tempted to just close this out now. We seemingly haven't gotten any reports of this in the last month, and it was a pretty noisy bug before that.

@zadjii-msft commented on GitHub (Jul 5, 2023): @whshields which Terminal version are you using? This is totally just a bug in the Terminal, regardless of VS version. I'm really tempted to just close this out now. We seemingly haven't gotten any reports of this in the last month, and it was a pretty noisy bug before that.
claunia commented 2026-01-31 06:31:52 +00:00
Author
Owner
Copy Link

@ForgotMyCode commented on GitHub (Jul 5, 2023):

In case it has any weight, I am still able to reproduce the bug even using the latest (stable) versions (Terminal 1.17.11461.0; VS 17.6.4), but I have noticed it is not consistently reproducible (that said in my case the output is destroyed in almost 100 % of cases), probably depends on a machine's performance if not other factors.

@ForgotMyCode commented on GitHub (Jul 5, 2023): In case it has any weight, I am still able to reproduce the bug even using the latest (stable) versions (Terminal 1.17.11461.0; VS 17.6.4), but I have noticed it is not consistently reproducible (that said in my case the output is destroyed in almost 100 % of cases), probably depends on a machine's performance if not other factors.
claunia commented 2026-01-31 06:31:52 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 5, 2023):

That would make sense - the PR I think fixed this (#15298) is only in 1.18 (Preview) builds currently.

@zadjii-msft commented on GitHub (Jul 5, 2023): That would make sense - the PR I think fixed this (#15298) is only in 1.18 (Preview) builds currently.
claunia commented 2026-01-31 06:31:53 +00:00
Author
Owner
Copy Link

@ForgotMyCode commented on GitHub (Jul 5, 2023):

@zadjii-msft I have tried the preview version, the issue seems to be fixed, well done! So, at least from my side this issue can be closed, if that's ok with you.

@ForgotMyCode commented on GitHub (Jul 5, 2023): @zadjii-msft I have tried the preview version, the issue seems to be fixed, well done! So, at least from my side this issue can be closed, if that's ok with you.
claunia commented 2026-01-31 06:31:53 +00:00
Author
Owner
Copy Link

@SurfinPixelBird commented on GitHub (Jul 6, 2023):

hi i have the same issue since i upgrade to win 11.
you can set the console to legacy mode to use a older console.
RESTART YOUR PC!!!
the output is as expected

legacy

6 hours for a for loop such a workflow

i can confirm that is not a vs bug.
i had the same behaviour with qt.

@SurfinPixelBird commented on GitHub (Jul 6, 2023): hi i have the same issue since i upgrade to win 11. you can set the console to legacy mode to use a older console. RESTART YOUR PC!!! the output is as expected ![legacy](https://github.com/microsoft/terminal/assets/118484933/94f8c9e6-7997-40b7-b5b8-e427ad915ce2) 6 hours for a for loop such a workflow i can confirm that is not a vs bug. i had the same behaviour with qt.
claunia commented 2026-01-31 06:31:53 +00:00
Author
Owner
Copy Link

@ForgotMyCode commented on GitHub (Jul 13, 2023):

Fixed in v1.18.

@ForgotMyCode commented on GitHub (Jul 13, 2023): Fixed in v1.18.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-DefApp In-PR Issue-Bug Needs-Tag-Fix Product-Conpty Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#19029
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?