Access violation exception thrown in ConhostV2.dll

[j4james]

• Your Windows build number:

Microsoft Windows [Version 10.0.16299.371]

• What you're doing and what's happening:

I've found that a certain combination of escapes sequences and input consistently causes the console to crash. I suspect it's some kind of heap corruption, because the actual location of the exception can vary depending on what else I've been doing prior to triggering the crash, but it usually occurs in ConhostV2.dll.

Interestingly it only happens in the Windows cmd shell - I can't reproduce the problem in a WSL bash shell. I have reproduced it on multiple machines, though, so I don't think it's something specific to my computer and should hopefully be easy to reproduce.

Before I provide the exact steps to trigger the exception, I just want to double check that it's OK for me to post those details here? I'm always a little concerned that an easily triggerable exception might have security implications, but it's not like it's a BSOD - it's only the shell that crashes.

• What's wrong / what should be happening instead:

The shell shouldn't crash. ;)

[zadjii-msft]

Yea I think it's probably fine to post the repro steps. It's only conhost, so it shouldn't be that big of a deal.

[j4james]

The basic steps to reproduce are:

1. Switch to the alternate screen buffer.
2. Read something from stdin.
3. Switch back to the original screen buffer.

At this point I think the heap will already be corrupted (or whatever it is that's gone wrong), and just doing something like a directory listing - essentially anything that writes to the screen - should eventually cause a crash. But for an immediate result, I've found that sending the RIS escape sequence works best.

So my Python test case looked like this:

import sys
sys.stdout.write("\033[?1049h")
sys.stdout.write("Press enter...")
sys.stdin.readline()
sys.stdout.write("\033[?1049l")
sys.stdout.write("\033c")

But note that this only causes the exception in the Windows cmd shell, and not the WSL bash shell (at least I couldn't get it to crash there).

And just to confirm that it wasn't anything specific to Python, I also hacked together an equivalent batch file (the funny characters in this code should be ESC characters):

@echo �[?1049h
@set /p junk=Press enter...
@echo �[?1049l
@echo �c

As I mentioned before, the exact location of the exception can vary, but when run from a newly opened shell, I often got: Exception thrown at 0x00007FF9E50DCE99 (ConhostV2.dll) in conhost.exe: 0xC0000005: Access violation writing location 0x0000000000000000.

And in case it helps, this is the stack trace I saw in an attached debugger:

ConhostV2.dll!wmemset()
ConhostV2.dll!ROW::Initialize(short,class TextAttribute)
ConhostV2.dll!TEXT_BUFFER_INFO::IncrementCircularBuffer(void)
ConhostV2.dll!SCREEN_INFORMATION::VtEraseAll(void)
ConhostV2.dll!ConhostInternalGetSet::PrivateEraseAll(void)
ConhostV2.dll!Microsoft::Console::VirtualTerminal::AdaptDispatch::_EraseAll(void)
ConhostV2.dll!Microsoft::Console::VirtualTerminal::AdaptDispatch::EraseInDisplay(enum Microsoft::Console::VirtualTerminal::TermDispatch::EraseType)
ConhostV2.dll!Microsoft::Console::VirtualTerminal::AdaptDispatch::HardReset(void)
ConhostV2.dll!Microsoft::Console::VirtualTerminal::StateMachine::_ActionEscDispatch(unsigned short)
ConhostV2.dll!Microsoft::Console::VirtualTerminal::StateMachine::_EventEscape(unsigned short)
ConhostV2.dll!Microsoft::Console::VirtualTerminal::StateMachine::ProcessCharacter()
ConhostV2.dll!Microsoft::Console::VirtualTerminal::StateMachine::ProcessString(unsigned short * const,unsigned __int64)
ConhostV2.dll!WriteChars(class SCREEN_INFORMATION *,unsigned short * const,unsigned short *,unsigned short *,unsigned long * const,unsigned long * const,short,unsigned long,short * const)
ConhostV2.dll!DoWriteConsole(unsigned short *,unsigned long * const,class SCREEN_INFORMATION *,class IWaitRoutine * * const)
ConhostV2.dll!WriteConsoleWImplHelper(class SCREEN_INFORMATION * const,unsigned short const * const,unsigned __int64,unsigned __int64 * const,class IWaitRoutine * * const)
ConhostV2.dll!ApiRoutines::WriteConsoleAImpl(class SCREEN_INFORMATION * const,char const * const,unsigned __int64,unsigned __int64 * const,class IWaitRoutine * * const)
ConhostV2.dll!ApiDispatchers::ServerWriteConsole(struct _CONSOLE_API_MSG * const,int * const)
ConhostV2.dll!IoSorter::ServiceIoOperation(struct _CONSOLE_API_MSG * const,struct _CONSOLE_API_MSG * *)
ConhostV2.dll!ConsoleIoThread(void)
kernel32.dll!00007ffa07c61fe4()
ntdll.dll!00007ffa09b7f061()

And the exact line in the assembly was:

00007FF9E50DCE99 66 F3 AB             rep stos    word ptr [rdi]

But hopefully it should be easy for you to reproduce. It happens for me every time.

[zadjii-msft]

I KNEW IT.

As soon as you said there was some weird crash, I knew it was this issue. I'd seen it at home a couple times, usually when an ssh session disconnects while I had tmux open, it would crash after switching back to the main buffer, but I'd only ever seen it a few times, and always forgotten about it before I got to work.

THANK YOU for reminding me to actually take a look at this, and provide a simple repro and stack.

IIRC we did a bunch of work to get rid of our memsets, so hopefully this is gone, but I've filed a bug to make sure and fix it if it's not.

[miniksa]

I figured this out today and have a fix going to PR. I'll update when it's on the way up and out to Insiders.

[DHowett-MSFT]

It looks like this went out with 1809. Thanks!