我想知道在.net Framework Profiler中，是否可以保证ExceptionThrown（https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/profiling/icorprofilercallback-exceptionthrown-method）与GC不重叠？
在查看文档时，它看起来像这样-“如果事件探查器在此处阻塞并尝试进行垃圾回收，则运行时将阻塞，直到此回调返回为止”
但是，我将我的探查器附加到paint.net（https://www.getpaint.net/-版本4.1.6）上，并看到了在ExceptionThrown期间获得GC的特定情况。 （但这是非常罕见的-仅在启动时发生，并且大约每20次运行中发生一次）-由于gc进行了数据移动，导致数据在我正在读取时发生了更改。
至少在.net核心版本-https://github.com/dotnet/coreclr/blob/master/Documentation/botr/profiling.md中，它明确说明了哪些回调是GC调用安全的。 ExceptionThrown并不是其中之一。例如，ExceptionUnwindFunctionEnter。但是，回到.NET Framework-https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/profiling/icorprofilercallback-exceptionunwindfunctionenter-method-.NET Framework文档中有关GC的说明与ExceptionThrown相同。
我知道.NET core！= .NET框架。但是，我觉得他们的探查器的代码非常相似并且有相同的保证。我找不到有关.NET框架回调的GC安全性的类似资源。
因此，在完成所有介绍之后，我的问题是：
.NET Framework clr探查器ExceptionThrown回调应该是GC安全的。如果是这样，怎么可能在ExceptionThrown（CLR可能的错误或预期行为）期间看到GC调用开始和结束？
如果不是bug，我是否可以至少100％依赖.NET Framework clr profiler UnwindExceptionFunctionEnter回调基于基于core-clr的类似文档而具有GC安全性？
Thx
答案 0 :(得分：3)
是的，允许GC运行。 .NETCore接口与.NETFramework接口没有根本区别，github文档是准确的。
当您查看the CLR source时，很容易看到。尽管测试仪似乎已在鲍尔默峰（Ballmer Peak）进行操作，但他的合同主张必须准确。复制/粘贴相关代码：
Convert.ToBase64String // Preemptive mode would be bad, dude. There's an objectId in the param list!
MODE_COOPERATIVE;
宏指示已启用GC。 MODE_COOPERATIVE宏表示GC已延迟。