ADB Failed To Check Server Version: Cannot Connect To Daemon | Quick Fixes

What This ADB Error Message Really Means

When adb prints adb failed to check server version: cannot connect to daemon, it is telling you that the client on your terminal could not talk to the background adb server process that lives on your machine.

The server is a small program inside adb that listens on TCP port 5037 and keeps track of every phone, tablet, or emulator attached to your computer.

The client side is every adb command you run in a shell window. Each command reaches out to the server, asks for the server version, and then forwards your request to the connected devices.

If the client cannot reach that server at all, or the server cannot answer with a readable version string, you see a message that mentions failed to check server version, protocol fault, or cannot connect to daemon before the command stops.

On many systems the root reason is simple, such as another program already using port 5037, a half crashed adb process, or two different adb installs fighting with each other for control.

Once you know that the message is about a broken link between client and server, the rest of the fix turns into a methodical checklist instead of random reinstall attempts.

Common Causes Of ADB Failed To Check Server Version: Cannot Connect To Daemon

This adb cannot connect to daemon problem shows up on Windows, macOS, and Linux with very similar triggers, even though the tools around it differ a bit on each system.

• Port 5037 is already taken — Another tool or a stale adb process can grab the default adb port, so the fresh server never starts in a clean way.
• Multiple adb binaries installed — A system package, Android Studio, Genymotion, or other tools can each ship their own adb and confuse the command path.
• Mixed client and server versions — An old server tries to answer a newer client, or the other way round, and the handshake fails with a version error.
• Broken Android SDK folder — Platform tools that were only partially updated can leave adb in a loop where it restarts but never reaches a steady state.
• Permissions or firewall blocks — On Linux and macOS the user may not belong to the right device group, and on Windows a firewall or antivirus product can block local TCP traffic on the adb port.

Once you have a feel for these patterns, you can clear the adb failed to check server version: cannot connect to daemon message in a few focused rounds instead of reinstalling everything in sight.

Quick Checks Before You Change Anything

Start with a few quick checks so you do not spend time on heavy reinstall steps if a small tweak is enough.

1. Run adb version — Open a fresh terminal window and run adb version so that you see which binary is in use and whether it prints a normal version string.

adb version
which adb    # macOS or Linux
where adb    # Windows PowerShell or cmd

The output line that shows the full path to adb tells you if commands point to platform tools inside your Android SDK or to a system wide install from a package manager.

2. List connected devices — Run adb devices -l and note the exact failure text that comes back from adb, including any protocol fault or reset by peer lines.

adb devices -l

If the tool hangs on starting the daemon or prints protocol fault, the client did not finish its handshake with the server, which matches the failed to check server version warning.

3. Check port 5037 usage — Inspect which process, if any, already listens on the adb port 5037.

# Windows
netstat -ano | findstr 5037

# macOS or Linux
lsof -i:5037 || netstat -anp | grep 5037

If the only process on that port is adb itself, the port is fine and you can move on to the deeper fixes in the next section.

Step By Step Fixes On Your Local Machine

Work through these fixes in order, testing adb devices after each step so you always know which change helped and you do not break a setup that already works.

Restart The Adb Server Cleanly

Many users see the error only once after a crash, a sleep cycle, or a long run of emulators, and a clean restart of the server is enough to restore the link between client and daemon.

• Kill the current server — Run adb kill-server in a terminal to stop any running instance of the adb daemon.
• Start a fresh server — Run adb start-server and watch the log text for a normal daemon started successfully line without new errors.
• Try a client command — Run adb devices and confirm that the cannot connect to daemon message disappears or at least changes to a more direct hint.

If the error returns as soon as you run another command, the root problem sits deeper than a one time crash and you can move on to the next fix.

Remove Conflicting Adb Installations

On Linux distributions with android tools packages or on systems that have Genymotion or similar tools, it is common to have more than one adb binary on disk at the same time.

