Conhost crashes after SetConsoleScreenBufferSize call if wrapping on resize is enabled

[AntonLapounov]

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.

[j4james]

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.

[AntonLapounov]

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.

[j4james]

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 eb480b6. 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.

[DHowett]

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

[DHowett]

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

[ghost]

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!

[AntonLapounov]

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]

@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.

[DHowett]

#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 😄

[AntonLapounov]

@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.

[DHowett]

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. 😄

[AntonLapounov]

@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.

[DHowett]

Ah, yes, I clearly cannot read. 😄

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