+7
Started

Exception 0x80004005 error in event logs on recent release.

Joshua Fredrickson 1 year ago updated by Billy V 2 weeks ago 32

I am seeing the following error on multiple computers with the latest version of Screenconnect (19.2.24707.7131).  After reviewing the Windows event logs it appears I started getting this error on June 11th on my computer.

I can still connect to these clients, and there is no error popping up on the screen for these clients. I noticed this when troubleshooting another issue in the event viewer.

System.Net.Sockets.SocketException (0x80004005): A blocking operation was interrupted by a call to WSACancelBlockingCall

at ScreenConnect.SocketNetworkConnection.Receive(Byte[] buffer)

at ScreenConnect.NetworkConnection.OnReadStreamNeedsBufferCycled(Object sender, EventArgs e)

at ScreenConnect.Extensions.RaiseEvent[T](Object sender, EventHandler`1 eventHandler, T eventArgs)

at ScreenConnect.BlockBufferReadStream.Read(Byte[] buffer, Int32 offset, Int32 count)

at ScreenConnect.Extensions.ReadByteDefault(Stream stream)

ConnectWise Control Version:
20.5
Server Affected:
Host Client Affected:
Guest Client Affected:

I'm also getting 0x80004005 on a win7 box. Connectwise Automate installs, and screenconnect components are present in program files (x86). Event viewer when attempting to start the screenconnect service via services.msc:

System.Net.Sockets.SocketException (0x80004005): A blocking operation was interrupted by a call to WSACancelBlockingCall
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)

On affected machines, I am UNABLE to connect with screenconnect.

I am also getting the same error in event viewer as above when trying to install the client on a new machine, i have also tried to manually start the service and it fails. 



System.Net.Sockets.SocketException (0x80004005): A blocking operation was interrupted by a call to WSACancelBlockingCall at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags) at ScreenConnect.SocketNetworkConnection.Receive(Byte[] buffer) at ScreenConnect.NetworkConnection.OnReadStreamNeedsBufferCycled(Object sender, EventArgs e) at ScreenConnect.Extensions.RaiseEvent[T](Object sender, EventHandler`1 eventHandler, T eventArgs) at ScreenConnect.BufferStream.OnNeedsBufferCycled() at ScreenConnect.BlockBufferReadStream.Read(Byte[] buffer, Int32 offset, Int32 count) at ScreenConnect.Extensions.ReadByteDefault(Stream stream) at ScreenConnect.BlockBufferReadStream.ReadByte() at System.IO.BinaryReader.ReadByte() at ScreenConnect.MessageSerializer.Deserialize(BinaryReader reader, Type requireBaseClass) at ScreenConnect.EndPointManager.ReceiveMessage(BinaryReader reader, Type requiredBaseMessageType) at ScreenConnect.SocketEndPointManager.RunIncomingThread(ThreadSharedState threadSharedState)

I'm having the same problem and cannot connect;

System.Net.Sockets.SocketException (0x80004005): A blocking operation was interrupted by a call to WSACancelBlockingCall
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at ScreenConnect.SocketNetworkConnection.Receive(Byte[] buffer)
at ScreenConnect.NetworkConnection.OnReadStreamNeedsBufferCycled(Object sender, EventArgs e)
at ScreenConnect.Extensions.RaiseEvent[T](Object sender, EventHandler`1 eventHandler, T eventArgs)
at ScreenConnect.BufferStream.OnNeedsBufferCycled()
at ScreenConnect.BlockBufferReadStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at ScreenConnect.Extensions.ReadByteDefault(Stream stream)
at ScreenConnect.BlockBufferReadStream.ReadByte()
at System.IO.BinaryReader.ReadByte()
at ScreenConnect.MessageSerializer.Deserialize(BinaryReader reader, Type requireBaseClass)
at ScreenConnect.EndPointManager.ReceiveMessage(BinaryReader reader, Type requiredBaseMessageType)
at ScreenConnect.SocketEndPointManager.RunIncomingThread(ThreadSharedState threadSharedState)

We are getting a similar error randomly at one client:

System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at ScreenConnect.SocketNetworkConnection.Receive(Byte[] buffer)
at ScreenConnect.NetworkConnection.OnReadStreamNeedsBufferCycled(Object sender, EventArgs e)
at ScreenConnect.Extensions.RaiseEvent[T](Object sender, EventHandler`1 eventHandler, T eventArgs)
at ScreenConnect.BufferStream.OnNeedsBufferCycled()
at ScreenConnect.BlockBufferReadStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at ScreenConnect.Extensions.ReadByteDefault(Stream stream)
at ScreenConnect.BlockBufferReadStream.ReadByte()
at System.IO.BinaryReader.ReadByte()
at ScreenConnect.MessageSerializer.Deserialize(BinaryReader reader, Type requireBaseClass)
at ScreenConnect.EndPointManager.ReceiveMessage(BinaryReader reader, Type requiredBaseMessageType)
at ScreenConnect.SocketEndPointManager.RunIncomingThread(ThreadSharedState threadSharedState)

