Fix inconsistent newline format when logging exceptions to console.

[lateralusX]

The introduction of minipal_log_write API's have flushed out some inconsistency in newline format used on Windows. Previously the Windows implementation logged exceptions to console using WriteFile together with STD_ERR_HANDLE. It turns out that the file mode of this handle is binary, while the file mode for regular stdout/stderr is text mode. minipal_log_write API uses underlying _write instead of WriteFile and the fd associated with stdout/stderr, but since they are in text mode, pre-formatted data intended for binary output will expand \r\n to \r\r\n that could cause side effects due to additional \r character in the stream. The use of WriteFile handled this case, but we also mixed regular \n using the same API, that won't be expanded to \r\n when written to a file in binary mode leaving us with output using different line endings through the same logging.

Normally all logging performed from native code use \n and expects it to be replaced to \r\n on Windows as part of logging through a file in text mode. Some data formatted in managed code intended for output is already pre-formatted, using \r\n, intended for files in binary mode. One area where we mix line ending formats is the logging of unhandled exception call stacks, where we currently mix formatted newlines \r\n with \n.

This fix implement support in minipal_log_write to detect if logging should go through binary file mode on Windows, and since this is the default on none Windows platforms its a noop on all other platforms. Since we already needed to take strlen in minipal_log_write, the fix integrate logic to also check for \r\n pattern while calculating the length, leading to no additional pass over the string to detect if a logging needs to go into binary mode instead of default mode..

Fixes #114579

[Copilot]

Pull Request Overview

This PR fixes inconsistent newline formatting when logging exceptions on Windows by introducing a new binary logging mode flag.

• Adds a new flag (minipal_log_flags_binary) and related macros in log.h
• Updates logging functions in log.c to choose between binary (WriteFile) and text (_write) logging
• Modifies PrintToStdErr functions in util.hpp/util.cpp and related calls in excep.cpp and eepolicy.cpp to support binary logging mode

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/native/minipal/log.h	Introduces binary flag and macros for flag manipulation
src/native/minipal/log.c	Refactors logging functions to use the new binary flag appropriately
src/coreclr/vm/util.hpp	Updates PrintToStdErr function signatures to accept a binary flag
src/coreclr/vm/util.cpp	Implements changes in PrintToStdErr functions using the new flag
src/coreclr/vm/excep.cpp	Adjusts exception logging to use binary mode for pre-formatted data
src/coreclr/vm/eepolicy.cpp	Updates logging calls to pass the binary flag where appropriate

Comments suppressed due to low confidence (1)

src/coreclr/vm/excep.cpp:4798

• [nitpick] Consider explicitly specifying the binaryOutputMode parameter in the PrintToStdErrA call (e.g., PrintToStdErrA("\n", TRUE)) for consistency with the preceding PrintToStdErrW call that uses binary output mode, unless the default behavior is intentional.

PrintToStdErrA("
");

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[lateralusX]

Looking into taking this fix closer to minipal_log_write internals, stay tuned.

[janvorli]

LGTM, thank you!

[lateralusX]

Looks like the failure in NET481 happened on other PR\s as well, https://helixr1107v0xdcypoyl9e7f.blob.core.windows.net/dotnet-runtime-refs-pull-114783-merge-677c12ce065b4a5b86/System.Net.Http.WinHttpHandler.Functional.Tests/3/console.24750079.log?helixlogtype=result

It is fixed here, #114790.

[lateralusX]

So if we end up with that as the only failure blocking build analysis, I think we can override and merge. @jkotas, agree? If so maybe we should try to get this in before preview 4 branch?

[lateralusX]

/ba-g Failing test has been fixed here, #114790.