starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Conhost crashes after SetConsoleScreenBufferSize call if wrapping on resize is enabled #12986

New Issue
Closed
opened 2026-01-31 03:30:42 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 03:30:42 +00:00
Owner
Copy Link

Originally created by @AntonLapounov on GitHub (Mar 12, 2021).

Environment

Windows build number: 10.0.19042.867 (20H2)
conhost.exe version: 10.0.19041.746

Steps to reproduce

  • Start a Command Prompt.
  • Open the properties and make sure Wrap text output on resize is enabled.
  • Launch the program below.
#include <Windows.h>

int main()
{
    const int Width = 40, Height = 20;

    HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
    SMALL_RECT window = { 0, 0, Width - 1, Height - 1 };
    COORD size = { Width, Height };

    if (SetConsoleWindowInfo(hConsole, TRUE, &window))
    {
        // BUG: conhost.exe crashes after this call if "Wrap text output on resize" is enabled
        SetConsoleScreenBufferSize(hConsole, size);
    }
}

Expected behavior

No crash.

Actual behavior

Most of the time conhost.exe crashes with the following call stack:

KERNELBASE!RaiseException
ucrtbase!_CxxThrowException
conhost!wil::details::ThrowResultExceptionInternal
conhost!wil::ThrowResultException
conhost!wil::details::ReportFailure
conhost!wil::details::ReportFailure_Hr
conhost!wil::details::in1diag3::_Throw_Hr
conhost!wil::details::in1diag3::Throw_HrIf
conhost!TextBufferCellIterator::{ctor}
conhost!TextBuffer::GetCellDataAt
conhost!Microsoft::Console::Render::Renderer::_PaintBufferOutput
conhost!Microsoft::Console::Render::Renderer::_PaintFrameForEngine
conhost!Microsoft::Console::Render::Renderer::PaintFrame
conhost!Microsoft::Console::Render::RenderThread::_ThreadProc
KERNEL32!BaseThreadInitThunk
ntdll!RtlUserThreadStart

The same program works correctly on Windows 7, so this is a regression. I could not find any open issues that might be duplicates of this one. Cc @zadjii-msft @j4james.

Originally created by @AntonLapounov on GitHub (Mar 12, 2021). # Environment Windows build number: 10.0.19042.867 (20H2) conhost.exe version: 10.0.19041.746 # Steps to reproduce * Start a Command Prompt. * Open the properties and make sure _Wrap text output on resize_ is enabled. * Launch the program below. ```c #include <Windows.h> int main() { const int Width = 40, Height = 20; HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE); SMALL_RECT window = { 0, 0, Width - 1, Height - 1 }; COORD size = { Width, Height }; if (SetConsoleWindowInfo(hConsole, TRUE, &window)) { // BUG: conhost.exe crashes after this call if "Wrap text output on resize" is enabled SetConsoleScreenBufferSize(hConsole, size); } } ``` # Expected behavior No crash. # Actual behavior Most of the time conhost.exe crashes with the following call stack: ``` KERNELBASE!RaiseException ucrtbase!_CxxThrowException conhost!wil::details::ThrowResultExceptionInternal conhost!wil::ThrowResultException conhost!wil::details::ReportFailure conhost!wil::details::ReportFailure_Hr conhost!wil::details::in1diag3::_Throw_Hr conhost!wil::details::in1diag3::Throw_HrIf conhost!TextBufferCellIterator::{ctor} conhost!TextBuffer::GetCellDataAt conhost!Microsoft::Console::Render::Renderer::_PaintBufferOutput conhost!Microsoft::Console::Render::Renderer::_PaintFrameForEngine conhost!Microsoft::Console::Render::Renderer::PaintFrame conhost!Microsoft::Console::Render::RenderThread::_ThreadProc KERNEL32!BaseThreadInitThunk ntdll!RtlUserThreadStart ``` The same program works correctly on Windows 7, so this is a regression. I could not find any open issues that might be duplicates of this one. Cc @zadjii-msft @j4james.
claunia added the Resolution-Duplicate label 2026-01-31 03:30:42 +00:00
claunia commented 2026-01-31 03:30:43 +00:00
Author
Owner
Copy Link

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

make sure Wrap text output on resize is enabled.

Did you perhaps mean "disabled"? Because that's the only way I can reproduce the crash.

