brettpound

hi David and Richard,

thanks for stepping in - and stepping up. Your level of detail and explanation does reassure that this wasn't just a "simple oversight" of a really poorly performing update, but quite a swiss-cheese set of circumstances that caused this.

As one of the early people flagging this, I guess I could have fielded this differently as well - perhaps by not clouding the new issue with the previous by adding to this thread may have prompted a slightly different initial investigations on your side and perhaps faster identification of the real underpinning cause, but that wouldn't have alleviated the impact because of the time of year and personnel.

Again, great to see you both actively engaged here and throughout, and the open and frank discussion.

We got the chance to do the dot 12 update last night and things look MUCH better this morning as well. Thanks

Please do let us know your "how to avoid doing again" plan. The pain was certainly not as severe this time but due to the time until the remediation became available, my management team are interested to understand how we might be impacted in the future...

That isn't set on me or our users... and unless the default has changed it hasn't changed for us.

We are predominantly an RDS support shop so it would be unusual to not see our techs with several RD sessions open at once. And certainly that RD focus hasn't changed for us from 2026.1x to immediately after the 2026.2 update applied, when we first noticed the performance difference.

Immediately post-impact and attempting to resolve with 2026.2.8 update, I rebooted the VM so there was only me connected to it, and only me running RDM, and even then I saw the laggy response to app movements and the VM CPU appeared high.

Our VM will reboot on Monday morning (GMT+10) before start of business so we will get some baseline info from then, I'm one of the early starters so will try to get stats. I'll also deploy 2026.2.11 as I hadn't got a chance to do .9 this week.

I know that in my dumps I didn't get a lot of "spare" CPU to my process so it took some time to meet the high CPU for 10-sec duration, as we don't have a high capacity VM running RDM for us - I suspect that might make it less relevant to investigate. Monday morning should give me a better view of the perf with minimal users and no previous day legacy, and I'll capture all the info again.

I've sent thru some dumps and an etl trace to my sharepoint link

I've updated to 2026.2.8.0 and still seeing very high CPU usage on a single user (me) using Remotedesktopmanager.exe... thats me rebooting the host, then RDPing to the server, and then starting RDM. I've not had my session disconnect at all, so the behaviour isn't directly related to the disconnect/reconnect process.

context: this is the CPU usage on the host that has our RDMan instance on it. We are a small team, less than 15 techs and regularly see a dozen connections to this host. Yesterday was a Monday but a non-working day for the majority, we had two people connect to the host to do some remote admin, at around 11am... the update must have been done by a colleague as I didn't initiate it but I had to complete the database update to finalise it. After that, the CPU usage went up, and ever since this morning when our business day started we have seen CPU starvation for all our users, and the graph shows we're constantly hitting that 100%, and I'm seeing at least 15% CPU for my own session, and the bulk of the CPU is from remotedesktopmanager.exe on all the other user sessions.

We saw this issue on the same version as was originally posted. We also saw the improvement when the public release happened.

However, this morning, after an update to 2026.2.7.0, we seem to have come back to a very CPU intensive problem. Anyone else see it coming back ?

I do note that there's a 2026.2.8.0 update now available, and there's an improvement noted "Improved agent connections to survive RDP reconnections", is there any chance this is the fix to this issue?