SQL Server Dedicated Admin Connection (DAC): How to Connect When the Server Won’t Respond

When SQL Server hangs, stops accepting new connections or sits at 100% CPU, connecting with SSMS is often impossible. For exactly these moments, SQL Server keeps a small reserved door: the Dedicated Admin Connection (DAC). The DAC is a single-user diagnostic connection with its own scheduler and reserved resources, available only to members of the sysadmin role.

This guide explains when the DAC helps, why it should be enabled in advance, how to connect, and what to do and not do once you’re in.

When Does the DAC Help?

• SQL Server doesn’t accept new connections because worker threads are exhausted.
• A heavy blocking chain or a runaway query has locked up the server.
• Nobody can log in because of a bug in a logon trigger.
• Normal connections time out, but the service is still running.

In these situations the first reflex is often to restart the service. But a restart can roll back long transactions and send databases into a long recovery, and the cause of the problem disappears with it. The DAC lets you get in and see what’s happening before you restart.

Enable It First: Remote Admin Connections

By default the DAC can only be used from the server itself. To connect through the DAC from a remote machine, for example from SSMS on your own computer, the remote admin connections option must be enabled:

EXEC sys.sp_configure N'remote admin connections', 1;
RECONFIGURE;

No restart is needed; the DAC listener starts accepting remote connections immediately. You can also set this in SSMS by right-clicking the server and using the RemoteDacEnabled property under Facets › Surface Area Configuration:

How to Connect with the DAC

With sqlcmd

In a crisis, sqlcmd is the most reliable route: it uses few resources and doesn’t open extra connections. The -A switch requests the DAC, and -d master skips the login’s default database and connects straight to master:

sqlcmd -S SERVER -E -A -d master
sqlcmd -S SERVER\InstanceName -E -A -d master

If the login’s default database is unavailable, the connection fails with error 4060; -d master avoids that, because master is always available while the instance is up.

With SSMS

1. In a new SSMS window, turn off IntelliSense in the Transact-SQL IntelliSense settings under Tools › Options.
2. Don’t use Object Explorer; open a query window with File › New › Database Engine Query.
3. In the Server name field, enter admin:SERVER or admin:SERVER\InstanceName.

Port and named instances

The DAC listens on TCP 1434 if available, otherwise on a port assigned dynamically at startup. The error log shows which one:

EXEC sys.xp_readerrorlog 0, 1, N'Dedicated admin connection';

For remote connections, this port must be open in the firewall. For named instances, the client asks SQL Server Browser for the port; if Browser isn’t running, specify the port explicitly: sqlcmd -S tcp:SERVER,PORT -E. To save resources, SQL Server Express only listens on the DAC port when started with trace flag 7806.

What to Do on the DAC

The resources reserved for the DAC are deliberately limited. Parallel queries don’t run, and BACKUP and RESTORE fail with error 3637. The DAC is for diagnosis: seeing what’s going on and, if necessary, ending the session that caused the problem.

First confirm that you’re on the DAC, then find the requests behind the hang:

-- On the DAC, this returns DACGroup
SELECT wg.name AS workload_group
FROM sys.dm_exec_sessions AS s
JOIN sys.dm_resource_governor_workload_groups AS wg ON wg.group_id = s.group_id
WHERE s.session_id = @@SPID;

-- Keep your own session from being blocked
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET LOCK_TIMEOUT 2000;

-- Running requests, wait types and the blocking chain
SELECT r.session_id, r.blocking_session_id, r.status, r.command,
       r.wait_type, r.wait_time, r.cpu_time, r.total_elapsed_time,
       DB_NAME(r.database_id) AS database_name,
       s.login_name, s.host_name, s.program_name,
       SUBSTRING(t.text, 1, 400) AS sql_text
FROM sys.dm_exec_requests AS r
JOIN sys.dm_exec_sessions AS s ON s.session_id = r.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.session_id <> @@SPID
ORDER BY r.total_elapsed_time DESC;

Microsoft’s guidance draws the same line: light DMV and catalog queries, basic commands such as DBCC SQLPERF, and KILL if needed. Resource-intensive operations such as DBCC CHECKDB, index rebuilds or heavy DMVs that scan the version store shouldn’t be run on the DAC.

Before You Use KILL

Once you’ve found the session causing the problem, KILL can look like the only option. But KILL doesn’t erase a transaction; it rolls it back. Killing work that has run for hours can start a rollback that takes at least as long, and the session can stay stuck in KILLED/ROLLBACK. So first look at what the session is doing, how long it has been running and who started it, and talk to the owner if you can. Our outage runbook describes how we make these calls during an outage.

DAC Readiness Checklist

• remote admin connections is 1 on every production server and cluster node.
• The DAC port is confirmed in the error log and open in the firewall from the management network.
• The team knows who uses the DAC; the sqlcmd command is ready in the runbook.
• The crisis queries (like the ones above) have been tested in advance.
• For Express editions, starting with trace flag 7806 is planned where needed.