Repository navigation
Closed
Labels
Area-ServerDown in the muck of API call servicing, interprocess communication, eventing, etc.Down in the muck of API call servicing, interprocess communication, eventing, etc.Area-VTVirtual Terminal sequence supportVirtual Terminal sequence supportNeeds-AttentionThe core contributors need to come back around and look at this ASAP.The core contributors need to come back around and look at this ASAP.Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirementsNeeds-TriageIt's a new issue that the core contributor team needs to triage at the next triage meetingIt's a new issue that the core contributor team needs to triage at the next triage meetingProduct-ConhostFor issues in the Console codebaseFor issues in the Console codebase
Description
Environment
Windows build number: 10.0.18363.1256
ConEmu: 210111
Steps to reproduce
- Run it as: conemu64.exe -basic -run cmd.exe /k wsl.exe
- WSL prompt appears, type exit
- 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.
Metadata
Metadata
Assignees
Labels
Area-ServerDown in the muck of API call servicing, interprocess communication, eventing, etc.Down in the muck of API call servicing, interprocess communication, eventing, etc.Area-VTVirtual Terminal sequence supportVirtual Terminal sequence supportNeeds-AttentionThe core contributors need to come back around and look at this ASAP.The core contributors need to come back around and look at this ASAP.Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirementsNeeds-TriageIt's a new issue that the core contributor team needs to triage at the next triage meetingIt's a new issue that the core contributor team needs to triage at the next triage meetingProduct-ConhostFor issues in the Console codebaseFor issues in the Console codebase
Activity
vefatica commentedon Jan 12, 2021
I think you'll be interested in #5940.
zadjii-msft commentedon 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.
Maksim Moisiuk (@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.
Maximus5 commentedon Jan 12, 2021
Mike Griese (@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.j4james commentedon 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
ReadConsoleOutputAttributemay 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 commentedon Jan 12, 2021
Just to be clear, I'm not testing in ConEmu, but I wrote a little test app that calls
ReadConsoleOutputAttributeto query the initial attribute values. When run fromcmd.exe /k wsl.exeI get 0x00, and when run fromOpenConsole.exe cmd.exe /k wsl.exeI get 0x07.DHowett commentedon 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.
Maximus5 commentedon Feb 19, 2021
Dustin L. Howett (@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