Do you guys use Palo Alto for your firewall?  We think we might of identified that as the problem on our end but are still researching.

No we don't, let us know what you have found :)

Ok it ended up being with the Captive Portal settings on our Palo Alto.

Not sure if the SonicWall has the same options but start there.  ScreenConnect support told me that after the 19 upgrade of their client some firewalls were like Palo were having issue so I suspect it could affect other types of firewalls.

I'm having the same issue, Sophos XG. I mean if its never been an issue before, wouldn't that be a Control issue, that maybe they should fix? =)

After making the changes on our Palo Alto the exceptions went away in the event viewer.


From what I understand they changed the way the traffic is being routed in the new version of Screen Connect which is why some firewalls are requiring some configuration changes.

It would be nice to have the configuration requirements on the Screen Connect site for each of these firewalls.  I know our administrator who called Palo Alto they had no idea what he was talking about at first.

Interesting, but shouldn't that affect all clients? I only have 1 of 40 at the site with that problem.

I am getting the same thing on random Win 10 workstations and we use Sophos.  I just pushed it out to 150 of the exact same computers with the same GPOs applied and maybe 10 of them came up with this error.

We are on 19.1.24050.7079

For those seeing the same issue, I did find that if I uninstall the client completely and reinstall it that they seem to work fine.  I just added it to my script that I push out with and those 10 computers all came online.

I am having the same issue on one new Server 2019 server.  it is a Hyper-V VM on a server 2019 host.  when  I try to connect, screen freezes on locked screen and I get the error above on my workstation and on the server I am trying to connect to.  I have 4 servers at this client, 2 physical, 2 VM's but only have the issue with one VM.  I can connect when the Hyper-V host is connected to the VM [has vm open in Hyper-V], but as soon as the host closes the vm, I cannot connect anymore.

Same problem - Server 2016, hits every 5 minutes or so.  Using the automate / screen connect client.  Only on one machine, of course it is the one we do the most work on.

i'm having the same issues:

Log Name:      Application
Source: ScreenConnect Client
Date: 4/3/2020 8:32:47 AM
Event ID: 0
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: xxxxxxxx
Description:
System.Net.Sockets.SocketException (0x80004005): 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 xx.xx.xx.xx:8041
at ScreenConnect.ClientNetworkExtensions.ConnectTcpSocket(Uri endPointUri)
at ScreenConnect.WindowsClientToolkit.ConnectNetworkConnection(Uri endPointUri, Uri httpProxyUri)
at ScreenConnect.SocketEndPointManager.Run()
Event Xml: <event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <system> <provider name="ScreenConnect Client"> <eventid qualifiers="0">0</eventid> <level>2</level> <task>0</task> <keywords>0x80000000000000</keywords> <timecreated systemtime="2020-04-03T13:32:47.662142300Z"> <eventrecordid>4844</eventrecordid> <channel>Application</channel> <computer>xxxxxx</computer> <security> </security></timecreated></provider></system> <eventdata> <data>System.Net.Sockets.SocketException (0x80004005): 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 xx.xx.xx.xx:8041 at ScreenConnect.ClientNetworkExtensions.ConnectTcpSocket(Uri endPointUri) at ScreenConnect.WindowsClientToolkit.ConnectNetworkConnection(Uri endPointUri, Uri httpProxyUri) at ScreenConnect.SocketEndPointManager.Run()</data> </eventdata> </event>

Getting the errors on Servers and PCs (all versions)

