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

ReadConsoleOutputAttribute returns zeros in the attribute buffer #12025

New Issue
Closed
opened 2026-01-31 03:04:17 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 03:04:17 +00:00
Owner
Copy Link

Originally created by @Maximus5 on GitHub (Jan 12, 2021).

Environment

Windows build number: 10.0.18363.1256
ConEmu: 210111

Steps to reproduce

  1. Run it as: conemu64.exe -basic -run cmd.exe /k wsl.exe
  2. WSL prompt appears, type exit
  3. cmd.exe prompt appears, but the first 4 characters are invisible. The reason is that ReadConsoleOutputAttribute returns malformed data (all zeros in attributes array).

Expected behavior

ReadConsoleOutputAttribute returns 7-s in the attributes array.

Actual behavior

ReadConsoleOutputAttribute returns 0-s in the attributes array.

Details

Sample code used in ConEmu to read attribute data

#define ROWID_USED_CELLS 4
WORD  nAttrs[ROWID_USED_CELLS];
const COORD crLeft = {0, nRow};
DWORD nRead = 0;
if (!ReadConsoleOutputAttribute(hConOut, nAttrs, ROWID_USED_CELLS, crLeft, &nRead) || (nRead != ROWID_USED_CELLS))
   return false;

So, on exit from wsl.exe back to cmd.exe prompt (we started it as cmd /k wsl.exe), ReadConsoleOutputAttribute returns TRUE, nRead is equal to 4, but nAttrs is {0,0,0,0}.

For now, I found the workaround - ReadConsoleOutputW works properly, it returns cell attribute 7.

Originally created by @Maximus5 on GitHub (Jan 12, 2021). # Environment ```none Windows build number: 10.0.18363.1256 ConEmu: 210111 ``` # Steps to reproduce 1. Run it as: conemu64.exe -basic -run cmd.exe /k wsl.exe 2. WSL prompt appears, type exit 3. cmd.exe prompt appears, but the first 4 characters are invisible. The reason is that ReadConsoleOutputAttribute returns malformed data (all zeros in attributes array). # Expected behavior ReadConsoleOutputAttribute returns 7-s in the attributes array. # Actual behavior ReadConsoleOutputAttribute returns 0-s in the attributes array. # Details Sample code used in ConEmu to read attribute data ``` #define ROWID_USED_CELLS 4 WORD nAttrs[ROWID_USED_CELLS]; const COORD crLeft = {0, nRow}; DWORD nRead = 0; if (!ReadConsoleOutputAttribute(hConOut, nAttrs, ROWID_USED_CELLS, crLeft, &nRead) || (nRead != ROWID_USED_CELLS)) return false; ``` So, on exit from wsl.exe back to cmd.exe prompt (we started it as `cmd /k wsl.exe`), **ReadConsoleOutputAttribute** returns **TRUE**, **nRead** is equal to **4**, but **nAttrs** is **{0,0,0,0}**. For now, I found the workaround - **ReadConsoleOutputW** works properly, it returns cell attribute 7.
claunia commented 2026-01-31 03:04:18 +00:00
Author
Owner
Copy Link

@vefatica commented on GitHub (Jan 12, 2021):

I think you'll be interested in #5940.

@vefatica commented on GitHub (Jan 12, 2021): I think you'll be interested in #5940.
claunia commented 2026-01-31 03:04:18 +00:00
Author
Owner
Copy Link

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

Hmm. That's a good point that we saw something like this in #5940. It does seem weird to me though. That other issue dealt with a improper conversion of 256/RGB attributes to legacy ones, while in this case, there's presumably no such conversion happening.

@Maximus5 can you quick share a screenshot of what those four characters look like? I think it's extremely bizarre that it's only those 4 that are returning bad data, and not the rest of the prompt.

@zadjii-msft commented on GitHub (Jan 12, 2021): Hmm. That's a good point that we saw something like this in #5940. It does seem weird to me though. That other issue dealt with a improper conversion of 256/RGB attributes to legacy ones, while in this case, there's presumably no such conversion happening. @Maximus5 can you quick share a screenshot of what those four characters look like? I think it's extremely bizarre that it's only those 4 that are returning bad data, and not the rest of the prompt.
claunia commented 2026-01-31 03:04:19 +00:00
Author
Owner
Copy Link

@Maximus5 commented on GitHub (Jan 12, 2021):

@zadjii-msft Sorry if I described unclearly. The problem is not with only first 4 characters. I mentioned this magic number only because ConEmu utilizes first four cells to overwrite some attributes for internal purposes. So, I've noted that attributes are zeros, because ConEmu explicitly writes new attributes, e.g. hi_byte_flags | lo_byte_from_conhost.

2021-01-12-12-35-44

