Troubleshooting Winsock 10060 Errors when using Dameware

10/30/2018 11:29 PM

8/11/2025 9:51 PM

Winsock Connect Error
System Error: 10060
Connection timed out. A connection attempt failed because the connected party did not properly respond after a period of time, or an established connection failed because the connected host has failed to respond.

Please keep in mind that Winsock Errors are Microsoft Windows Sockets (TCP) errors, not Dameware errors, and typically when a Winsock 10060 error is reported it's typically either due to an improperly configured firewall (hardware or software), a Names Resolution issue, or even improper routing within your network implementation (especially when VPNs or multiple NICs are involved). These configuration issues then cause the TCP Socket to timeout, which then causes the Winsock 10060 error to occur. 

Unfortunately, there are no settings within our software that would either cause or prevent a Winsock 10060 error (or any other Winsock error) from occurring.

Right now, this error also appears after the migration of a domain controller

Dameware Remote Support & Mini Remote Control

• First, make sure that all routers and firewalls between the local and remote machines and any firewall software on the remote machine itself (such as Windows Firewall for SP2 or Vista) are properly configured to allow the necessary traffic to pass through.
  • SolarWinds software is compatible with any firewall (hardware or software), but you must properly configure the firewall to allow the necessary traffic to pass through. Otherwise, the connection will time out with a Winsock 10060 error.
  • Also, if you are currently using version 9.x or higher of the software, then after you install v9.x (or higher) of the MRC Client Agent Service on the remote machine and after the Client Agent starts up, it should automatically create a port exception in the Windows Firewall (under Vista or XP) for the specified TCP port used for communication (default is TCP 6129). But make note this does not open the ports required to remotely install, remove, start, or stop the MRC Client Agent Service--only the port specified to use for communication. 
  • Additionally, when using the MRC software over VPN connections to connect to these remote machines, you also need to keep in mind that the VPN may actually assign your local machine a different (VPN) IP-Address (depending on how your VPN is configured, and whether it's VPN software or hardware). So you would have to make sure this VPN range of assigned addresses are also properly configured in the Windows Firewall on these remote machines as well (under the Scope settings for each port).

 

• If you haven't already done so, you should also take a look at our performance KB article on our website, because it explains the techniques for reducing CPU% or reducing bandwidth/increasing performance over your MRC connections.  However, you may also want to make sure all these remote machines are running the most current Video Drivers, NIC Drivers, etc... 
  • Basically, try cranking up your compression to Maximum, increase your scan blocks, increase the delay between scan block updates, disable all desktop effects, use Force 4-bit color or 8-bit color, turn off encryption, and attempt to address anything possible to reduce the amount of data being sent over the wire.
  • For version 5.x and above, you may also want to try using the Mirror Driver as well. Mirror Drivers are basically kernel-mode video drivers, which allows the software to retrieve video updates directly from the kernel without having to query the GDI subsystem. Once the Mirror Driver has been installed on the remote machine, simply enable the "Use MRC Mirror Driver (if available)" checkbox on the Remote Connect dialog before you click on Connect.
  • ​​​​​​​Just keep in mind that the Mirror Driver is so efficient that it may actually be too efficient for anyone using the software over very slow connection links. Therefore, you may also want to try selecting this Host Entry, and then click on the Settings button. Now select the Mirror Driver Tab (not the Display Options Tab), and then enable Force 8-bit display setting, and set Compression to 9 (Maximum). If this does not help your connection speeds, then also try disabling the "Use MRC Mirror Driver (if available)" checkbox, and then you can also try adjusting some of the aforementioned non-Mirror Driver performance settings.​​​​​​​

• For high latency connection links such as satellite connections, SolarWinds recommends that you try increasing the "Socket Logon Timeout" settings within the Mini Remote Client Agent Service on the remote machine. All the settings for the MRC Client Agent Service by default are stored within the DWRCS.INI file in the System32 folder on the remote machine (or optionally in the Registry). By default, it's set to Socket Logon Timeout=90000 (in milliseconds), so you can try doubling that value to start out. 
  • SolarWinds also suggests that you try tweaking some of the performance settings mentioned above (Compression, Scan Blocks, and the like) to help with performance as well.
     
• Although the Mini Remote Control program only requires a single TCP port (default is TCP 6129) for communication with the MRC Client Agent on the remote machine, other ports and protocols are required to remotely install, remove, start, or stop MRC Client Agent Service, basically known as the operating system's installed protocols, or "File & Printer Sharing" for short. Microsoft also defines File & Printer Sharing as UDP 137, UDP 138, TCP 139, & TCP 445.  
   
  • The Mini Remote Control program will first attempt a straight TCP connection to the remote machine, using the port that you specified for communication. If nothing is listening on this specified port (MRC Client Agent not installed, MRC Client Agent installed but not running, or incorrect port specified), the Mini Remote Control program will then drop out of its TCP mode and use the Operating System's installed protocols (see above) to interrogate the Service Control Manager (SCM) on the remote machine. This step is required to determine if the MRC Client Agent is already installed but possibly just in a stopped state. This is because you cannot install the Client Agent Service again if it's already installed on the remote machine. If for any reason the software is unable to communicate with the Service Control Manager on the remote machine (Access Denied, ports blocked, or similar), then the software will not be able to connect and has will fail, displaying the appropriate Winsock Error.
     
  • Therefore, if the remote machine is on a different subnet than your local machine, or it's located behind some type of router or firewall, or it's currently running some type of firewall software (for instance, Windows Firewall), then you must make sure all the necessary ports are open between the local and remote machines. Otherwise, the connection will fail.
     
• Ensure that there is a network route to the remote host via the TCP protocol using the selected port (default port 6129). When dealing with VPN connections (or multiple subnets as well), it's possible that the data packets are being received by the remote machine, but based upon the remote machine's TCP configuration it doesn't know how to route the packets back to your local machine. In this scenario, adding a static route may fix the issue and can be made persistent, using route -p add xxxxxxxxx mask yyyyyyyy. This would have to be done either on the remote machine itself or on the remote machine's defined gateway.
   
• Lastly, if none of the suggestions above resolves your issues, find out if you are doing any type of port filtering or VLAN filtering, or if you have some type of application-layer firewall installed, even when defining specific access lists (ACLs) over VPN connections. You may have issues with any TCP Client/Server application anytime you're doing blocking or filtering outbound connections.

 

• In addition, you can also try connecting to the target computer using its IP address rather than its hostname.
   
  • To clarify, many users state that all they had to do in these scenarios was open TCP 6129 in both directions and it worked fine, even for ISA Server, which also contains an advanced application-layer firewall (similar to filtering traffic across VLANs). The reason you typically don't need to open these ports in both directions is that most firewalls cache outbound connections in order to make comparisons to inbound connections. Then, after an inbound connection is matched up to the initial associated outbound connection (based upon the header information), the traffic is allowed back through the firewall, no matter what port it comes back on. Blocking on outbound connections is not typically done in firewalls. However, filtering between VLANs does not work the same way firewalls do. It is more similar to an application-layer firewall where you must define specific ports used for each application in both directions. 
     
  • Anytime you have a true client/server application using the TCP protocol, then the operating system actually uses a different port for the return connection when it accepts the socket. So simply blocking inbound/outbound traffic by a port isn't the correct thing to do when you're working with Client/Server type TCP applications. 
     
  • Basically, the MRC Connection logic is simply just a standard Winsock (Windows Sockets) design of bind(), listen() and accept(), and on the Server (agent) when you accept() the inbound socket, the operating system will make a copy of that socket (creates a new socket) and then use a randomly assigned port in the range of 1024 - 5000 for this new socket. This is common for any socket server application (server service) because you cannot re-use the socket and continue to listen for new connections on the same port. 
     
  • In this scenario, you will have to try opening TCP 6129 in both directions, and then also set a source/destination rule to allow traffic emanating from TCP 6129 access to ports > 1024-5000 TCP to the other side.