High CPU usage after Update tor Version 2026.1.12.0

Hello,
Thank you for reporting this.
At the moment, we do not have any known issues reported regarding increased CPU usage with version 2026.1.12.0. If possible, could you provide a bit more information so we can investigate further?
For example:

• The exact CPU usage observed for the RDM process
• Whether it happens constantly or only during specific actions
• If the issue persists after restarting Remote Desktop Manager
• The number of sessions or entries open when the CPU usage increases

Additionally, if you are able to capture a process dump or logs, that could help us analyze what is consuming the CPU.
Looking forward to your feedback.
Best regards

We see same issue!

35-40% of CPU utilization in RDM without doing anything in the application. This is on a shared jumphost running Windows server 2022.

Hello,

Thank you for your follow-up and for confirming that you are experiencing the same behavior.

At this time, we are still unable to reproduce the issue on our end. We are continuing our investigation based on the information previously requested.

Additionally, if you are able to provide application logs, this would greatly help us identify what may be causing the increased CPU usage.
We appreciate your collaboration and look forward to your feedback.

Best regards,

Hello

We had a somewhat similar issue recently that only affected older versions of Windows, but it will be worth checking if the same fix applies in your situation.

In Settings > Performance > Avalonia, uncheck the following options

• Enable WinUI composition mode
• Enable direct composition mode

So the settings should look like this:


Save the changes and restart RDM. Does it help?

If not, further uncheck "Enable AngleEgl rendering mode". So now the settings look like this:


Save the changes and restart RDM. Does it help?

If not, in terms of concrete next steps: you can re-enable all those settings and once more save changes and relaunch RDM. Then the following steps might help us to identify the problem:

