Submit a ticketCall us

Training ClassThe Orion® Platform Instructor-led Classes

Provided by SolarWinds® Academy, these trainings will introduce users to the Orion Platform and its features, management, and navigation. These courses are suitable for users looking to discover new tips, tricks, and ways to adapt their Orion products to better suit their monitoring needs:
Deploying the Orion Platform
Configuring Orion views, maps, and accounts
Configuring Orion alerts and reports

Reserve your seat.

Home > Success Center > DameWare Remote Support & Mini Remote Control > DameWare - Knowledgebase Articles > Troubleshooting Winsock 10060 Errors when using DameWare

Troubleshooting Winsock 10060 Errors when using DameWare

Table of contents

Updated July 3rd, 2017


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 established connection failed because connected host has failed to respond.

Please keep in mind that Winsock Errors are Microsoft Windows Sockets (TCP) errors, not DameWare error, 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 occuring.


  • DameWare Mini Remote Control All Versions


  • First make sure that all routers & firewalls between the Local & Remote Machines, and any firewall software on the remote machine itself (i.e. Windows Firewall for SP2 or Vista, etc..) are properly configured to allow the necessary traffic to pass through.  Our 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 timeout with a Winsock 10060 error.

    Please see the following knowledgebase article for more information:

    Using DameWare Development Products in Conjunction with XP Service Pack 2

    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, once 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... 

    Mini Remote Control Performance Settings

    Basically, try cranking up your compression to Maximum, increase your Scan Blocks, increase your Delay between Scan Block Updates, disable all Desktop Effects, use Force 4-bit color or 8-bit color, turn off encryption, etc.... In other words, anything you can do 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 these non-Mirror Driver performance settings mentioed above.
  • For high latency connection links, such as satellite connections, we also suggest 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 currently set to Socket Logon Timeout=90000 (in milliseconds), so you can try doubling that value to start out. 

    But we also suggest  you try tweaking some of the performance settings mentioned above (Compression, Scan Blocks, etc...) 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 & 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 (i.e. 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 it's 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, because you cannot install the Client Agent Service again if it's already installed on the remote machine.  So if for any reason the software is unable to communicate with the Service Control Manager on the remote machine (Access Denied, ports blocked, etc..), then the software will not be able to connect and has no choice but to fail with the appropriate Winsock Error.

    Therefore, if the remote machine is on 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 (i.e. Windows Firewall, etc...), then you must make sure all the necessary ports are open between the local & remote machines.  Otherwise the connection will fail.
  • Please also make sure there is a network route to the remote host via the TCP protocol using the selected port (default port 6129). Because when dealing with VPN connections (or multiple subnets as well) it's possible that the data packets are being received by the remote machine, however, 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, I have had more than one customer say that adding a static route fixed it. (which can be made persistent, 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. (see attached diagram)
  • Lastly, if nothing else above resolves your issues, you also need to 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, or even when defining specific access lists (ACLs) over VPN connections .  Because you could potentially have issues with any TCP Client / Server application anytime you're doing any type of blocking or filtering of outbound connections.

    Let me explain further:

    I've had many users tell me 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 because most Firewalls cache outbound connections in order to make comparisons to inbound connections. Then once an inbound connection is matched up to it's initial associated outbound connection (based upon the header information), the traffic is then allowed back through the Firewall, no matter what port it comes back on. Blocking on outbound connections is not typically done in Firewalls because then basically nothing would work. But from what I'm told, filtering between VLANs does not work this way (the same way that firewalls do), and it's more like 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 O/S actually uses a different port for the return connection when it accepts the socket. So simply blocking inbound / outbound traffic by port isn't really the correct thing to do when you're working with Client/Server type TCP applications, and if this were the case I can't see how anything would be working in this configuration. Not unless you have some apps that only allow a single TCP connection between the Client (local) and Server (remote).  But if you only allow a single connection (like RDP does) then it's really not a Server application anymore. 

    Basically, the MRC Connection logic is simply just a standard Winsock (Windows Sockets) design of: bind(), listen() & accept(), and on the Server (agent) when we accept() the inbound socket, the O/S will actually 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 also continue to listen for new connections on the same port. 

    So under this specific type of scenario I believe you will have to do something like open 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.



Last modified