0
Waiting for information

Updating Client to 6.4.15002.6500 is NOLONGER Silent!

FAB-ITRescue 3 years ago updated 3 years ago 10

Updating from previous 6.3 stable version to 6.4 appears to flag up on client's desktop and requires user intervention.


This should be silent and totally automated and invisible to the end-user.

ConnectWise Control Version:
1
Server Affected:
Host Client Affected:
Guest Client Affected:
Waiting for information

Good morning,


I was unable to reproduce this behavior in our test environment by upgrading the 6.3.13446 client to version 6.4.15002 on a Windows 10 guest via the Host page.


To facilitate troubleshooting, can you update this thread with additional information about the environment in which you observed the behavior, including:


1) Guest operating system on which the client upgrade does not occur silently

2) Any relevant details about the logged-in user that is prompted for interaction when the client reinstall is submitted from the host page

3) Does this behavior occur across the board, or only on specific machines?


Regards,

Ben

OK - bear with me because it's complicated.  I'd updated the Server and issued a blanket reinstall to all remote access sessions.  I was hosting a remote access session to a client (Named Kilo) running Win7 Pro when a dialogue popped up asking for permission to update the ScreenConnect Client.  The dialogue 'appeared' to be from my host machine (Named Mike) which also runs a client RA session. Mike runs Win7 Ult.  I accepted the prompt to allow the update to proceed, and carried on with the RAS on Kilo.  During that session, the ScreenConnect Service reported as stopped and I was able to resume the session just by closing the Error dialogue, but the error dialogue would reappear every 30sec or so.  In hindsight, I believe the original request to update was from the Kilo session, ie. the session was being updated whilst in use!  Indeed, after around 10mins RA, there were multiple instances of the ScreenConnect Client in the notifications section of the taskbar on Kilo; which promptly disappeared when hovered over.  In the intervening time I was again asked for permission to update the ScreenConnect Client once or twice; and again this could have been a dialogue from Kilo or Mike as there was nothing in the dialogue to identify.  Logged in user for both Mike & Kilo was the same domain user with administrative privileges.


The RAS for Kilo is still registered on the Server as v6.3.13446 although the host is no longer connected. Mike has been updated to 6.4.15002.


Further to test; another Win7 Pro PC (previously powered down during all of the above) with a 6.3.13446 client installed behaved as expected when booted - initially registering on the server and then updating Silently to 6.4.15002.


Perhaps the problem is confined to sessions in host?  If so, could/should this be caught and the reinstall instruction delayed until the session is off host?


Further - Just booted Kilo PC which was running 6.3.13446 RA client.  Started a RA session and logged in on the client as a domain user (with admin rights).  The host screen froze at the Welcome prompt. When the Client PC was checked locally, the Screen Connect RA Client was reported as Stopped even though the session was in progress as can be seen in the following screen shot:


I closed the Host Session, but the client still appeared to have a host connected.  I pressed the close button locally on the client.  There were 2 RA icons in the notification section of the taskbar one of which disappeared when hovered over.  The Stopped Error dialogue keeps reappearing and the Client is still reporting as 6.3.13446.  Attempting to reconnect a host just produced a blank screen at the host session.

The Client PC was rebooted and logged in locally and updated silently to 6.4.15002.


Therefore attempts to update RA clients whilst sessions are in host can lead to an unresponsive RA session which requires local intervention to clear and a locally logged in user to complete the upgrade of the RA Client.


Respectively suggest this is a bug.

This problem might just be confined to this PC, but I've manually uninstalled ScreenConnect and then ReInstalled with the ESET Endpoint Security set for learning mode.  The client is now 6.4.15002 but the service keeps stopping with the following error when the Host connects:


Problem signature:
  Problem Event Name: CLR20r3
  Problem Signature 01: ScreenConnect.WindowsClient.exe
  Problem Signature 02: 6.4.15002.6500
  Problem Signature 03: 59e7b624
  Problem Signature 04: mscorlib
  Problem Signature 05: 4.7.2116.0
  Problem Signature 06: 59c475d2
  Problem Signature 07: 531
  Problem Signature 08: d
  Problem Signature 09: System.ArgumentNullException
  OS Version: 6.1.7601.2.1.0.256.48
  Locale ID: 2057
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt


