DEADLOCK_ENUM_MUTEX is recorded when the background deadlock monitor and the sys.dm_os_waiting_tasks DMV synchronise so that SQL Server never runs multiple deadlock searches at once. Computing blocking_session_id for the DMV’s output walks the same territory as a deadlock search, so the two take turns through this mutex.
An obscure but tidy piece of engine hygiene.
Is It a Problem?
No; it has not been a contention point. The only workload that could even theoretically nudge it is monitoring tooling polling sys.dm_os_waiting_tasks at very high frequency while deadlock searches run, and even then the amounts stay trivial.
Deadlocks themselves are diagnosed through the system_health deadlock graphs, and blocking through the DMVs; this mutex is just the turnstile between two internal readers.
Common Causes
- Normal alternation between the deadlock monitor’s searches and
sys.dm_os_waiting_tasksqueries. - Aggressive monitoring poll intervals raising the collision odds slightly.
What To Do
- Filter it out of wait analysis.
- If a monitoring tool hammers the waiting-tasks DMV every second, relaxing its interval is good citizenship anyway.
How To See It
Rank waits with Get-WaitStatistics; expect near-zero, always.
Part of the SQL Server Wait Types Library.
Related deep dive: LCK_M_X, LCK_M_S, and LCK_M_U Wait Types.
Leave a Reply