• Locate every adb binary — Use whereis adb on Linux or a system wide file search on Windows to find each copy of the tool.
• Keep the SDK copy — Leave the adb that lives under your Android or command line tools SDK platform tools folder in place, since that copy follows Android Studio updates.
• Disable the others — Rename or move the extra adb binaries so that they no longer sit on the default system path and cannot start their own server.
• Reset your path — In your shell profile on macOS or Linux, make sure that platform tools are the first adb entry in the path variable you export.

After that cleanup, new terminals will only run the single adb from your SDK, which removes version mismatches between a system package and the tools that ship with Android Studio.

Fix Port Conflicts And Stuck Processes

If earlier checks showed a foreign task on port 5037, or if adb prints connection reset by peer, clear that port before trying again so the new server can bind cleanly.

• Identify the blocking process — From your netstat or lsof output, copy the process id that holds port 5037 on your host.
• End the task once — Use Task Manager on Windows or kill on macOS and Linux so that the program lets go of the port.
• Restart adb — Run adb kill-server followed by adb start-server, then call adb devices again.
• Run adb in foreground if needed — Use adb nodaemon server to start the server in the foreground so you can watch log lines and see exactly where the connection fails.

This mix of checks handles cases where browsers, test tools, or past adb sessions parked themselves on the default port and stopped the new server from answering version checks.

Refresh Your Android Platform Tools

If nothing else helps, the adb binary itself might be damaged or out of sync with your devices, especially after partial SDK updates or manual file copies.

• Update platform tools through the SDK manager — In Android Studio or the command line tools, update to the latest platform tools package from the official Android site.
• Reinstall standalone tools if needed — On machines without Android Studio, download the recent platform tools zip from the Android developer site and extract it to a clean folder.
• Point your path to the new folder — Adjust the path so that the fresh platform tools directory is the first place the shell looks for adb when you open a new terminal.

Newer platform tools bring bug fixes for adb itself and often clear subtle handshake issues that lead to failed to check server version messages even when cables and devices are fine.

Project And Device Settings That Break Adb

Even with a healthy server on your computer, some device side settings and host system rules can still stop adb from talking to the daemon that runs on each phone or tablet.

Reset USB Debugging And Developer Options

• Toggle developer options — On the Android device, switch Developer options off, wait a short moment, then turn it back on again.
• Toggle USB debugging — Turn USB debugging off and on so that the trust dialog appears the next time you plug the device into your computer.
• Accept the RSA fingerprint — When the device prompts you to allow USB debugging, tick Always allow from this computer and tap Allow.
• Replug the cable — Disconnect and reconnect the USB cable, using a direct port instead of a hub whenever possible, and try a different cable if devices stay offline.

This reset chain forces Android to rebuild its debug bridge trust with your machine, which can clear stale records that leave devices stuck in an offline state even while the daemon itself runs.

Check Permissions, Groups, And Firewalls

On many Linux systems, users need a specific group entry to talk to devices over adb, while on Windows a strict firewall can block local TCP calls even though both ends live on the same computer.

• Confirm user groups on Linux — Add your account to an adbusers or plugdev group if your distribution uses one, then log out and back in so the change takes effect.
• Allow adb through the firewall — On Windows Defender or third party security tools, create a rule that lets adb.exe open local TCP connections on port 5037.
• Run a single adb instance — Keep only one Android Studio window, emulator set, or command shell using adb at a time while you debug this error.

Once the operating system no longer blocks the server from binding to its port or talking to devices, adb commands usually start to behave in a consistent way again.

When ADB Failed To Check Server Version: Cannot Connect To Daemon Keeps Coming Back

If you work on Android code every day, you might see this adb error return after a reboot, a tool update, or a long run of emulator sessions that leave old processes behind.

• Create a simple health script — Write a small shell or batch script that runs adb kill-server, starts the server again, and prints adb devices so you can reset the bridge with one command.
• Stick to one source of truth — Keep a single Android SDK folder per machine when you can, and avoid mixing adb from system packages with the one inside platform tools.
• Watch for port 5037 reuse — Any time network tools, browsers, or security tools change, run a quick netstat scan to make sure nothing new has taken the adb port.

With these habits in place, this adb daemon connection error turns from a blocker into a short nuisance that you can clear in a minute or two, instead of a problem that interrupts every development session.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback