Windows Terminal hangs when printing certain emoji

[ritchiehughes]

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.18362.53]
  Windows Terminal: 0.1.1211.0 (this was a signed daily build of the appx)

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

Running this .NET Core app causes the Terminal to hang. This app uses Unicode.NET to generate emoji string encodings.

using NeoSmart.Unicode;
using System;
using System.Text;

namespace HangWindowsTerminal
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.OutputEncoding = Encoding.UTF8;

            foreach (var emoji in Emoji.All)
            {
                try
                {
                    Console.Write(emoji.ToString());
                }
                catch (Exception e)
                {
                    Console.Write($"[FAILED: {emoji.Name} - {e.Message}]");
                }
            }
        }
    }
}

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.2</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Unicode.net" Version="0.1.2" />
  </ItemGroup>
</Project>

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

Once the loop gets to certain characters (with modifers?) the terminal hangs. Not always the same character. I'd expect problematic chars to be skipped or replaced with '??':

No repro in classic cmd.exe

[miniksa]

It would help me if you could identify exactly which codepoint is going through when it hangs to try to reduce this issue to the minimal repro.

[5HT]

A lot of them. Actually in the example states that exception happened at weary face 😩 emoji. But tired face 😫, weary cat face 🙀 are also the cases and it's counting. It doesn't happen in FAR and WSL, but does in CMD.

[miniksa]

If you can give me the hex code for them, it's optimal. Sorry, that's what I was trying to imply.

[5HT]

I'm not sure which one is used in CMD for weary face 😩:
It could be Clipboard Issue, but for this example it should be UTF-8.

UTF-8 (hex)	0xF0 0x9F 0x98 0xA9 (f09f98a9)
UTF-8 (binary)	11110000:10011111:10011000:10101001
UTF-16/UTF-16BE (hex)	0xD83D 0xDE29 (d83dde29)
UTF-16LE (hex)	0x3DD8 0x29DE (3dd829de)
UTF-32/UTF-32BE (hex)	0x0001F629 (0001f629)
UTF-32LE (hex)	0x29F60100 (29f60100)

Microsoft Windows [Version 10.0.18894.1000]

[miniksa]

U+1F629 is what I was looking for. Thanks. Presuming I get enough time to actually jump back into the code next week, I might look into this while I'm in the rendering pipeline anyway. Appreciated!

[ritchiehughes]

Hi @miniksa - it doesn't visually hang at exactly the same codepoint each time, which suggests that the actual issue is being masked by buffering somewhere. I attached to a debugger was able to step through to printing "woman student: medium-light skin tone (codepoint 01f469, 01f3fc, 00200d, 01f393)" (this is entry 186 from "Emoji.All" in the library I referenced). All I can see from managed code is that it's hung at:

System.Console.dll!System.ConsolePal.WindowsConsoleStream.WriteFileNative(System.IntPtr hFile, byte[] bytes, int offset, int count, bool useFileAPIs)

Here's another screenshot showing three runs where the output visually hangs at different points.

Line format = [(sequence), (name), (codepoint), 10 x character)]

[miniksa]

A hang on the managed side means that the call is probably being locked inside the console host servicing the API call. This will be fun to debug.

[mlindgren]

@miniksa I have also hit a hang when trying to input any emoji using the emoji panel (Windows key + ;). I don't have time to attempt to debug it, but it's a 100% repro for me. Feel free to contact me internally and I can provide a time travel trace if that would help.

[j4james]

This looks like another issue that has probably been fixed by PR #4150. I can reproduce the hanging with the example code in a preview build (v0.8.10091.0), but it's no longer happening in the master build.

I can't say that the output looks correct, mind you, but that's a separate issue. It at least doesn't hang anymore.

[zadjii-msft]

@j4james Thanks for taking the time to triage these issues! I bet you're right about this one as well. Since we've got another issue tracking the actual layout problems, lets close this one.

/dup #1360

[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!

[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!