Windows Terminal hangs when printing certain emoji #963

Closed
opened 2026-01-30 22:12:34 +00:00 by claunia · 12 comments
Owner

Originally created by @ritchiehughes on GitHub (May 10, 2019).

  • 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 '??':

image

image

No repro in classic cmd.exe

Originally created by @ritchiehughes on GitHub (May 10, 2019). * 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. ```csharp 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}]"); } } } } } ``` ```xml <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 '??': ![image](https://user-images.githubusercontent.com/18265132/57547709-4ecf5580-731c-11e9-8e2e-3e8947766662.png) ![image](https://user-images.githubusercontent.com/18265132/57547987-1c722800-731d-11e9-968f-9726a896200d.png) No repro in classic cmd.exe
Author
Owner

@miniksa commented on GitHub (May 10, 2019):

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.

@miniksa commented on GitHub (May 10, 2019): 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.
Author
Owner

@5HT commented on GitHub (May 10, 2019):

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.

@5HT commented on GitHub (May 10, 2019): 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.
Author
Owner

@miniksa commented on GitHub (May 10, 2019):

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

@miniksa commented on GitHub (May 10, 2019): If you can give me the hex code for them, it's optimal. Sorry, that's what I was trying to imply.
Author
Owner

@5HT commented on GitHub (May 10, 2019):

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]

@5HT commented on GitHub (May 10, 2019): 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]
Author
Owner

@miniksa commented on GitHub (May 10, 2019):

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!

@miniksa commented on GitHub (May 10, 2019): 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!
Author
Owner

@ritchiehughes commented on GitHub (May 10, 2019):

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.

image

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

@ritchiehughes commented on GitHub (May 10, 2019): 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. ![image](https://user-images.githubusercontent.com/18265132/57549785-b5a33d80-7321-11e9-8e54-aa1d8c56aa2c.png) Line format = [(sequence), (name), (codepoint), 10 x character)]
Author
Owner

@miniksa commented on GitHub (May 10, 2019):

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.

@miniksa commented on GitHub (May 10, 2019): 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.
Author
Owner

@mlindgren commented on GitHub (May 13, 2019):

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

@mlindgren commented on GitHub (May 13, 2019): @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.
Author
Owner

@j4james commented on GitHub (Jan 23, 2020):

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.

@j4james commented on GitHub (Jan 23, 2020): 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.
Author
Owner

@zadjii-msft commented on GitHub (Jan 23, 2020):

@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

@zadjii-msft commented on GitHub (Jan 23, 2020): @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
Author
Owner

@ghost commented on GitHub (Jan 23, 2020):

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 (Jan 23, 2020): 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!
Author
Owner

@ghost commented on GitHub (Jan 23, 2020):

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 (Jan 23, 2020): 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!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#963