• Download procdump from Microsoft / SysInternals
• Extract the download to a location on disk
• From an administrative command prompt, `cd` to the extracted procdump directory
• Run RDM (if it's not running already) and let it idle. We want it to be already running so we're capturing the idle state, not the startup cost.
• Back in the command prompt run `procdump64.exe RemoteDesktopManager.exe -c 10 -s 5 -n 10`. You may need to accept the license agreement which pops up.

This will instruct procdump to generate a minidump from RDM every time processor utilization exceeds 10% for 5 seconds, exiting after capture 10 minidumps. The command prompt will give some feedback as it generates the mini dumps. Based on your post I believe this should be an appropriate configuration.

procdump will write the dump files to the current directory and they'll be named like "RemoteDesktopManager.exe_{date}_{time}.dmp".

Once you've gathered these files please let us know and the support team can provide you an avenue to upload them to us. Do not post them here on the public forum. I encourage you to read the security disclaimer around dump files.

Please let me know if you have any questions

Kind regards,

Hi

I worked with Windows 365 all day. Remote Desktop Manager was always open in the background with a session. I had no problems all day.
After I closed (sleep) the Windows 365 session and reopened it, the problem with high CPU usage occurred.
The CPU usage of Remote Desktop Manager constantly fluctuates between 40 and 70%.
As a side effect, Windows 365 keeps losing its network connection and closing the session.
When Remote Desktop Manager is closed, the Windows 365 client recovers.


I adjusted the settings according to your suggestion, but the error occurred again.
I my case, I can reproduce the failure now.

Kind regards,
Oliver

Hello

The next step is to generate diagnostic information as in the second part of my post. Please let me know if you have some questions.

Kind regards,

Hi,

We’re experiencing the same issues with version 2026.1.12 running on a Windows Server 2019 Remote Desktop Session Host.

Based on our observations, the problem appears to have started with version 2026.1.10. The graph from our monitoring system clearly shows a noticeable change in CPU usage following the installation of version 2026.1.10 on the morning of March 9.

Task Manager also confirms that the increased CPU usage is caused by RDM.

Is there anything we can help to get futher with this issue - we have same issue.

We tried to change settings in the "Performance" selection, but for now still issues.

Hello

The next step is to generate diagnostic information as in the second part of my post. Please let me know if you have some questions.

Kind regards,

Hello

The next step is to generate diagnostic information as in the second part of my post. Please let me know if you have some questions.

Kind regards,

@Richard Markiewicz

Hi Richard

I've created the dump as you requested.
How can I send you this data?

Regards,
Oliver

Hello,

I will send you a link via private message with instructions on how to safely send the minidump.

Best regards,

Any updates?

Hello everyone,

Thank you for your patience.

We have received multiple dump files from Oliver and are currently analyzing them to identify the root cause of the increased CPU usage. At this stage, we can confirm that the issue appears reproducible in certain environments, particularly after resuming sessions (e.g., Windows 365 or RDS scenarios), but we are still validating the exact trigger.

Our team is actively investigating the data, and we will provide an update as soon as we have more concrete findings or a potential fix/workaround.

In the meantime, if others are experiencing the same behavior and are able to provide additional dumps or logs, it would help us confirm patterns across different environments.

Thank you again for your collaboration.

Best regards,

Hello

Thanks everyone in this thread for your patience. I've analyzed the data that @oliveroberholzer sent and found a smoking gun for the cause of this. I'll implement a fix ASAP and get that in the next release, and update you once that's available (it should not be too long).

In the meantime I'm afraid I don't have any workaround. I can tell you that this appears to be because we are triggering a bug in the Yubico SDK for a feature that optimistically tries to detect if you have an attached Yubikey. It would be really helpful if we can find any commonality between the users in this thread because I don't know exactly what the cause of the bug is, and I cannot reproduce it, I only have a way to work around it. Things like: do you have a smartcard attached on your client device? Do you redirect smartcards to the host running RDM? Things like that.

In the meantime, please don't hesitate with further questions or comments

Kind regards

Hello

Thanks everyone in this thread for your patience. I've analyzed the data that @oliveroberholzer sent and found a smoking gun for the cause of this. I'll implement a fix ASAP and get that in the next release, and update you once that's available (it should not be too long).

In the meantime I'm afraid I don't have any workaround. I can tell you that this appears to be because we are triggering a bug in the Yubico SDK for a feature that optimistically tries to detect if you have an attached Yubikey. It would be really helpful if we can find any commonality between the users in this thread because I don't know exactly what the cause of the bug is, and I cannot reproduce it, I only have a way to work around it. Things like: do you have a smartcard attached on your client device? Do you redirect smartcards to the host running RDM? Things like that.

In the meantime, please don't hesitate with further questions or comments

Kind regards

@Richard Markiewicz

Hi Richard
we do not have any smart cards or YubiKeys connected on our side.
Please let me know if you need any additional information from us.
Kind regards,
Oliver

Hello,

Thank you for your patience regarding the high CPU usage issue.

A fix has been implemented in a newer version of Remote Desktop Manager. Could you please update to version 2026.1.16 and let us know if the issue still occurs after the upgrade?

If the problem persists, feel free to share any additional observations.

Best regards,

Hi Carl,

We're running current 2026.1.16 on a RDS Jumphost and I currently have +40% in CPU without any tasks in RDM.

Hello @enoch

Pending feedback from other users, perhaps you are experiencing a different issue or the fix we made for .16 was not complete in some way.

If you can follow the troubleshooting steps I gave earlier I'll be able to look at the data straight away. I reproduce the instructions here:

• Download procdump from Microsoft / SysInternals
• Extract the download to a location on disk
• From an administrative command prompt, `cd` to the extracted procdump directory
• Run RDM (if it's not running already) and let it idle. We want it to be already running so we're capturing the idle state, not the startup cost.
• Back in the command prompt run `procdump64.exe RemoteDesktopManager.exe -c 10 -s 5 -n 10`. You may need to accept the license agreement which pops up.

This will instruct procdump to generate a minidump from RDM every time processor utilization exceeds 10% for 5 seconds, exiting after capture 10 minidumps. The command prompt will give some feedback as it generates the mini dumps. Based on your post I believe this should be an appropriate configuration.

procdump will write the dump files to the current directory and they'll be named like "RemoteDesktopManager.exe_{date}_{time}.dmp".

Once you've gathered these files please let us know and the support team can provide you an avenue to upload them to us. Do not post them here on the public forum. I encourage you to read the security disclaimer around dump files.

Thanks and kind regards,

Hi
I've tested the new version 2026.1.16 on our W365 Client.
RDM works without any issues. Also the W365 Client. There is no Network Connection errors anymore.

From my side, thanks.
Oliver