Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[release/7.0] Enable logging managed stack trace for AV to event log #76428

Merged
merged 1 commit into from
Sep 30, 2022

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Sep 30, 2022

Backport of #75721 to release/7.0

/cc @janvorli

Customer Impact

.NET Framework was logging managed stack trace of access violations that happened in external native code in the event log. .NET core only logs the address and error code of the exception, which makes it difficult for developers to figure out which part of their managed code has called the failing native code on their customer's machines.

Testing

Local directed test, coreclr and libraries tests.

Risk

Very low, the change affects only the final part of fatal error process exit where we are enabling logging of the stack trace for one more case.

.NET Framework was logging managed stack trace of access violations that
happened in external native code in the event log. .NET core only logs
the address and error code of the exception, which makes it difficult
for developers to figure out which part of their managed code has called
the failing native code.
The reason why .NET core doesn't print the stack trace is that the
access violation is now handled as fail fast instead of regular
unhandled exception. And while we report managed stack traces in the
EEPolicy::FatalError for fail fasts called from our runtime and managed
code in both runtime and user code, we don't report it when we come to
that method due to the access violation.

This change enables printing the stack trace for that case too.
@janvorli janvorli self-assigned this Sep 30, 2022
@janvorli janvorli added this to the 7.0.0 milestone Sep 30, 2022
@janvorli janvorli added the Servicing-consider Issue for next servicing release review label Sep 30, 2022
Copy link
Member

@jeffschwMSFT jeffschwMSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved. this is good for overall diagnostics. we will take for consideration in 7 ga.

@jeffschwMSFT jeffschwMSFT added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Sep 30, 2022
@carlossanlop
Copy link
Member

Approved, signed off, CI is green. Ready to merge. :shipit:

@carlossanlop carlossanlop merged commit cb09ca7 into release/7.0 Sep 30, 2022
@carlossanlop carlossanlop deleted the backport/pr-75721-to-release/7.0 branch September 30, 2022 21:30
@ghost ghost locked as resolved and limited conversation to collaborators Oct 31, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-VM-coreclr Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants