“I Can’t See the SQLServer!” – Establishing the Fault Domain

“I Can’t See the SQLServer!” – Establishing the Fault Domain

By Jim Hudson, Senior Technology Evangelist, OakTree Staffing & Training

Aaaah! I can’t see the SQL Server!

Ok, first take a deep breath. I’ve broken more systems by freaking out than just making mistakes. What works? What doesn’t? Did it ever work? What changed?

We’re going to take a look at 3 command line tools to help us establish the fault domain. What’s a fault domain? It’s where it’s broken. It’s the reason the doctor asks you where it hurts. SQLServer is made up of a lot of moving parts. Our job is to decide which parts don’t fit together or are broken.

The tools are:


And no, they aren’t case sensitive. Some of the command line arguments are. If you see an UPPERCASE argument in the following examples, they need to be.

The command:

net start | findstr /I sql

This will give us a list of running SQLServer related services. “Net Start” will give a list of running services. The “findstr” command will restrict it to lines that contain the string ‘sql’. This keeps us from getting buried under output we don’t want to see. I don’t know about you, but when things break, I’m stressed. That doesn’t make me smarter.

At the very least we should see something that looks like this:


– or you may see an entry that points to a named instance. If you have no entry that says “SQL Server” then the SQLServer service isn’t started and it’s time to go look at the Application Event Log and the SQL Server logs to figure out why.

Assuming the service is started, the next issue is whether it is listening on the network. Now, if this is a development instance, you may not want it listening on the net. At that point use either “sqlcmd” or the SSMS tool to test connection.

We can use:

netstat -ano | findstr /I 143 | findstr /I listen

This command is used to see if there are any listening ports on either 1433 or 1434. If you get any output from that command, you are probably listening on the network. The version and configuration of your SQLServer installation will affect which exact ports are listening, but in 22 years of troubleshooting SQLServer I’ve never found a functional SQLServer that wasn’t listening on one of those two ports.

If these gave good output and you still can’t connect, it’s time to open the SQL Configuration Manager, the Event Logs, and the SQLServer logs for further info.

Good Luck!

Interest in learning more? We can definitely help.

Learn more about OakTree

Leave a Reply

Close Menu