Four waits cover CLR assembly loading and task startup, and this page covers them together:
ASSEMBLY_LOAD: exclusive access while an assembly loads into memory; concurrent first-callers of the same assembly queue here.ASSEMBLY_FILTER_HASHTABLE: threads inserting into or iterating the hash table of CLR hash values used to track assemblies.CLR_CRST: a task in CLR execution waiting to enter a critical section another CLR task holds.CLR_TASK_START: waiting for a CLR task to complete startup (preemptive, so the thread stays on the processor).
Together they describe .NET code arriving and getting under way inside the engine.
Are They a Problem?
Rarely; none has been a contention point in normal use. Assembly loading clusters at first use and after appdomain reloads, so bursts of ASSEMBLY_LOAD usually mean an appdomain cycled (see SQLCLR_APPDOMAIN and the error log’s unload messages) rather than anything about the assemblies themselves. CLR_CRST is the one with a code-review angle: if it grows on a system running your own assemblies, some critical section in that .NET code holds threads too long, which is yours to profile.
What To Do
- For load bursts, check appdomain stability first (error log unload/reload pairs, memory pressure).
- For
CLR_CRSTgrowth on custom assemblies, review the .NET code’s locking; keep external calls out of held critical sections. - Filter the family in routine analysis otherwise.
How To See It
Rank waits with Get-WaitStatistics, reading them with the SQLCLR_* lifecycle waits for the full CLR picture.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply