Some Windows Bugs and Workarounds
- WINDOW_BUFFER_SIZE_EVENT received after scrolling in Windows 10
- Console content is ‘erased’ after resize in Windows 10
- Broken text is returned from console input
- Broken cursor position and height in Windows 10
- Broken WM_MOUSEWHEEL’s mouse cursor position in Windows 10
- Broken desktop coordinate system in Windows 10
- Exception in ReadConsoleOutput
- Console screen buffer corrupts from other console application
- chcp hung
- Ctrl+C lags
- Insert/Overwrite indication
- Conclusion
WINDOW_BUFFER_SIZE_EVENT received after scrolling in Windows 10
When application calls SetConsoleWindowInfo to scroll console contents, conhost posts the WINDOW_BUFFER_SIZE_EVENT into the console input buffer.
The event was intended to inform application ‘about the new size of the console screen buffer’, but in fact, the size of the buffer was not changed.
| Appeared | Fixed |
|---|---|
| Windows 10 | ? |
Console content is ‘erased’ after resize in Windows 10
After resizing ConEmu in Windows 10 console contents becomes invisible. It looks like contents was erased, but actually text attributes are to ‘black on black’. This is known conhost’s API bug.
| Appeared | Fixed |
|---|---|
| Windows 10 | ? |
Workaround
There is no good solution yet.
You may enable ‘Legacy mode’ in RealConsole properties, but you’d lost abitily to run Bash on Ubuntu on Windows and console contents reflow would stop working.
Related issues
- Issue 1164: Content disappears after resizing to smaller size
- Issue 1216: Split pane does not play well with shell_plus in top window
- Issue 1219: Maximize & restore console erases text
Broken text is returned from console input
In some cases, broken text is returned from console input buffer.
Full description: https://github.com/Maximus5/ms-bug-2.
| Appeared | Fixed |
|---|---|
| Windows 2000 | ? |
Related issues
Broken cursor position and height in Windows 10
After SetConsoleScreenBufferSize call cursor position and height are broken.
Full description: https://github.com/Maximus5/ms-bug-1.
| Appeared | Fixed |
|---|---|
| Windows 10 (14361) | Windows 10 (14371) |
Workaround
Choose ‘Fixed cursor size’ at Text cursor settings page.
Related issues
Broken WM_MOUSEWHEEL’s mouse cursor position in Windows 10
MSDN says that WM_MOUSEWHEEL/lParam contains X and Y coordinates of the mouse pointer, relative to the upper-left corner of the screen.
But that is not true in Windows 10 anymore. Seems like the bug relates to several monitors, larger than 100% scale, and focused child window. Than, your window will receive larger coordinates than they would be.
| Appeared | Fixed |
|---|---|
| Windows 10 | ? |
Workaround
There is no proper workaround, because mouse pointer may be moved, after WM_MOUSEWHEEL was posted.
However, in most cases, retrieving mouse coordinates using GetCursorPos, instead of relying on message’s lParam, will be suitable.
Related issues
Broken desktop coordinate system in Windows 10
insider/forum/insider_wintp-insider_desktop/desktop-coordinate-system-is-broken
More details in this sample project: ms-bug-3.
| Appeared | Fixed |
|---|---|
| Windows 10 | ? |
Related issues
Exception in ReadConsoleOutput
social.msdn.microsoft.com/Forums/en-US/40c8e395-cca9-45c8-b9b8-2fbe6782ac2b
| Appeared | Fixed |
|---|---|
| Windows 7 | Windows 10 |
Sample project
http://conemu-maximus5.googlecode.com/svn/files/BugReports/
Workaround
Turn on ‘Inject ConEmuHk’ option.
Related issues
- Issue 1060: git rebase using vim as an editor crashes conemu
- Issue 1061: interactive git rebasing causes ConEmu to crash
- Issue 1146: Crash when doing “git diff”
- Issue 1190: ConEmu crashes
- Issue 1203: Occasional crash when vim.exe is started
- Issue 1204: Fail after updating Far with UpDateEx
- and others…
Console screen buffer corrupts from other console application
social.msdn.microsoft.com/Forums/en-US/ec363615-397c-42a8-84d2-38a70e4f8ae2
| Appeared | Fixed |
|---|---|
| Windows 7 | Windows 8 |
Related issues
- Issue 65: Telnet.exe is not working
- Issue 107: 32-bit console applications
- Issue 529: Tunnelier stermc.exe hangs under Win7
- Issue 669: text editor Aurora is working
Workaround
Turn on ‘Inject ConEmuHk’ option. Workaround was first created in ConEmu build 120509a.
chcp hung
Console code page change (chcp.com, SetConsoleCP, SetConsoleOutputCP) hungs.
| Appeared | Fixed |
|---|---|
| Windows XP | ? |
Related issues
Workaround
Turn on ‘Inject ConEmuHk’ option.
Ctrl+C lags
In Windows console API there is no correct way to send Ctrl+C signals to console applications.
The only working way which simulates conhost behavior is posting WM_KEYDOWN/WM_KEYUP
events into the RealConsole window. But obviously due to asynchronous nature
and possible race conditions console application may receive Ctrl+C signal after long lags
or even may not receive the signal at all.
| Appeared | Fixed |
|---|---|
| Windows XP | ? |
Related issues
- Issue 402: ConEmu long delay on Ctrl+C with GitBash
- Issue 429: ctrl-c problems with build 151115 and above
- Issue 1018: ctrl-c not working in powershell windows 10 15007 on latest ConEmu
- Issue 1470: CTRL-C out of erl shell running in powershell will stop responding to input and stop output in ConEmu
- Issue 1576: Ctrl+C won’t stop a command which is dumping text to STDOUT
Workaround
First of all, check Ctrl+C in the RealConsole,
if it does not work - the problem is somewhere outside of ConEmu or conhost.
If Ctrl+C works in the RealConsole,
no workaround may guarantee the expected result,
but you may try the following:
- Press and hold
Ctrl+Cfor a longer time. But this may be not working too. - Use [GuiMacro.html#Break]
Break(0). But this has no effect on cmd.exe prompt, it’s just ignored when you typed some command. - Use hotkey for ‘Terminate (kill) all but shell processes in the current console’. But this really kills processes instead of sending
Ctrl+Csignal.
Insert/Overwrite indication
It is not possible to determine the state of ReadConsole procedure. ConEmu do not know if the RealConsole is in the ‘Insert’ or ‘Overwrite’ mode.
Wny not? Description is here.
Workaround
Doesn’t exists.
Conclusion
My (and not only) experience in ‘bug reporting’ suggests that Microsoft won’t fix reported bugs in current versions of Windows. Even in service packs.
But, may be, bug will be fixed in the next version of Windows if you manage to report them…
Users and developers, help yourself.
