getting the windows error asking to change the color scheme to windows 7 basic since upgrading to 6.1.
This issue has been fixed as of the 6.4.15002 release.
I was unable to reproduce this in our test environment on a Win 7 guest using the default Windows 7 Aero Theme with Visual Effects performance options set to "Adjust for best appearance". I connected to the Win 7 guest using the 6.1.12292 client without generating any Windows warnings.
Would you mind providing some additional information about the behavior:
1) Are you able to successfully join the session despite the Windows warning?
2) Does the Windows message appear on all Windows 7 endpoints, or only some?
3) What theme is enabled for the Windows 7 guests on which the error appears?
4) What is the WindowsClient CPU utilization like after connecting into the Windows 7 guest that generates the warning?
Since upgrading to the latest version of ScreenConnect this error has appeared. We have never encountered it before and all of our machines ran the high quality setting by default.
1) Yes we can join the session fine. Roughly 2 - 5 minutes after joining does the message appear
2) We have encountered this error on all of our machines (all Win 7)
3) We run the default Windows theme (company background image) with the Aero effect enabled
4) ScreenConnect client CPU usage is at 09 / 58,264 K memory usage.
Following on from mhighsmiths comments, I'm not sure if the issue we have is due to duplicate clients? I have attached a screenshot of our processes list and as you can see we have two clients running. When the new version released I flagged all our machines to reinstall the client.
Would you mind reattaching the screenshot; I'm unable to view it.
I would like to add too, that we have an outstanding issue with the 6.1.12292 guest client in that it consumes more system resources than previous versions of the client during an active session, which can be especially taxing on machines with older, single-core CPUs. This is largely due to changes we made in 6.1 to improve session responsiveness. Development is currently investigating the issue.
As a temporary workaround, you may be able to disable the color scheme warning message on the affected machines.
Apologies... may have forgotten to attach it. Here is the image I took yesterday:
...and here is an image I have just taken on the same machine today:
Looks like there is a memory leak issue?
I think that's what we're thinking too for the time being as the message is rather annoying. Glad to hear it's on the dev teams list anyway as our machines are fairly beefy things so we wouldn't really expect system resources to be a factor. Is there any rough timeline for a fix?
Thank you for providing the screenshots. Based on the provided information, I don't see evidence of a memory leak issue -- the 125 MB windows client memory footprint depicted in the second image falls within the expected range, especially when a host is connected to the machine.
I'm unable to provide an ETA for the CPU-related resource consumption fix, but I can confirm that development is aware of the issue and actively investigating a solution. A fix will likely be included in the 6.2 release.
1 - yes we are able to join. the message comes up later on in the session
2 - it shows up on alot of the windows 7 32 bit connections. the message does not instantly come up. takes some time. not sure.
3. Just basic windows theme. all the systems have the same them
4. waiting on the CPU information. Because at this time i cannot reproduce the error.
I think i found the issue. some of the systems when they updated have multiple installs of SC now. The invalid ones are pointing at the following relay?
the version of the invalids are 5.3.9117.5654 and to two separate servers that are not ours
Ben - you requested that we "s a temporary workaround, you may be able to disable the color scheme warning message on the affected machines."
Unfortunately this did not resolve the message from coming back up. I have tried multiple registry settings to no avail.
For Windows 7, do the steps outlined in the following linked comment prevent the message from reappearing?
Disable “Do you want to change the color scheme to improve performance?” warning
the problem with manually doing the steps is that we have over 2000 devices with the issue. i would need a registry fix for this. manually changing each location is unrealistic.
net stop UxSms
sc config UxSms start= disabled
This should stop the Aero theme, It doesn't seem ideal, but it should also suppress the warnings.
We're having the same problem with the, "Do you want to change the color scheme to improve performance?", message since upgrading from v5.6 to 6.1. I'm at the beginning stages of troubleshooting this for more info. I'll add here as the info becomes available.
supposedly the newest version of 6.2 is going to resolve this issue possibly. from Output Stream - Windows Client process can peg CPU during active session on certain single-core guest machines
I have verified that they have a fix for this issue in 6.2. I connected to a machine with 6.1 and the message came up twice in 6 minutes. connected with 6.2 and the message is not coming up after 10 minutes. if "prompt for storage" was working i probably would put 6.2 in production.
I tested a remote guest machine and watched the resources when the message appeared. I didn't see the CPU surge, but I did see a spike in network I/O when the message popped up. The CPU, RAM, and VRAM all had plenty of resources left when this happened. I do wonder if that Windows message is just generic, and maybe it can be triggered if there are spikes in any of the hardware. Would the keep alive pings cause spikes in the network I/O?
interestingly 6.2 is now showing the same symptons as 6.1 with the message popping up. took some time for the issue to start showing again.
We are seeing this issue regularly in SC 6.2.
Yeah, we're still experiencing the same issue in 6.2. I haven't really noticed a difference between 6.1 and 6.2 in terms of regularity.
it appears to take a little longer to pop up in 6.2. but yes on certain PCs it is coming up.
I hope 6.3 resolves the issue. We're on good PC's here so I'm surprised this is a problem.
We've also been experiencing this issue on all of our Windows 7 PCs in versions 6.1 and 6.2. Note: We use the cloud version.
I too am running into this problem, running 6.2 cloud and it happens every time i connect to a machine
Cloud version here too.
Same issue here with on-premise installation and 6.2.12963.6312 version.
Please up-vote this topic if you are currently affected by this issue. Thank you.
issue is still happening in 6.3.13256.6348
Yep... having this issue with 6.2... pops up on almost all remote Windows 7 sessions... not sure about other OS versions.
Thank you everyone who has participated so far in this thread. We were able to reliably trigger the "change color scheme" warning on a Windows 7 machine in our development environment; I have registered an issue and it is currently under investigation.
As mentioned previously, the warning message only appears to be triggered on Windows 7 guest machines with an Aero theme enabled. I have, as yet, been unable to trigger the color scheme warning by connecting to a Windows 7 guest with Aero disabled.
Seeing this on all our Windows 7 clients with Aero theme enabled using cloud 6.2.12963.6312.
Is there a fix for this other than removing Aero theme from hundreds of clients?
I have the same Problem after the Update from 5.2 to 6.2. Only win7 are affected, no win10 Clients. So any updates here ? Topic started 5 Months ago.
Can we get an update on an ETA for a fix please? The place where I work utilizes over 7,700 sessions, and this issue definitely affects us.
Please up-vote this topic if you are affected by this issue.
Same problem here. On Prem 6.2 to Windows 7 desktops with Aero on. I was looking for a group policy to block the message, but it would be great if it wasn't triggered in the first place.
How many more people need to up vote or comment on this thread before it gets the attention that it deserves? This has been going on for nearly 6 months now and we're all still in the exact same spot now as we were when it started with no end in sight.
Is this a 'critical' bug? Probably not, however because it affects nearly 80% of my client machines it's 'critical' for us. I'm sure everyone else who took the time to post a message here feels the same way.
+1 to Tim's commentThis has been going on for a long time, and ScreenConnect/Control has already admitted they can replicate the issue. We shouldn't have to up vote this anymore, but we need transparency on the fix. It's both embarrassing and awkward that the same product we use to remotely help someone is also the same product that's triggering the performance warnings. The warnings pop up on the screen and disturb our workflow.
+1 to both you and Tim.
It's bad enough when ScreenConnect asks me to provide feedback. I don't need Windows complaining about low resources when it's running on an i5 with 8GB DDR4.
I am hopeful that now the issue can be reproduced a fix is on the way sooner rather than later.
Good morning all,
I have added new comments from this thread to the existing issue in our internal bug tracker. While I'm unable to provide an ETA for a fix at this time, development is aware of the issue and currently investigating a solution.
BUMP BUMP BUMP
Super annoying, and may be causing some installs to fail
This is seriously impeding customer interaction and users have concerns about the window popping up that there is something wrong with their computer.
How can this issue be escalated to the next severity level? Who do we need to speak with?
Encountered same issue but not on every Win7 box. Can't figure out why it only affects some boxes but not others. Very annoying when you have users complain that you messed up their computer (Aero disabled). Now I have to remember to manually re-enable Aero after some sessions.
Is it possible to get a temporary fix for the issue until a permanent solution is found?
Someone higher up this thread mentioned to run
"net stop UxSms
sc config UxSms start= disabled"
If that stops Aero, then can it be configured to run on connect without the tech having to manually send a command?
I am affected by this bug as well.
We are affected as well
It has now been over a month since we last heard anything from ConnectWise, and a HALF YEAR since the problem was originally reported. I work at a hospital which has display boards that show patient critical status information. Due to this bug, this information is sometimes getting blocked when people are remoting on. This is extremely poor communication and customer service. Since this issue doesn't seem to be currently taken very serious, I'd like to know who we as your customers can talk to in management at ConnectWise to see a solution to this issue.
Sad to see what was once a great solution now going down the drain. Typical nonsense when bigger companies acquire smaller ones. Time to go back to RAdmin!
I'm curious if anyone has been contacted by CONTROL to address their concern when they asked for this to be escalated. It comes across as though CONTROL isn't hearing our cries or isn't addressing them properly. Skimming through the replies, it looks like the last official employee commented about a month ago. I think I already said this, but there should be more transparency on this issue since it impacts a large group of customers and is also annoying to deal with. The thing I liked about the ScreenConnect forum was that you at least had regular replies from employees, even if the issue isn't resolved.
I wanted to provide a quick update on the status of this issue.
Our development team is continuing to investigate the best way to mitigate the frequency of the appearance of the color scheme dialog on Windows 7 guest machines with an Aero theme enabled during active sessions.
The color scheme dialog is appearing more frequently with the latest releases of ConnectWise Control because we made some major changes to how the client encodes captured screen data -- the encoding process is now more CPU-intensive for the guest, which, in turn, reduces the magnitude of screen data transmitted across the wire and improves the responsiveness of the connection. Because the encoding process is more CPU intensive (especially when the screen is changing rapidly), some Windows 7 machines with Aero enabled will intermittently prompt the user to change the color scheme to improve performance.
I have added everyone's comments in this thread to our internal bug tracker so that both the development and product management teams are aware of your concerns.
Thank you for your patience while we continue to investigate the best method of mitigating the impact of this issue.
So....3 weeks later, and not a single update regarding a fix. This is very poor showing.
Is there any light at the end of the tunnel? Any kind of updates?
We have made some changes to 6.4 to correct this problem by reducing the overall CPU usage but it has not yet yielded significant improvement in our internal tests. We are still working to correct this problem and while I cannot completely guarantee that it will be included in the stable 6.4, it is still currently our primary goal to do so.
I'm happy to report that we identified what was triggering the color scheme warnings on Windows 7 guest machines.
We've implemented a fix for this issue, and it will be included in the forthcoming 6.4 release.
Does 6.4.15002.6500 fix this issue?
we are no longer seeing the issue on that version
Customer support service by UserEcho