Troubleshooting TempDB Log Full Errors When SSMS Won't Connect

Have you ever received the dreaded error from SQL Server that the TempDB log file is full? Only to open SSMS and be greeted with a message that prevents you from connecting.

Oh no.. my number one troubleshooting tool is not usable. Time to fire up a command prompt and connect via DAC, right?

Well, not so fast.

During a recent technical interview, I was introduced to a clever workaround that lets you connect to a distressed SQL Server using SSMS, even when it seems unresponsive.

The SSMS Workaround

Here’s how to bypass the connection issue and get back into SSMS:

Open SSMS and connect to a healthy SQL Server instance (not the one experiencing issues).
Open a New Query window.
In the query window, click the Change Connection icon (top-left corner).
Enter the connection details for the problematic server.

Volla, you now have a query window connected to the troubled instance. From here, you can begin your investigation.

Diagnosing the Issue

Start by identifying active sessions. For example:

SELECT session_id, blocking_session_id, wait_type, wait_time, status
FROM sys.dm_exec_requests
WHERE database_id = DB_ID('tempdb');

SELECT session_id, blocking_session_id, wait_type, wait_time, status

FROM sys.dm_exec_requests

WHERE database_id = DB_ID('tempdb');

Let’s say you discover that SPID 57 is causing blocking in TempDB. You can dig deeper with:

DBCC INPUTBUFFER(57);

1	DBCC INPUTBUFFER(57);

Once you’ve confirmed the culprit, you can terminate the session:

KILL 57;

KILL 57;

After that, try reconnecting to SSMS normally. With the blocking session cleared, you should be able to perform a deeper dive into TempDB usage or other root causes.