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

Alternate screen buffer escape sequence not changing write destination in recent 1809 build #16592

New Issue
Closed
opened 2026-01-31 05:16:36 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 05:16:36 +00:00
Owner
Copy Link

Originally created by @Gyross on GitHub (Feb 2, 2022).

Windows Terminal version

N/A - Issue is with conhost

Windows build number

10.0.17763.2452

Other Software

conhost.exe 17763.2268
conhostV1.dll 17763.973

Example program used for demonstration, just enables virtual terminal sequences and writes to both the alternate and main buffers:

`

#include <windows.h>
#include <stdio.h>

#define ESC "\x1b"
#define CSI "\x1b["

bool EnableVTMode() {
	HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE);
	if (hOut == INVALID_HANDLE_VALUE) {
		return false;
	}

	DWORD dwMode = 0;
	if (!GetConsoleMode(hOut, &dwMode)) {
		return false;
	}
	
	dwMode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
	if (!SetConsoleMode(hOut, dwMode)) {
		return false;
	}

	return true;
}

int main()
{
	if (!EnableVTMode()) {
		printf("Unable to enter VT processing mode. Quitting.\n");
		return -1;
	}

	// Enter the alternate buffer
	printf(CSI "?1049h");
	
	printf("This should be in the alternate buffer.\n");
	printf("It should not be visible after the program exits.\n");

	Sleep(3000);

	// Exit the alternate buffer
	printf(CSI "?1049l");

	printf("This should be in the main buffer.\n");
	printf("It should be visible in cmd's console window after program exits.\n");

	return 0;
}

`

You can also test with the "Example of Select Anniversary Update Features" from: https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences.

Steps to reproduce

  • Compile example program with Visual Studio 2022, default console app project, Debug target, with static-linked flag (/MTd), v143 toolset.
  • Open cmd.exe and run the example program from within the same console window.

(I also tested with Visual Studio 2019, default console app project, Release target, with default dynamic linking (/MD), v142 toolset).

Expected Behavior

Console window switches to the alternate buffer and displays the text printed after the alternate buffer was opened.
After 3 seconds the console switches back to the main buffer and the text printed to the main buffer is visible.

https://user-images.githubusercontent.com/7597319/152100470-07ed33f1-33c5-41ee-b091-0114afaf1c97.mp4

Works as expected older version of 1809:

  • Win10 1809 17763.1012
  • conhost.exe 17763.404
  • conhostV1.dll 17763.973

Also works on:

  • Win10 20H2 19042.1469

Actual Behavior

Console window switches to the alternate buffer but no text is displayed.
After 3 seconds the console switches back to the main buffer and both the text printed to the alternate and main buffers is visible.
printf sends text to the main buffer despite the alternate buffer being active.

https://user-images.githubusercontent.com/7597319/152100421-bcb92eaf-7c73-48fc-af32-3b6a99e66968.mp4

[The issue also occurs when launching the program on it's own, rather than through cmd. I launched it from cmd in the examples because it demonstrates that output is still written to the main screen buffer.]

Originally created by @Gyross on GitHub (Feb 2, 2022). ### Windows Terminal version N/A - Issue is with conhost ### Windows build number 10.0.17763.2452 ### Other Software conhost.exe 17763.2268 conhostV1.dll 17763.973 Example program used for demonstration, just enables virtual terminal sequences and writes to both the alternate and main buffers: ` #include <windows.h> #include <stdio.h> #define ESC "\x1b" #define CSI "\x1b[" bool EnableVTMode() { HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE); if (hOut == INVALID_HANDLE_VALUE) { return false; } DWORD dwMode = 0; if (!GetConsoleMode(hOut, &dwMode)) { return false; } dwMode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING; if (!SetConsoleMode(hOut, dwMode)) { return false; } return true; } int main() { if (!EnableVTMode()) { printf("Unable to enter VT processing mode. Quitting.\n"); return -1; } // Enter the alternate buffer printf(CSI "?1049h"); printf("This should be in the alternate buffer.\n"); printf("It should not be visible after the program exits.\n"); Sleep(3000); // Exit the alternate buffer printf(CSI "?1049l"); printf("This should be in the main buffer.\n"); printf("It should be visible in cmd's console window after program exits.\n"); return 0; } ` You can also test with the "Example of Select Anniversary Update Features" from: https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences. ### Steps to reproduce - Compile example program with Visual Studio 2022, default console app project, Debug target, with static-linked flag (/MTd), v143 toolset. - Open cmd.exe and run the example program from within the same console window. (I also tested with Visual Studio 2019, default console app project, Release target, with default dynamic linking (/MD), v142 toolset). ### Expected Behavior Console window switches to the alternate buffer and displays the text printed after the alternate buffer was opened. After 3 seconds the console switches back to the main buffer and the text printed to the main buffer is visible. https://user-images.githubusercontent.com/7597319/152100470-07ed33f1-33c5-41ee-b091-0114afaf1c97.mp4 Works as expected older version of 1809: - Win10 1809 17763.1012 - conhost.exe 17763.404 - conhostV1.dll 17763.973 Also works on: - Win10 20H2 19042.1469 ### Actual Behavior Console window switches to the alternate buffer but no text is displayed. After 3 seconds the console switches back to the main buffer and both the text printed to the alternate and main buffers is visible. `printf` sends text to the main buffer despite the alternate buffer being active. https://user-images.githubusercontent.com/7597319/152100421-bcb92eaf-7c73-48fc-af32-3b6a99e66968.mp4 [The issue also occurs when launching the program on it's own, rather than through cmd. I launched it from cmd in the examples because it demonstrates that output is still written to the main screen buffer.]
claunia added the Product-ConhostResolution-Fix-CommittedIssue-BugNeeds-Tag-Fix labels 2026-01-31 05:16:36 +00:00
claunia commented 2026-01-31 05:16:37 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 2, 2022):