Good morning,


I've so far been unable to replicate this behavior in our development environment, and based on the comments thus far, it seems to be an environmental issue limited to a single machine.


Is there any additional information in the event log related to the problem signature referenced above? In particular, is there any sort of stack trace that might indicate where the argument null exception is thrown (this relates to the line "Problem Signature 09: System.ArgumentNullException", above).


Cheers,

Ben

Ben

Hope this helps:

Application: ScreenConnect.WindowsClient.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ArgumentNullException

Server stack trace: 
   at System.String.FormatHelper(IFormatProvider provider, String format, ParamsArray args)
   at ScreenConnect.UnderControlBanner.UpdateUserInterface()
   at ScreenConnect.WindowsClientExtensions.<>c.<UpdateVisibleControlsUserInterfaces>b__55_2(IUpdateUserInterface u)
   at ScreenConnect.Linq.LinqExtensions.<>c__DisplayClass14_0`1.<ForEach>b__0(TSource element, Int32 index)
   at ScreenConnect.Linq.LinqExtensions.ForEach[TSource](IEnumerable`1 source, Proc`2 proc)
   at ScreenConnect.Linq.LinqExtensions.ForEach[TSource](IEnumerable`1 source, Proc`1 proc)
   at ScreenConnect.WindowsClientExtensions.UpdateVisibleControlsUserInterfaces(Control rootControl, Boolean includeSelf)
   at ScreenConnect.Client.UpdateUserInterface()
   at ScreenConnect.Client.<>c__DisplayClass193_6.<ScreenConnect.IMessageProcessor<System.Object>.ProcessMessage>b__30()
   at ScreenConnect.WindowsClientExtensions.<>c__DisplayClass99_0.<Send>b__0(Object <p0>)
   at System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control, System.Delegate, System.Object[], Boolean)
   at System.Windows.Forms.Control.Invoke(System.Delegate, System.Object[])
   at System.Windows.Forms.WindowsFormsSynchronizationContext.Send(System.Threading.SendOrPostCallback, System.Object)
   at ScreenConnect.WindowsClientExtensions.Send(System.Threading.SynchronizationContext, ScreenConnect.Proc)
   at ScreenConnect.Client.ScreenConnect.IMessageProcessor<System.Object>.ProcessMessage(System.Object)
   at ScreenConnect.MessageThreadQueue`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].Run()
   at ScreenConnect.ThreadRunner.RunThread(System.Object)
   at ScreenConnect.WindowsToolkit+<>c__DisplayClass6_0`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].<StartThread>b__0(System.Object)
   at System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Threading.ThreadHelper.ThreadStart(System.Object)


Thanks for providing additional information.


Based on the provided stack, in particular the line ScreenConnect.UnderControlBanner.UpdateUserInterface(), I'm wondering if you experience the same behavior if you temporarily disable the under control banner on the affected machine by updating your app.config and reinstalling the client on that machine.


The easiest way to temporarily update the app.config would be to use the Edit App.Config Settings extension to disable the following flag setting:


AccessShowUnderControlBanner

Remember to reinstall the client on the affected machine after changing the app.config.


Regards,

Ben


Ben


I can confirm that the "Stop & Restart" error as described has ceased with the "AssessShowUnderControlBanner" Disabled. Furthermore the behaviour reappears with the setting Re-Enabled.

Thank you for confirming that.


I'm still unable to replicate the behavior in our environment, which suggests that there's some environmental factor at play on that one Win 7 guest which causes the crash.


Have you by any chance modified the value for the client resource entitled "UnderControlBannerTextFormat" (the current value for this resource may be found on the admin Appearance tab)?


Regards,

Ben

The value is unchanged @ "Your computer is being controlled by {0}"