Uh oh!
There was an error while loading. Please reload this page.
[release/7.0] Fix FailFast logging message - #75718
Conversation
ghost
commented
Sep 15, 2022
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
carlossanlop
commented
Sep 15, 2022
@eduardo-vp what branch are you trying to target? Do you want this change backported to RC2 or to GA?
|
janvorli
commented
Sep 15, 2022
@carlossanlop I think that GA is ok for this. |
carlossanlop
commented
Sep 15, 2022
Thanks @janvorli for the confirmation. Since this is GA, can one of you please fill the template, then send an email to Tactics for approval? |
janvorli
commented
Sep 15, 2022
Yes, @eduardo-vp will do that. |
jeffschwMSFT
left a comment
There was a problem hiding this comment.
approved. we will take for consideration in RC2. Can you take a look at the ci failures and get a code review?
carlossanlop
commented
Sep 16, 2022
Approved via email by Tactics. |
carlossanlop
commented
Sep 19, 2022
CI green. Approved and signed off. Ready to merge. |
Backport of #75685 to release/7.0
/cc @eduardo-vp
Customer Impact
When the customer's app crashes due to an exception like access violation in an external native code, the customer doesn't get the crash address and error code in the event log entry (there is an
xinstead due to a bug). This change is a regression from .NET 6.Testing
A function in an external native code file with a memory access crash was used by a managed app. In the Event Viewer app it could be found the logs with the correct information.
Risk
Very low, this change only involves formatting character for the FormatMessage Windows API from a wrong one that doesn't format the values to a correct one and adds 0x prefix.