And if that's the case, I think this is probably #1976 or #8453, which should be fixed in the current version of OpenConsole. I'm not sure how long it'll take for those fixes to make their way into a Windows release.

@j4james commented on GitHub (Mar 12, 2021): > make sure Wrap text output on resize is enabled. Did you perhaps mean "disabled"? Because that's the only way I can reproduce the crash. And if that's the case, I think this is probably #1976 or #8453, which should be fixed in the current version of OpenConsole. I'm not sure how long it'll take for those fixes to make their way into a Windows release.
claunia commented 2026-01-31 03:30:43 +00:00
Author
Owner
Copy Link

@AntonLapounov commented on GitHub (Mar 12, 2021):

Did you perhaps mean "disabled"? Because that's the only way I can reproduce the crash.

For me it crashes only if Wrap text output on resize is enabled. As soon as I remove the check mark in Properties, it no longer crashes.

@AntonLapounov commented on GitHub (Mar 12, 2021): > Did you perhaps mean "disabled"? Because that's the only way I can reproduce the crash. For me it crashes only if _Wrap text output on resize_ is **enabled**. As soon as I _remove_ the check mark in Properties, it no longer crashes.
claunia commented 2026-01-31 03:30:43 +00:00
Author
Owner
Copy Link

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

OK I've tried repeatedly now, and I definitely can't reproduce this. However, based on my comments in issue #1976, there was a time where I could produce a crash in OpenConsole with wrapping enabled, which didn't occur in my Windows conhost, so that suggests it was probably a regression. And that would explain why your conhost has this bug, but mine doesn't (I'm still on Window 10.0.18363.1316).

And looking at your stack trace, the reason it's likely crashing is because of the missing exception handler on _PaintFrameForEngine, which was later added in commit eb480b6bbb. So even if there is still an unresolved bug there, it should at least fail more gracefully now. But I suspect the underlying problem would have been fixed by PR #8309.

@j4james commented on GitHub (Mar 12, 2021): OK I've tried repeatedly now, and I definitely can't reproduce this. However, based on my comments in issue #1976, there was a time where I could produce a crash in OpenConsole with wrapping enabled, which didn't occur in my Windows conhost, so that suggests it was probably a regression. And that would explain why your conhost has this bug, but mine doesn't (I'm still on Window 10.0.18363.1316). And looking at your stack trace, the reason it's likely crashing is because of the missing exception handler on `_PaintFrameForEngine`, which was later added in commit eb480b6bbbd83a2aafbe62992d360838e0ab9da5. So even if there is still an unresolved bug there, it should at least fail more gracefully now. But I suspect the underlying problem would have been fixed by PR #8309.
claunia commented 2026-01-31 03:30:43 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 12, 2021):

The exception handler made it into 10.0.19041, which you should probably use 😄

@DHowett commented on GitHub (Mar 12, 2021): The exception handler made it into 10.0.19041, which you should probably use :smile:
claunia commented 2026-01-31 03:30:44 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 12, 2021):

/dup #256 this is fixed! Thanks for the investigation, James

@DHowett commented on GitHub (Mar 12, 2021): /dup #256 this is fixed! Thanks for the investigation, James
claunia commented 2026-01-31 03:30:44 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 12, 2021):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Mar 12, 2021): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
claunia commented 2026-01-31 03:30:44 +00:00
Author
Owner
Copy Link

@AntonLapounov commented on GitHub (Mar 12, 2021):

Thank you for your immediate attention. @DHowett Issue #256 seems to be fixed more than 2 years ago. Are you claiming the latest Windows 20H2 that I use still do not have that fix? In what Windows version should we expect the fix then?

Moreover, the crash in #256 happens only when Wrap text output on resize is unchecked. In my repro it crashes only when that option is checked. How do you know it is the same issue then?

Just to be sure, I ran my repro on two other machines with Windows 10.0.19042.867. It crashed on them as well, but only when the option is checked.

@AntonLapounov commented on GitHub (Mar 12, 2021): Thank you for your immediate attention. @DHowett Issue #256 seems to be fixed more than 2 years ago. Are you claiming the latest Windows 20H2 that I use still do not have that fix? In what Windows version should we expect the fix then? Moreover, the crash in #256 happens only when _Wrap text output on resize_ is **unchecked**. In my repro it crashes only when that option is **checked**. How do you know it is the same issue then? Just to be sure, I ran my repro on two other machines with Windows 10.0.19042.867. It crashed on them as well, but only when the option is **checked**.
claunia commented 2026-01-31 03:30:44 +00:00
Author
Owner
Copy Link

