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 10054 errors

Troubleshooting Winsock 10054 errors

Updated June 26th, 2016


Connection reset by peer.

An existing connection was forcibly closed by the remote host.  This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, or the remote host uses a hard close (see setsockopt for more information on the SO_LINGER option on the remote socket).  This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress.  Operations that were in progress fail with WSAENETRESET.  Subsequent operations fail with WSAECONNRESET.



  • DameWare Mini Remote Control All versions
  • Windows Environment



Winsock Errors are Microsoft Windows Sockets errors, not DameWare errors, and even though a Winsock 10054 error can be caused by many different things, "network" errors are the typical cause of this "Forcible Disconnect" or "Lost Connection" error.  Googling this specific error will result in thousands of hits (, and even more can be obtained by searching this way (

The term "network" errors is not limited to hardware, but also includes everything between point A to point B - bad or faulty hardware, bad or faulty drivers, even application errors on the remote machine.  This error can be duplicated by unplugging the Ethernet cable, or if either end of the TCP socket has gone down for any reason. 



  1. What Operating System and service pack level is installed on the local and remote machines?
  2. Are tests being performed such as "penetration testing," "vulnerability" or "threat assessment" or any other type of scanning/testing on these machines or on the network?
  3. Is there a specific interval of time in which the connection remains before being disconnected?  Is this a consistent amount of time, or random?
  4. Is the remote machine being left at the Logon Desktop or Lock Screen, or on a users desktop (logged in)?
  5. Is there a screen saver defined on the remote machine?
  6. Is there any type of Security or AV software on these machines or on the network (i.e. Cisco Security Agent, Symantec AV, Symantec Endpoint Protection (SEM), CA eTrust, Pest Patrol, etc.)?  This software could be hooking into (or scanning) all activity on the network or on these machines, which could possibly cause an additional load.  This additional load could also be causing timeouts to occur or this software could be killing the TCP socket in totality.
  7. Are there any type of activity timeouts enabled within the DMRC software or DMRC Client Agent Service?  In the DMRC Application, select the Host Entry, click on Settings (blue wrench), then select the Inactivity Options Tab and make sure "Enable Disconnect on Inactivity" is not enabled.  For the DMRC Client Agent Service on the remote machine, right-click on the DMRC SysTray icon and select Settings.  Select the General Tab and make sure "Absolute Timeout" is set to 0 (Zero), which equals no timeout.
  8. Is the Mirror Driver being used for this connection (i.e. is the "Use MRC Mirror Driver" checkbox enabled on the Remote Connect dialog before clicking on Connect)?  If so, try the following steps because earlier versions of the software does not automatically install the DameWare Mirror Driver on the remote machine.  It is automatically installed in version 9.x and up of the software:
    1. Select the Host Entry, click on the Settings button (blue wrench), then select the Mirror Driver Tab and enable the "Force 8-bit display" option.  This will reduce the color-depth over the DMRC connection to 8-bit color, which will drastically reduce the amount of data being sent over the wire.  Due to the tremendous amount of data the Mirror Driver is capable of sending, this actually may be too efficient for this specific type of connection and it is possible some hardware (or driver) component is not capable of handling this additional load.
    2. If #1 does not help, try toggling the "Use MRC Mirror Driver" off before clicking on the Connect button to see if the connection remains without any type of Winsock 10054 error.
  9. -  Is a VPN connection being used?  DameWare software should work fine over any type of VPN implementation (hardware or software).  It may be helpful to check the MTU settings because the MTU settings for the VPN connection may be larger than what is defined on the local or remote network, which could be causing a lot of dropped packets.  Also, it is recommended that the VPN configuration with regard to the fragmentation of packets be reviewed.

    The following is one DameWare user's comments concerning MTU settings:

    "I did a little hunting around on the web and found a post regarding the MTU settings on routers. I eventually reduced it to 500 (originally at 1500) and Dameware (and RDP) connect fine now."

    Therefore, using the following test may prove to be helpful:

    Ping <ip-address> -f  -l  #bytes

    Start #bytes about 1500, then decrease incrementally.  Check the response times, and note if the Operating System displays a message stating that it needs to fragment the packets.  The more fragmentation present, the higher the possibility for packet loss (depending on the VPN and network configuration).

    1300 bytes
    1000 bytes
    500 bytes

    RV042 - Problem using VNC and Remote Desktop (© 2015 Linksys International Inc., available at, obtained on July 7th, 2017)
    Painful networking situation - Connection Reset By Peer (© 2017 A Gossamer Threads company., available at, obtained on July 7th, 2017.)                                                   

    -  When reconnecting to the same machine, is a message displayed stating that the DMRC Client Agent Service is installed but not running on the remote machine, and asked to start it?   If so, this is a good indication that something on the remote machine is causing the DMRC Client Agent Service to crash on the remote machine, which would certainly cause a Winsock 10054 error to occur (similar to unplugging the Ethernet cable from the wall). 

    If an old version of the software is being used, try upgrading to the newest (current) version and updating the DMRC Client Agent Service on the remote machine.  An issue was discovered in version, where reconnecting to a remote machine with the "Enable Remote Clipboard" feature enabled could possibly terminate the connection with a Winsock 10054 error.  This was resolved in the subsequent release of the software.

    If these suggestions and action steps do not resolve the issue, please check for any DWMRCS entries in the Application Event Log on the remote machine export it and submit a ticket to SolarWinds Support for examination.  Please also check for any "Service Control Manager" entries for the DMRC Client Agent Service (i.e. DWRCS.EXE, or DWRCST.EXE) which could explain this behavior.





Last modified