Conhost crashes on resize

[parkovski]

The best I can tell is this happens when an app responds to a window size change, if it is using ANSI. The window resizes, but the buffer region stays in the same place on screen for a second, and then the console window crashes. Sometimes it leaves behind a zombie process. I think this requires the app to be using the secondary buffer but I'm not totally sure which apps do and don't.

• Your Windows build number: (Type ver at a Windows Command Prompt)
  17666

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
  Start an unmaximized console window, then run a program that writes all the way around the screen and maximize the window. Any of these commands will crash the console when I maximize it:

PS> vim -u NONE -i NONE "+set tgc" # Needs to be a recent vim with tgc enabled
$ vim -u NONE -i NONE # Any Linux vim should do it
$ tmux # The client crashes, but the server is still there.
$ sl # Only crashes while the choo choo is a-comin' out of the right edge;
$ # should give a hint where the problem is.
$ # If you catch it elsewhere on the screen, the buffer glitches but doesn't crash.

Windows vim using console APIs (without termguicolors set) does not crash.

PS> vim -u NONE -i NONE # Hooray, 16 colors like the good old days!

This is what my nightmares look like:

• What's wrong / what should be happening instead:
  Clippy should appear saying "I see you're trying to maximize the console. Do you want to crash it?" And I'll only pick "yes" if I really deserve it.

[mkarpoff]

I can definitely confirm this as of this morning in wsl ubuntu

[miniksa]

Any chance one of you can open Event Viewer, go to Windows Logs > Application, find the Windows Error Reporting (Event ID 1001) associated with this and let me know the "Hashed bucket" ID?

One of the other lines in the details under "Problem Signature" should say something about conhost.exe and the date stamp should be very, very near when the crash happened.

[mkarpoff]

Log Name: Application
Source: Application Error
Date: 2018-05-15 8:03:30 AM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: REMOVED
Description:
Faulting application name: conhost.exe, version: 10.0.17666.1000, time stamp: 0x3a39791f
Faulting module name: ucrtbase.dll, version: 10.0.17666.1000, time stamp: 0x32c7a0b8
Exception code: 0xc0000409
Fault offset: 0x000000000006e5de
Faulting process id: 0xf70
Faulting application start time: 0x01d3ec557f75800c
Faulting application path: C:\WINDOWS\system32\conhost.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: 51bfad3c-a4f6-4118-91f3-a45fa0912fc0
Faulting package full name:
Faulting package-relative application ID:
Event Xml:



1000
2
100
0x80000000000000

318
Application
REMOVED



conhost.exe
10.0.17666.1000
3a39791f
ucrtbase.dll
10.0.17666.1000
32c7a0b8
c0000409
000000000006e5de
f70
01d3ec557f75800c
C:\WINDOWS\system32\conhost.exe
C:\WINDOWS\System32\ucrtbase.dll
51bfad3c-a4f6-4118-91f3-a45fa0912fc0

I just grabbed the event. Hope this helps

[miniksa]

That's event ID 1000 of the application crashing, not event ID 1001 of the crash being submitted to Windows Error Reporting. I'm trying to correlate your crash with the submission to Windows Error Reporting so I can see if it matches with one of our known issues.

Alternatively, if you have a debugger attached and can show me the stack of the crash, I can see if it is something we know about.

(I suspect we've already fixed this issue, but I would need the WER submission or the stack to confirm.)

[parkovski]

Ok, I'm seeing 2b4dbb2a3e8feca6162ab1a53539c092 for the hashed bucket ID, here is the output of windbg !analyze -v, just in case.

[miniksa]

Thanks @parkovski. The !analyze -v helped a ton.

This is MSFT: 16503311 which Payload Tracking tell me is in build 17673 of the Insiders branch built on May 14th 2018. So the next Insiders build pushed should have the fix.

[parkovski]

The crash is fixed in the last couple builds, but now there is a second issue: if I start vim, then maximize the console, then restore it, it looks like this:

What should be the top ~2/3 of the buffer is now on the bottom of the screen, and the bottom is above it. When I start typing, it looks like this:

So some things are in the right place, some are one row off, and some are somewhere different entirely. Right now it seems to be happening every time I restore the window from maximized, whether vim was started maximized or not. This only happens in vim though (secondary buffer) - maximize/restore works fine at a regular prompt.

[miniksa]

Please file a different issue for something that is no longer a crash. It is very hard to do payload tracking if you bump the old issue with a new symptom.