@AntonLapounov commented on GitHub (Mar 12, 2021):

@j4james Thank you for the investigation! Indeed #8309 might have fixed the issue (duplicating to #256 closed 2 years ago was certainly confusing). I just tried Windows 10.0.21298.1000 with the same version of conhost.exe (10.0.21298.1000) and the program does not crash there. It seems we miss refreshing the console window though: after running my program the cursor disappears and the program path is 'stuck' in the title until I press any key. However, it no longer crashes, which was my main concern.

Therefore if #8309 landed between conhost builds 10.0.19041.746 and 10.0.21298.1000, I agree with resolving this as a duplicate.

@AntonLapounov commented on GitHub (Mar 12, 2021): @j4james Thank you for the investigation! Indeed #8309 might have fixed the issue (duplicating to #256 closed 2 years ago was certainly confusing). I just tried Windows 10.0.21298.1000 with the same version of conhost.exe (10.0.21298.1000) and the program does not crash there. It seems we miss refreshing the console window though: after running my program the cursor disappears and the program path is 'stuck' in the title until I press any key. However, it no longer crashes, which was my main concern. Therefore if #8309 landed between conhost builds 10.0.19041.746 and 10.0.21298.1000, I agree with resolving this as a duplicate.
claunia commented 2026-01-31 03:30:44 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 12, 2021):

#8309 landed between 19041 and 21298, but the exception handler landed between 18362 and 19041, so I am at a bit of a loss here 😄

@DHowett commented on GitHub (Mar 12, 2021): #8309 landed between 19041 and 21298, but the exception handler landed between 18362 and 19041, so I am at a bit of a loss here :smile:
claunia commented 2026-01-31 03:30:45 +00:00
Author
Owner
Copy Link

@AntonLapounov commented on GitHub (Mar 13, 2021):

@DHowett I just set up a fresh VM with build 19041, WinDbg, and private conhost symbols. Could you please take a look why the exception handler is not working? I'll send the RDP connection parameters in a private email.

@AntonLapounov commented on GitHub (Mar 13, 2021): @DHowett I just set up a fresh VM with build 19041, WinDbg, and private conhost symbols. Could you please take a look why the exception handler is not working? I'll send the RDP connection parameters in a private email.
claunia commented 2026-01-31 03:30:45 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 13, 2021):

I'm not inclined to -- not because I don't care about this bug, but because if I had to write code to fix it it would only come out in the next build of windows... which is also when the root cause fix is also going to come out. You know? There isn't a configuration flag somewhere to dictate that we do or do not handle the exception. That bit is set in stone. 😄

@DHowett commented on GitHub (Mar 13, 2021): I'm not inclined to -- not because I don't care about this bug, but because if I had to write code to fix it _it would only come out in the next build of windows_... which is also when the root cause fix is also going to come out. You know? There isn't a configuration flag somewhere to dictate that we do or do not handle the exception. That bit is set in stone. :smile:
claunia commented 2026-01-31 03:30:45 +00:00
Author
Owner
Copy Link

@AntonLapounov commented on GitHub (Mar 13, 2021):

@DHowett Makes sense. BTW, I just looked at renderer.cpp source code fetched by WinDbg and it clearly misses commit eb480b6, which explains why the exception is not handled in Windows 20H2 build 19041.

@AntonLapounov commented on GitHub (Mar 13, 2021): @DHowett Makes sense. BTW, I just looked at `renderer.cpp` source code fetched by WinDbg and it clearly misses commit [eb480b6](https://github.com/microsoft/terminal/commit/eb480b6bbbd83a2aafbe62992d360838e0ab9da5), which explains why the exception is not handled in Windows 20H2 build 19041.
claunia commented 2026-01-31 03:30:45 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 15, 2021):

Ah, yes, I clearly cannot read. 😄

image

It is evident that this number is in fact not less than 19041.

@DHowett commented on GitHub (Mar 15, 2021): Ah, yes, I clearly cannot read. :smile: ![image](https://user-images.githubusercontent.com/189190/111189177-d672f480-8583-11eb-9b4e-6793b3bcbc59.png) It is evident that this number is in fact _not_ less than 19041.
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 Resolution-Duplicate
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#12986
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?