How the heck did you even find this? 😅

I'm pretty sure 17763 is really not supposed to be getting any support anymore... That being said, there was a servicing fix we did late last year to port a bugfix to an older release. I forget the version off the top of my head, but I'd guess it's 17763. Unfortunately, we forgot that the bugfix was a series of commits, not a single commit, so we accidentally only ported one of the commits.

Lemme pull up the servicing bug numbers to make sure my theory is right. In general - the bug is already fixed for newer versions of windows, so there's not much else we can do here. If I'm right, then we're already in discussion to service the remaining commits for the original fix.

@zadjii-msft commented on GitHub (Feb 2, 2022): How the heck did you even find this? 😅 I'm pretty sure 17763 is really not supposed to be getting any support anymore... That being said, there was a servicing fix we did late last year to port a bugfix to an older release. I forget the version off the top of my head, but I'd guess it's 17763. Unfortunately, we forgot that the bugfix was a series of commits, not a single commit, so we accidentally only ported one of the commits. Lemme pull up the servicing bug numbers to make sure my theory is right. In general - the bug is already fixed for newer versions of windows, so there's not much else we can do here. If I'm right, then we're already in discussion to service the remaining commits for the original fix.
claunia commented 2026-01-31 05:16:37 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 2, 2022):

  • Original fix: OS!2627182
  • Follow up fix: OS!2698584
  • Second follow up fix: OS!2591242
  • Original servicing bug: MSFT:34449714 (serviced to 17763, 2110c, which was KB5006744, 17763.2268)
  • Second servicing bug: MSFT:37631553. That one hasn't gone out yet.

Yep, that's what you're seeing here.

I think this is also tracked elsewhere in https://github.com/microsoft/WSL/issues/7660.

I'm following the second servicing bug internally. I'll post here when the fix goes out.

@zadjii-msft commented on GitHub (Feb 2, 2022): * Original fix: OS!2627182 * Follow up fix: OS!2698584 * Second follow up fix: OS!2591242 * Original servicing bug: MSFT:34449714 (serviced to 17763, 2110c, which was [KB5006744](https://support.microsoft.com/en-us/topic/october-19-2021-kb5006744-os-build-17763-2268-preview-e043a8a3-901b-4190-bb6b-f5a4137411c0), 17763.2268) * Second servicing bug: MSFT:37631553. That one hasn't gone out yet. Yep, that's what you're seeing here. I think this is also tracked elsewhere in https://github.com/microsoft/WSL/issues/7660. I'm following the second servicing bug internally. I'll post here when the fix goes out.
claunia commented 2026-01-31 05:16:38 +00:00
Author
Owner
Copy Link

@E3V3A commented on GitHub (Feb 2, 2022):

Can this be related to this ?

@E3V3A commented on GitHub (Feb 2, 2022): Can this be related to [this](https://github.com/PowerShell/PowerShell/issues/16818) ?
claunia commented 2026-01-31 05:16:38 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 2, 2022):

I highly doubt it. OP in https://github.com/PowerShell/PowerShell/issues/16818 is on Windows 11. The original bug here was fixed a while ago, and there's just some minorly torn state in 17763 builds right now. 22000 shouldn't have this issue at all.

@zadjii-msft commented on GitHub (Feb 2, 2022): I highly doubt it. OP in https://github.com/PowerShell/PowerShell/issues/16818 is on Windows 11. The original bug here was fixed a while ago, and there's just some minorly torn state in 17763 builds right now. 22000 shouldn't have this issue at all.
claunia commented 2026-01-31 05:16:38 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 20, 2022):

The hotfix for the hotfix was seemingly released in KB5011551. Thanks all!

@zadjii-msft commented on GitHub (Apr 20, 2022): The hotfix for the hotfix was seemingly released in [KB5011551](https://support.microsoft.com/en-gb/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4). Thanks all!
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 Issue-Bug Needs-Tag-Fix Product-Conhost Resolution-Fix-Committed
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#16592
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?