SHUTDOWN is recorded when a SHUTDOWN statement is waiting for active connections to exit, specifically when the shutdown request is blocked behind queries being run by connections with sysadmin-level (sa) access. A graceful shutdown wants running work to complete; while it waits, the initiating thread sits here.
If SQL Server “will not shut down”, at least one thread will be showing this wait.
Is It a Problem?
It is a live diagnostic more than a statistic. Its cumulative total is trivia; its presence right now, during a shutdown that is dragging, tells you exactly what is happening: some session is still running, and the shutdown is honouring it. The clock matters most during patching windows and cluster failovers, where a hung shutdown extends the outage.
The resolution is always the same: find who is blocking the shutdown and decide their fate.
Common Causes
- Long-running queries or transactions still active when
SHUTDOWNwas issued. - Maintenance jobs (index rebuilds, CHECKDB) running at shutdown time.
- An administrative session mid-operation that nobody remembered.
What To Do
- Identify the runners:
sys.dm_exec_requests(from another connection) shows active sessions and their statements. - Decide per session: wait it out, or
KILLit and accept the rollback. Remember big transactions roll back slowly; killing them can extend the wait, not shorten it. - For planned maintenance, drain first: stop Agent jobs, block new connections, let work finish, then shut down.
SHUTDOWN WITH NOWAITexists for emergencies but skips the graceful steps.
How To See It
During a hung shutdown, sys.dm_os_waiting_tasks shows the SHUTDOWN waiter; in Get-WaitStatistics history it appears only as a footnote of past shutdowns.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply