Seeing issues on 3 different On Premise Control installations where frequently Timeline view for Access Hosts will crash the browser, happens on all major browser versions.   Seeing this on two instances of the most recent version of Control (currently 19.1) as well as on older instance on 6.7.

Issue can really be compounded on say a device that might be in a boot loop and is just rebooting over and over.    I think all the entries in the Timeline database make it so that the browser isn't capable of loading all the data to render the timeline.   

Browser will prompt for Stop or Wait, but if you Stop and don't quickly move off the Timeline it will just crash the browser again.   Since once your in timeline view it stays there until you go to another view, if your browsing through timelines on devices to get a visual of what might be happening at a site, then suddenly you hit a device that just freezes the browser entirely, which also seems to affect overall performance of the server and web interface for other users.

Our users occasionally report that the Windows key is stuck on the host computer after using it in a remote control session. Windows will act like the key is still being held even outside a remote control session. Pressing the Windows key a few times solves the 'stuck' key.

Problem can occur after using the Windows key in a remote session to launch Explorer (Win + E) for example.

This problem started to occur after upgrading to 19.0.23665.7058

Host computers are running Windows 10 1809 October 2018 Update x64

The process to upgrade the client software by selecting "Reinstall" from the web interface doesn't always work.  I've seen it happen quite often where if you select an Access session and hit "Reinstall", it doesn't seem to do anything, and then it might work later, perhaps after a reboot.

I was testing this, and tried to "reinstall" an old agent running 6.8.20124.6845 (the server is on 19.1.24050.7079), and instead of doing nothing, it knocked the Guest out of the session.  I think the software on the Guest is being killed in preparation for the upgrade, but then the upgrade doesn't happen.  If I reboot, the Guest joins the session again and the version is still 6.8.20124.6845.

If I manually install the new agent on the Guest, then it successfully upgrades it.

When launching ConnectWise Automate Web or Control web consoles, "Control" button doesn't launch the installed application and instead attempts to force re-download of the app.

McAfee has started quarantining the standard ScreenConnect DLLs from a permanent install, knocking out most of my client PCs. This has been reported to McAfee some time ago, and I am chasing, but they do not seem to be "allowing" these.

This is happening with 6.9.21870.6964

Does this still happen with 19.0.23234.7027 or later?

ScreenConnect.ClientService.dll

ScreenConnect.Core.dll

ScrennConnect.Windows.dll

ScreenConnect.Client.dll

Most of my customers/client PCs use retail McAfee so they are completely UNABLE to 'exclude' these as apparently "McAfee kows best" for retail customers.  At this rate I will not be able to renew as this will become unworkable.  Others must be affected by this?

I have a 25 machines in an access group. After accessing the website, and selecting the access group, I cannot scroll down without using the arrow keys. 

I am on a Mac running 10.11.6 (15G22010 - El Capitan) using Chrome 72.0.3626.64. This happens also on my Mac running 10.14 (Mojave), same version of Chrome. 

If I use Safari, I can scroll normally. 

The Mac version of the remote support client requires High Perf GPU, forcing macbooks to utilize the discrete graphics card. This is causing a reduced battery life on several of our machines, and customer machines.

Using build 73.0.3683.103 with no issue.

Upgraded to build 74.0.3729.108 and I have no scroll bar nor can I scroll with the mouse wheel.

When connecting to a session I get a popup that there is an update.

When trying to install the update I get this.

http://take.ms/MYTZI