@Maximus5 commented on GitHub (Jan 12, 2021): @zadjii-msft Sorry if I described unclearly. The problem is not with only first 4 characters. I mentioned this magic number only because ConEmu utilizes first four cells to overwrite some attributes for internal purposes. So, I've noted that attributes are zeros, because ConEmu explicitly writes new attributes, e.g. `hi_byte_flags | lo_byte_from_conhost`. ![2021-01-12-12-35-44](https://user-images.githubusercontent.com/1222388/104309908-2aedeb00-54d3-11eb-9ab8-e55ca81eaef1.png)
claunia commented 2026-01-31 03:04:19 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 12, 2021):

I think this issue has been fixed. If it wasn't #6358, it may have been #6698, or a combination of the two (possibly one of the other PRs from around that time). I'm too lazy to dig through the changes, but I vaguely remember something about the buffer being initialized with different attributes in different circumstances. Sometimes it would be white-on-black, but sometimes it would use the VT default colors (which I suspect ReadConsoleOutputAttribute may not have read back correctly).

I think at this point we always initialize with the VT default colors, but all the legacy console APIs are now able to read that back correctly (i.e. returning 0x07, which is what legacy apps would expect).

I can reproduce the problem using the cmd.exe that's included in Windows 10.0.18363.1256, but it works correctly if I try the same thing with the latest version of OpenConsole, so I'm assuming that means it's fixed.

@j4james commented on GitHub (Jan 12, 2021): I _think_ this issue has been fixed. If it wasn't #6358, it may have been #6698, or a combination of the two (possibly one of the other PRs from around that time). I'm too lazy to dig through the changes, but I vaguely remember something about the buffer being initialized with different attributes in different circumstances. Sometimes it would be white-on-black, but sometimes it would use the VT default colors (which I suspect `ReadConsoleOutputAttribute` may not have read back correctly). I think at this point we always initialize with the VT default colors, but all the legacy console APIs are now able to read that back correctly (i.e. returning 0x07, which is what legacy apps would expect). I can reproduce the problem using the cmd.exe that's included in Windows 10.0.18363.1256, but it works correctly if I try the same thing with the latest version of OpenConsole, so I'm assuming that means it's fixed.
claunia commented 2026-01-31 03:04:19 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 12, 2021):

Just to be clear, I'm not testing in ConEmu, but I wrote a little test app that calls ReadConsoleOutputAttribute to query the initial attribute values. When run from cmd.exe /k wsl.exe I get 0x00, and when run from OpenConsole.exe cmd.exe /k wsl.exe I get 0x07.

@j4james commented on GitHub (Jan 12, 2021): Just to be clear, I'm not testing in ConEmu, but I wrote a little test app that calls `ReadConsoleOutputAttribute` to query the initial attribute values. When run from `cmd.exe /k wsl.exe` I get 0x00, and when run from `OpenConsole.exe cmd.exe /k wsl.exe` I get 0x07.
claunia commented 2026-01-31 03:04:19 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 17, 2021):

So, I've gone to try to reproduce this. I'm running 19041/19042, and I can't. I suspect you released a fix in ConEmu? 😄

Regardless -- James' hunch appears to be correct. It's been fixed in newer versions, even though we can't quite pinpoint exactly where. When we added 256- and 24-bit-color support and some of the VT work that exposed "default" versus "legacy" colors, we likely broke something in a subtle way that ConEmu tripped over.

I'm going to close this one out. If you see any other cases where you're storing stuff in attributes and they're getting corrupted, or we're not storing something quite right, please let me know.

@DHowett commented on GitHub (Feb 17, 2021): So, I've gone to try to reproduce this. I'm running 19041/19042, and I can't. I suspect you released a fix in ConEmu? :smile: Regardless -- James' hunch appears to be correct. It's been fixed in newer versions, even though we can't quite pinpoint exactly where. When we added 256- and 24-bit-color support and some of the VT work that exposed "default" versus "legacy" colors, we likely broke something in a subtle way that ConEmu tripped over. I'm going to close this one out. If you see any other cases where you're storing stuff in attributes and they're getting corrupted, or we're not storing something quite right, please let me know.
claunia commented 2026-01-31 03:04:19 +00:00
Author
Owner
Copy Link

@Maximus5 commented on GitHub (Feb 19, 2021):

@DHowett Yes, the latest ConEmu version where this may be observable is 210111.
https://github.com/Maximus5/ConEmu/releases/tag/v21.01.11

If it's fixed, than everything is ok. Thanks

@Maximus5 commented on GitHub (Feb 19, 2021): @DHowett Yes, the latest ConEmu version where this may be observable is 210111. https://github.com/Maximus5/ConEmu/releases/tag/v21.01.11 If it's fixed, than everything is ok. Thanks
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-Server Area-VT Needs-Attention Needs-Tag-Fix Needs-Triage Product-Conhost
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#12025
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?