CLR_AUTO_EVENT is recorded when a task running Common Language Runtime (CLR) code waits on an auto-reset event, which in practice is mostly CLR worker threads waiting for something to do. If CLR integration is enabled, and several built-in features use it internally even when you never wrote a .NET assembly, these threads exist and mostly idle.
Books Online says it plainly: long waits are typical and do not indicate a problem.
Is It a Problem?
Almost never. It belongs on the benign filter list, and its totals track uptime and CLR thread pool size, not workload health. Many instances accumulate it purely from internal CLR usage (spatial types, hierarchyid, replication components) without a single user assembly deployed.
The narrow exception: if you run your own unsafe assemblies that use AutoResetEvent for cross-thread signalling, waits here can reflect your code’s synchronisation behaviour, and only then is it worth reading. For safe assemblies, ignore it entirely.
Common Causes
- Idle CLR worker threads on any instance with CLR integration active.
- Internal engine features using CLR under the covers.
- Custom unsafe assemblies doing their own thread signalling (rare).
What To Do
- Filter it out; our
Get-WaitStatisticsscript excludes it by default. - If you maintain unsafe CLR assemblies and this wait tracks their behaviour, review the assembly’s threading rather than the server.
- Change no server settings on account of this wait.
How To See It
Rank waits with Get-WaitStatistics, where it is filtered as background noise.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply