Messages printed to STDERR by DefaultCatchHandler are not encoded correctly #45503
Description
Description
Unzip Repro.zip and run dotnet run.
The app spawns a new process and redirects its output. It sets the STDOUT and STDERR output encodings to Encoding.Unicode. The process sets Console.OutputEncoding to Encoding.Unicode as well. Then the process prints out a message to STDOUT via Console.WriteLine (encoded correctly) and triggers stack overflow. The stack overflow handler (DefaultCatchHandler in src/coreclr/src/vm/util.cpp) does not encode the string to the console output encoding though and the result is gibberish.
Actual output:
Child process started: 848
Child process running
Output: \uD808\uDF45
\u7453\u6361\u206B\u766F\u7265\u6C66\u776F\u0A2E\u6552\u6570\u7461\u3320\u3132\u3731\u7420\u6D69\u7365\u0A3A\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u200A\u2020\u7461\u4320\u6E6F\u6F73\u656C\u6E45\u6F63\u6964\u676E\u502E\u6F72\u7267\u6D61\u3C2E\u614D\u6E69\u673E\u5F5F\u7C46\u5F32\u2830\u0A29\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u2D2D\u200A\u2020\u7461\u4320\u6E6F\u6F73\u656C\u6E45\u6F63\u6964\u676E\u502E\u6F72\u7267\u6D61\u4D2E\u6961\u286E\u7953\u7473\u6D65\u532E\u7274\u6E69\u5B67\u295D
Child process exited: -1073741571
Expected output:
Child process started: 11928
Child process running
Output: \uD808\uDF45
Stack overflow.
Repeat 32137 times:
--------------------------------
at ConsoleEncoding.Program.<Main>g__F|2_0()
--------------------------------
at ConsoleEncoding.Program.Main(System.String[])
Child process exited: -1073741571
Configuration
dotnet --version
5.0.100
winver
Regression?
Not a regression.
.NET Framework has the same issue.
Notes
This issue shows up in Visual Studio when we attempt to work around another issue, where setting Console.OutputEncoding to Encoding.UTF8 throws "Invalid handle". Setting Console.OutputEncoding to Encoding.Unicode works and regular console output is correctly encoded but messages reported by DefaultCatchHandler are now garbled.