SQLCLR_APPDOMAIN is recorded while CLR execution waits for an application domain to complete startup. SQL Server hosts .NET code in appdomains (one per database/owner combination, broadly), and the first CLR call after an appdomain has been created, or recreated, pays the startup cost. Sessions arriving during that startup wait here.
Steady state, appdomains stay loaded and this wait stays quiet.
Is It a Problem?
Occasional blips after restarts or first use are the design. The pattern that hurts is appdomain cycling: something repeatedly unloads the appdomain (memory pressure being the classic trigger, also assembly changes and certain unhandled exceptions), and every reload makes callers queue on this wait while the domain spins up again. The error log narrates it plainly with “AppDomain … unloaded” messages.
Frequent unload messages plus this wait equals CLR workloads stuttering.
Common Causes
- First CLR call after instance restart or assembly deployment.
- Memory pressure forcing appdomain unloads, then reload costs on next use.
- Unhandled exceptions or escalation policy events tearing an appdomain down.
What To Do
- Check the error log for appdomain unload/load message pairs and their stated reasons.
- If memory pressure drives unloads, address the memory story (max server memory, what else squeezes the box); CLR appdomains are early eviction victims.
- Keep CLR assemblies lean and exception-safe so they do not bring their own domain down.
How To See It
Rank it against everything else with Get-WaitStatistics, and pair it with the error log’s appdomain messages for the full story.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply