Malformed/Partially destroyed Standard output from Visual studio

[ForgotMyCode]

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 (& 17.4.3)

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.

Note: Classic console works as expected in this scenario.

[zadjii-msft]

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

[ForgotMyCode]

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).

[DHowett]

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 🙂

[ForgotMyCode]

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:

When I start scrolling:

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?

[LucNanquette]

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();

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

[LucNanquette]

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".

[LucNanquette]

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 😁

[zadjii-msft]

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]

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"

---

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....

[zadjii-msft]

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:

[zadjii-msft]

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.

[ghost]

@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).

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.

[LucNanquette]

Yeah, still no fix in sight for this?

[ghost]

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

[zadjii-msft]

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.

[ghost]

v1.18.1421.0 fixes the issue for me.

[whshields]

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?

[ghost]

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.

[zadjii-msft]

@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.

[ForgotMyCode]

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.

[zadjii-msft]

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

[ForgotMyCode]

@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.

[SurfinPixelBird]

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

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.

[ForgotMyCode]

Fixed in v1.18.