Log Name: Application
Source: ScreenConnect Client
Date: 4/6/2020 6:22:28 AM
Event ID: 0
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: IT-WS-01.ERB.local
Description:
System.Net.Sockets.SocketException (0x80004005): 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
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at ScreenConnect.SocketNetworkConnection.Receive(Byte[] buffer)
at ScreenConnect.NetworkConnection.OnReadStreamNeedsBufferCycled(Object sender, EventArgs e)
at ScreenConnect.Extensions.RaiseEvent[T](Object sender, EventHandler`1 eventHandler, T eventArgs)
at ScreenConnect.BufferStream.OnNeedsBufferCycled()
at ScreenConnect.BlockBufferReadStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at ScreenConnect.Extensions.ReadByteDefault(Stream stream)
at ScreenConnect.BlockBufferReadStream.ReadByte()
at System.IO.BinaryReader.ReadByte()
at ScreenConnect.MessageSerializer.Deserialize(BinaryReader reader, Type requireBaseClass)
at ScreenConnect.EndPointManager.ReceiveMessage(BinaryReader reader, Type requiredBaseMessageType)
at ScreenConnect.SocketEndPointManager.RunIncomingThread(ThreadSharedState threadSharedState)
Event Xml:

One location is having the same issue.  Only thing that we changed is we installed a fortigate 50E firewall.  Now we have the issue with this one site.  However, we have FortiGates all over.  Not sure if that's the issue or not. 

Same issue here with 20.3 and 20.4 debug with Sophos UTM. Also, the system tray icon is not visible on some machines.


IMPORTANT NOTE: We are using the built-in router functionality of CWC so we have an extra Windows service running on the server although I don't know if this has anything to do with this issue.

Has any Sophos UTM user figured out what settings need to be edited? I had to uninstall latest client and install v19.6 client as a temp fix. Using a cleaner to completely uninstall and reinstall 20.3 or 20.4 did not make any difference.

I have a UTM also and I have this issue. I am working on trying to resolve it.

Having the same problem on a Win 10 computer behind a FortiGate 60E.  My other Win 10 computer on the same network is fine - no ScreenConnect issues.  No recent changes to anything.  

Started

A fix for this will be in 20.4+ soon.

We are still seeing this on 20.4.28399.7439

System.Net.Sockets.SocketException (0x80004005): 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 X.X.X.X:8041
at ScreenConnect.ClientNetworkExtensions.ConnectTcpSocket(Uri endPointUri)
at ScreenConnect.WindowsClientToolkit.ConnectNetworkConnection(Uri endPointUri, Uri httpProxyUri)
at ScreenConnect.SocketEndPointManager.Run()

I am seeing this on many systems we use Watchguard firewalls . I have not been affected as far as connecting to systems is concerned but I have needed to reinstall the client on a few systems. At the moment It is mainly a distraction when checking eventlogs.

A SocketException is thrown by the Socket and Dns classes when an error occurs with the network. Most of the time these are connectivity issues due to different IP protocols (IPV4/IPV6) between the two server/computers trying to communicate or extra authentication rules setup on one of the computers for in/out connectivity. Ways to troubleshoot this SocketException are, check you have proper internet connection is there on your machine or not, and you are able to ping the remote server or not. Possible causes for the error:

  • You are using the wrong IP address.
  • You are using the wrong port.
  • Firewall blocking the connection.


The fix in 20.4 just filtered out Interrupted or ConnectionAborted error types (which are expected when closing the client). Is this insufficient? I don't think we want to filter everything, as some of these are probably useful for troubleshooting purposes. (I'm trying to figure out if I can call this "Fixed" or not.)

I have the same issue/same error message, but it keep disconnecting access each time error occurs. anyone else having this issue? it reconnects on its own, sometimes immediately, sometimes 20 seconds later etc. Anyone find a reliable fix? have exhausted all suggestions in this feed.

Same issue here as well running 20.7


Additionally, the site uses a .NET SQL warehouse management system, and for the past month or so users have been complaining of random disconnects (accessed from physical PC)


Server logs are clean, however when PC logs are checked the only errors found at the time of their disconnect is this connectwise error.


Nothing in the sites SonicWall profile has changed, and we've disabled Avast Firewall on a couple of the PC's to see if it makes a difference.


If not, next will be removing Connectwise from a couple of the PC's


If that resolves the issue, we may have to find a different solution

Any update on this issue? We are seeing this error a lot. 


System.Net.Sockets.SocketException (0x80004005): 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


We are running version 20.10.


We are also having this issue for all are clients behind NGFWs.  Even when all NGFW features are disable bled.   I have been trouble shooting it with our firewall vendor for months and have made multiple changes from that end,  just when we think it is resolved it occurs again.  

    After months of trying to resolve this from the networking side, because that is what CW support has been blaming the entire time, I about had a stroke when I found this thread where others are having this exact issue from behind a variety of Security Appliances.  And to see that the issues started with a specific SC patch was just the icing on the cake.     

    Has anyone gotten anywhere on this?

I have been trouble shooting this from the firewall standpoint. Assuming Connectwise changed something in the way the traffic is flowing causing NGFWs to take action on the traffic in the session.     Since Connect wise support has not been helpful in any capacity I have been trying things from the FW standpoint. 

What I notice is the following,          At some point, with a frequency anywhere between minutes to hours,)    The firewall removes the active session from the session table. I am not getting any log info on why.  At that point, inbound and outbound traffic matching the original session gets blocked on both sides of the firewall.   Eventually ScreenConnect restarts the session...

    Logging at the packet captures I am not seeing anything in the TCP traffic that should be triggering a tare down of the sessions.        Has anyone else done packet captures on their Firewalls and have seen the same thing?

Good morning Folks,

We have had this issue with SC for about 3 maybe 4 weeks now. It was only one location with this issue. I called Sonic Wall support (as we pay them a buttload of money every year) and it turned out that the SSL Control Function under Firewall Settings was on. The tech had me turn it off as his bomgar session was also disconnecting/connecting. This stabilized the connection and allowed my techs and myself to now work normally.

The two articles the tech sent me were:

http://help.sonicwall.com/help/sw/eng/9530/26/2/3/content/PANEL_scSslCtrlCustomLists.htm

http://help.sonicwall.com/help/sw/eng/7634/7/2/0/content/Policies_FirewallSettings_SSLControl_Snwls.htm