Welcome to the ConnectWise Control Bug Report Portal
If you do not have an account, click "Sign in/ Sign up" to get started.
- Search for an existing bug report before adding your own. This helps us prevent duplicate entries and improve bug tracking.
- If you find a matching bug report, give it a thumbs up and throw in a comment with more details about the problem.
- If you can't find a request for an item you need, create your own bug report. Provide as many details as you can, especially:
- Software version of the server, host client, and guest client
- Operating systems affected
- Any error messages
- No spam, advertising, or self-promotion.
- No offensive posts, links, or images.
- Only one request per post.
- Administrators have the ability to moderate the forums, including editing, deleting, and moving posts. Posts may be deleted for any reason, with or without notification.
Thank you for sharing your thoughts with us!
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
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?
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.
When connecting to a session I get a popup that there is an update.
When trying to install the update I get this.
Customer support service by UserEcho