Troubleshooting Winsock 10060 Errors
The information in this article applies to:
- DameWare Mini Remote Control
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.
here are some things you can try:
- 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
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 6.x of the software, then after you install
v6.x 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, &
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
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
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
||Microsoft Windows 95/98/Me
Microsoft Windows NT4/2000/XP/2003/Vista/2008/Windows 7
||Monday, June 15, 2015
||winsock connect error, system error, 10060, connection timed out
||Some common causes of Winsock 10060 Errors within DameWare Mini Remote Control
8.0 out of 10.
313 people have rated this article.