Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
When the common language runtime (CLR) calls certain methods in the ICorProfilerCallback interface, the runtime cannot perform a garbage collection until the profiler returns control from that call. This is because profiling services cannot always construct the stack into a state that is safe for a garbage collection. Instead, garbage collection is disabled around that callback. In these cases, the profiler should return control as soon as possible. This situation applies to the following callbacks:
ICorProfilerCallback::ExceptionOSHandlerEnter, ICorProfilerCallback::ExceptionOSHandlerLeave
ICorProfilerCallback::ExceptionUnwindFunctionEnter, ICorProfilerCallback::ExceptionUnwindFunctionLeave
ICorProfilerCallback::ExceptionUnwindFinallyEnter, ICorProfilerCallback::ExceptionUnwindFinallyLeave
ICorProfilerCallback::ExceptionCatcherEnter, ICorProfilerCallback::ExceptionCatcherLeave
ICorProfilerCallback::ExceptionCLRCatcherFound, ICorProfilerCallback::ExceptionCLRCatcherExecute
ICorProfilerCallback::COMClassicVTableCreated, ICorProfilerCallback::COMClassicVTableDestroyed
In addition, the following callbacks allow the profiler to block garbage collection, call by call, by using the fIsSafeToBlock parameter:
Note that if the profiler does block, it will delay garbage collection. This delay is harmless as long as the profiler does not call a CLR function that triggers a garbage collection or allocates space in the managed heap.
See Also
Concepts
Garbage Collection in the Profiling API