[Release/8.0] Remove preventing EH at shutdown

[janvorli]

Backport of #100293 to release/8.0

Customer Impact

During the runtime shutdown, we stop handling exceptions at all and we also prevent entering EE at few places. A customer has hit an issue with Watson dump being generated from a .NET app on every machine reboot due to that. That app was a networking app that was listening on a socket. Shutdown of the app resulted in a SocketException being thrown, but the exception handling was prevented and so the exception was reported as an unhandled exception which caused the dump to be taken.

Testing

CI testing, local testing of a case equivalent to what the customer had - a grpc running as a service. Without the fix the issue reported by the customer can be reproduced, with the fix it is gone.

Risk

Low - the change just enables exceptions handling during shutdown. So where previously the app would crash with an unhandled exception, it will now get proper handling of that exception upto the point the process is torn down by the OS.

[jeffschwMSFT]

removing the servicing-consider for now. given the low/medium risk, let's ship a preview of 9 and check for feedback and then consider a backport

[jkotas]

• This issue existed since .NET Core 1.0. Why did we not hear about it earlier? Did some other change make it much more likely to be hit?
• Is the full backport of the original PR required to address the customer issue? Should we do a smaller more targeted backport for servicing to reduce the risk?

[janvorli]

This issue existed since .NET Core 1.0. Why did we not hear about it earlier? Did some other change make it much more likely to be hit?

I think the issue wouldn't reproduce in the customer's scenario if the issue #83093 wasn't there. That issue was introduced by changes in the CNTRL_SHUTDOWN_EVENT handling. Also, we disable software exceptions only on x86, so the app has to be a x86 windows service that is running during shutdown. Moreover, the issue is not observable if watson dumps are not enabled on the machine. So, I guess that is what's making the issue occurrence and observability low.

Is the full backport of the original PR required to address the customer issue? Should we do a smaller more targeted backport for servicing to reduce the risk?

That is a good point. I can scale it down to just remove the g_fNoExceptions, which is sufficient to fix the issue for the customer. The change would then be much smaller and I would then reclassify the risk as being low. @jeffschwMSFT does that make sense to you?

[jeffschwMSFT]

That is a good point. I can scale it down to just remove the g_fNoExceptions, which is sufficient to fix the issue for the customer. The change would then be much smaller and I would then reclassify the risk as being low. @jeffschwMSFT does that make sense to you?

My preference is a lower risk fix which addresses the customer issue (eg. they validated that their scenario is now working as expected).

[janvorli]

@jeffschwMSFT I have scaled down the change considerably to address just the issue the customer has reported. I believe the risk is low now, so I have re-added the servicing-consider tag.

[jeffschwMSFT]

lgtm. I will take for consideration for 8.0.x.

please get a code review and ensure the customer has signed off that this addresses their issue.