iustinn

Hello,

Thank you for being so patient!

I'm pleased to inform you that a new version of RDM Mac (2026.3.0.5) has been released, featuring the fix for your issue.

Latest Version: Download RDM

Please let us know if this works or if you encounter any issues.

Best regards,

@Maxim Robert

Amazing! I am on it now, hoping for the best.

Thanks to all @devolution team and especially to @Richard Markiewicz for figuring our fast what I was talking about!

Hi Richard,

I captured another data point from the same PID. In approximately 43 hours, RDM increased from 12 GB to 15 GB, while IOSurface increased from 10 GB across 1,327 regions to 14 GB across 1,479 regions. During that interval, macOS recorded 67 sleep entries, 66 DarkWakes and one full wake. This does not confirm how many RDP reconnects occurred, but it makes the sleep/reconnect explanation plausible.

Thanks!

Unfortunately, Dynamic Resolution only appeared stable in the short term. The same RDM process and RDP session from the previous T0/T1 captures has now been running for 20 days. During the last several days, RDM mostly remained untouched in the Dock, with the same RDP session connected.

Memory has now reached 12 GB, of which footprint reports 10 GB as IOSurface. I’ve attached the new T2 footprint and top captures. The PID is still 88589, matching the earlier T0 and T1 captures.

Sorry, again, it is ok for me, I can close it / open again to clear the ram, but it is just that I have spent some time and you too, so just want to help fixing this nasty leak...

Hi, same RDM process and RDP session using Metal + Dynamic Resolution, over 24h 28m, with normal use and several window resizes. Memory increased from 964 MB to 1,130 MB, suggesting Dynamic Resolution avoids the large growth seen with Smart Reconnect.

Attached the captures.

With 48GB of ram I was close to call it a day, but 11+GB usage and I was like " what the f, do I need to sell my car and get the 128 GB macbook pro ?" :D

Thank you for tracking this down!

And wow, to be honest, I had no idea about dynamic resolution - was this here say 5y ago ? Just switched to it and it much faster/better.

I am using it for a long time, but not exactly a "pro" RDM user, probably 90% of its options I never use..

Thanks again and will report if this stopped the leak.

Thanks, that explanation fits the behavior very well. I had no particular reason for using Smart Reconnect—it was simply an old setting that remained in my RDP configuration.

I’ll switch to Dynamic Resolution while keeping Remote Desktop size set to Default, restart RDM and test it.

The fact that this configuration followed me between machines may also explain why I consistently experienced the issue while it remained uncommon for other users.

Thanks for tracking it down!

Hello,

I completed the requested captures and attached them.

Both captures are from the same RDM process and continuously connected RDP session. T0 was taken 52 seconds after launch; T1 was taken 22 hours 38 minutes later.

The footprint increased from 910 MB to 3,864 MB. IOSurface increased from 113 MB to 2,575 MB.

The session used Metal, with unified memory and OpenH264 disabled.

Some observation: I use tabbed sessions, resizing the left pane triggers the 'reconnect' and memory usage goes up 200-400mb, then it drops some but not all.

I just had time to try and help, I don't use it say professionally, mostly home/lab use, RDP into proxmox lab, home laptops, ssh here and there and OTP when I don't have the mobile.

It has been like this for a long time, just that I can live with it and did not have time to complain + it is hard to complain about something you use at home for free :)

But, now that we are here, I can run some tests if you want, my AI palls are also happy to help and eat my tokens, and since I used this software for so many years, maybe it helps someone else.

It is hard to think it is only me - if that would be the case - I would not even bother tbh. But all this time, multiple macs, multiple versions of RDM and same issue ?

I don't do exotic stuff on these machines, ... don't know, can't think of anything that would do this to RDM.

Maybe some observation, the more ram I have , the bigger the usage - like this is the first time I see RDM at 11+ GB, but I also have 48 gigs for the first time...

If you want me to provide something that might help, just ask.

Hello,

I connect to various Windows 10 and 11 machines, not Windows Server. The behavior isn’t tied to a particular remote computer.

There is no CCTV, video, animated dashboard or other unusual workload involved, this was just this time, I do various things. It can happen with a plain desktop and ordinary administrative use. The session moves between foreground, behind other applications and occasionally minimized.

I don’t use thumbnail view or session recording. Resource forwarding is limited to the clipboard.

One potentially relevant setting is Persistent bitmap caching, which is enabled. I can test with that disabled if useful.

I’ve experienced the same behavior over the years on a 2019 Intel MacBook Pro and two M4 Pro MacBook Pros.

Thanks.

I completed the idle-control test with OpenH264 disabled.

RDM was cold-started and left idle for 20 hours 20 minutes without opening any RDP, SSH, or other sessions.

• Initial footprint: 571.6 MB

• Final footprint: 662.5 MB

• Initial IOSurface: 39.1 MB across 729 regions

• Final IOSurface: 39.0 MB across 722 regions

• Peak footprint remained unchanged at 904.3 MB

Therefore, idle RDM does not exhibit the multi-gigabyte IOSurface growth. The growth is triggered by an active RDP session, occurs with both Metal and Core Graphics, with unified memory and OpenH264 both disabled.

Hello again

Thanks for the information. It is certainly confusing, since without the unified memory option we're not directly allocating IOSurfaces ourselves (neither in RDM or within the RDP library). Additionally, using the Core Graphics renderer should bypass Metal entirely.

Do you have the OpenH264 decoder enabled? It's in the application settings, Types > Remote Desktop (RDP) > Codec.

is it possible to try and rule out RDP here? What happens if you cold start RDM at the end of your day; without running a session or anything else; if you come back to it the next morning is memory usage normal?

Thanks and kind regards,

@Richard Markiewicz

OpenH264 decoding is disabled.

I will perform the proposed idle-control test:

1. Fully quit RDM to release the existing IOSurface allocation.

2. Cold-start RDM with no RDP, SSH, or other sessions opened.

3. Record the initial memory footprint.

4. Leave RDM idle overnight.

5. Record the footprint and allocation categories again the following morning.

Observations:

(engine changed to core graphics)

- cold start and opened 1x RDP session = 1GB

- 1.5 GB after 1 hour

- next morning, it is at 3.18 GB

- now (15pm) already at 5+GB

So changing the rendering engine did not help.

Current capture after 18h10m:

• Total RDM footprint: 5,048 MB

• IOSurface: 3,915 MB across 940 regions

• IOAccelerator (graphics): 232 MB

• Ordinary malloc memory: comparatively small

• Unified memory: disabled

"The accumulating memory remains overwhelmingly IOSurface memory, suggesting the retention occurs in renderer-independent RDP display/surface handling, or in a path shared by both rendering engines—not specifically in the Metal renderer"

And I think it matters what is on the remote box, because normally I does not grow to 4 gb/day, but now I configured some remote cctv cameras in that windows box and it showed live video, so somehow makes sense to me that if the graphics are 'kept', it grows faster if viewing a movie vs. text in a notepad, but it's just speculation...

Hi, thanks for reply.

1. yes, same RDP session opened for 6 consecutive days, without reconnects.

2. unified memory disabled (was never enabled before)

3. I only use RDP (90%) and occasionally some SSH into some Proxmox box.

(I do also use some OTP credentials when I don't have my mobile near me, but during those 6 days I don't think so.)

I will now change the rendering engine, restart, wait and report back.

It is clear to me that the ram grows by the day. Restarted yesterday, only one RDP session and I am at 4+ GB already..

And after some AI assisted investigation we have the following:

While the affected RDP session was open, vmmap reported a 12.0 GB RDM footprint, including 10.8 GB of IOSurface allocations across 1,293 regions.

I closed the RDP session but left RDM running. Immediately afterward and again several minutes later, the footprint remained 11.8–12.0 GB, with approximately 10 GB retained across 1,277 IOSurface regions.

Therefore, closing the RDP session released only 16 IOSurface regions and did not release the approximately 10 GB accumulated graphics-buffer footprint. The memory is released only when RDM terminates.

This appears to be retained IOSurface/Metal resources in the main RemoteDesktopManager process rather than a .NET managed-memory leak.

That is strong, developer-actionable evidence of an RDP/Metal resource leak.

Don't know if new topic is needed since 6mo has passed, an I have been away from tech, but there must be something wrong.

Now I have the same thing on a new macbook pro (m4pro), with RDM over 11GB of ram used over 6days, and only 1 constantly active RDP session.

Also, some captures of the RDP options used for this one Windows 11 remote session.

As always, thank you for your time, it is just frustrating this issue still persists after some years :(

Hi, just an update - now on 2025.3.9.2 - no change, leaving the app opened for 1-2 days and it still grows over 3GB :(

Since the last report, ram is now more expensive than gold :)

Hello,

Thank you for reaching out to us regarding this matter.

Could you please confirm the type of RDP in use? For example, is it FreeRDP?

In the meantime, could you also check if there is any device or system currently enabled or associated with this entry?

Best regards,

@Tommy Sanders

Hi, using it only in tabbed/embedded mode - If I was to using it detached, I have the Microsoft app for that so not sure who would use RDM to open sessions same as you do with the MS app :)

Hi,

New macbook pro m4 pro and having only one RDP connection opened, but for 3days, RDM is using 3.5GB of ram. Connection is opened to a LAN PC, and not even focused on the tab (using it for OTP codes mostly).

Closing the RDP session does not free up the ram.

(also, a bunch of about: processes that exits if application is closed)

Version: 2025.3.6.9

Thank you.

Hello

This subject is a little bit complicated and I've started some investigation but I don't have a quick fix. We are also hampered on our side by a lack of test machines for this environment.

In the first case, I need to check if on our side (in our code) we're doing something that prevents the application from using integrated graphics.

The next problem I see, is that any part of the application using Metal for rendering will automatically kick in the discrete graphics card unless it's explicitly opted out from. We've already addressed this in our code (the "favour low power GPU" option) but notably, we've started migrating our products to use AvaloniaUI for parts of the interface. I do believe Avalonia probably renders using Metal by default and it's likely this would also kick in the discrete GPU.

We've had a somewhat similar issue on Windows recently which we were able to address by exposing some additional options from the Avalonia compositor. I wonder if the same approach might help in this situation.

Do you recall if this is a recent or semi-recent regression? Did things behave better on your side, for example, in late 2024 releases or even in 2025.1?

In the meantime you could see if gswitch enables you to force the integrated graphics card.

Thanks and kind regards,

@Richard Markiewicz

Hi,

Yes, using gswitch with integrated works. Opening RDM keeps the discrete graphics off.

While the RDM is running, using gswitch to switch to default dynamic, immediately triggers the discrete card.

PS: just upgraded to 2025.2.9.0 = same results.

Hi

Thanks for the feedback and I'll wait to hear some more from you.

For the sandboxing - that's fine; the main purpose of the sandboxing mode is that it runs the RDP connection in a separate process. This is just to make RDM more resilient if the RDP process crashes, it won't bring down the whole application. Historically we had stability issues here - FreeRDP is a big, complicated chunk of C code and can be hard to integrate in a stable way. That being said, the integration has come on leaps and bounds in the last years and I generally have sandboxing mode turned off.

Anyway, the reason I asked was, if you are seeing a memory leak this tells us which part of the application the leak exists in. Since you're running sandboxed, any leak must be in RDM itself or the rendering engine, not the RDP side itself.

Thanks and kind regards,

@Richard Markiewicz

Hi, had some time and tested 2024.2.10.4 - no issues, discrete gfx is not triggered on open.

(disabling RDP sandboxing on latest version made no difference)

Hello

I understand your feeling. RDM is a big complicated tool, a kind of Swiss army knife. My understanding is that previous attempts to produce something like an "RDM-lite" have fallen pretty flat, where the consensus seems to be that most users want a large set of features. I'm not sure where that lies with the future strategy of the product. Quite simply it will always be much more resource heavy than "just" an RDP client, like Windows App. I do encourage you to look at the blog post I linked above ("Modernizing the codebase of RDM"), and I am encouraged that you seem willing to keep testing the waters with RDM Mac to see if it fits for you.

Back to the issue at hand - I and many of the developers don't use Intel Macs at this point, although we have a handful available for QA and testing. I will say that the percentage of RDM Mac users overall still on Intel is meaningful, but small, and decreasing constantly.

If you have the time, I'd ask if you can download 2024.2.10.4. No need to configure a data source or do anything really - does starting the bare application on your Intel Mac start the discrete GPU? It would help me test an assumption about AvaloniaUI.

I'm also interested that you seem to see a memory leak with RDP. Can you tell me if you are using the "sandboxed" mode for RDP? It's in the "Advanced" tab of the RDP session settings.

Thanks and kind regards,

@Richard Markiewicz

Just to be clear, I don't have any demands, I am just a regular user somewhere on the globe :)

Yes, I know Intel macs are dying, but hey, not everyone can buy the latest and greatest all the time. Less than 5y ago, this mac was top spec, and top price so ...

I will test 2024.2.10.4. and come back with the results (I am leaving soon in vacation so no promises).

And yes, I am using the "sandboxed" option - it says "recommended" so ...

Should I try without it ?

Hello

This subject is a little bit complicated and I've started some investigation but I don't have a quick fix. We are also hampered on our side by a lack of test machines for this environment.

In the first case, I need to check if on our side (in our code) we're doing something that prevents the application from using integrated graphics.

The next problem I see, is that any part of the application using Metal for rendering will automatically kick in the discrete graphics card unless it's explicitly opted out from. We've already addressed this in our code (the "favour low power GPU" option) but notably, we've started migrating our products to use AvaloniaUI for parts of the interface. I do believe Avalonia probably renders using Metal by default and it's likely this would also kick in the discrete GPU.

We've had a somewhat similar issue on Windows recently which we were able to address by exposing some additional options from the Avalonia compositor. I wonder if the same approach might help in this situation.

Do you recall if this is a recent or semi-recent regression? Did things behave better on your side, for example, in late 2024 releases or even in 2025.1?

In the meantime you could see if gswitch enables you to force the integrated graphics card.

Thanks and kind regards,

@Richard Markiewicz

I will be honest, I did not even expected an answer. This tool is still a little mystery to me. I first used it like 6y ago when I had to use both windows an mac and had a lot of RDP's that I needed to not make from scratch when changing platforms.

I really wanted to use it and even promote it in my organization, but some things just did not worked for me. I can't tell exactly what. It is a big tool, with lots of options (maybe to many?) but you know better your users base.

So every year or so I gave it a try. Database on Mac os had a bug and you could just duplicate it to bypass the password (fixed), then I saw you can just see any password, no way to hide it unless you have some paid version (or I think that is how it works). Then, I always recall it was using a lot of resources (GPU mostly but also ram) compared to the light official Microsoft Remote Desktop for Mac - so I used that.

That being said, I don't recall regressions since I probably skip 5 or more versions because I am not using it.

Now, I wanted to give it a try again and I also have a team that was interested but it is 38c outside, and those intel Macs (well, any intel high end) are a pain, you give up any software that produces heat :)

I can, however, try 1-2-3 versions for testing, if you tell me what to try/test or if it makes any sense.

Right now, I am on 2025.2.6.8 and Sequoia 15.5

With no external monitor or any other app running, I just open it and in about 5sec, I can see the AMD graphics card pop up and stars being used.

Oh, also, another issue - If you open a RDP session, and leave it, next day it will be using like 2+GB of ram. Closing the RDP session does not free the RAM. So ... it just feels very "heavy". If you use ALL the features it has (and has a lot) then maybe it makes sense, but for RDP only...

Hello

The option to "favour low power GPU" is specific to running sessions that use Metal for rendering (e.g. RDP, VNC). It doesn't do anything for the application just in an idle state.

Possibly there are some changes that can be made here, I do feel the pain with the later generation Intel machines that ran hot and noisy under load.

But, your screenshot doesn't help to show the issue; energy impact is zero and App Nap is enabled.

You said it uses a lot of resources, but can you show what? Is it CPU, memory?

Thanks and kind regards,

@Richard Markiewicz

Hi there,

The worst thing is that we open the app, use it just for let's say OTP codes, and after some time, the laptops are hot. Looking over, it triggers the discrete GPU and never let's go.

So there should be something it can be done to stop this behavior.

If we open a remote session (RDP) AND we have configured an option to have "maximum performance" then yes, for the duration of the RDP session, it can use the discrete GPU but when session is stopped, it should let go.

Not much to test, it is the same behavior on different macbooks with similar graphics, so not a specific macbook bug or something.

If you need something I can help with some testing.

Thank you.

Hi all,

2y old thread, but did not want to open a new one since problem is related.

16" Macbook pro with AMD Radeon Pro 5500M.

Just opening the program (no connections established) and it uses the graphics card. (Favor low power GPU is selected).

It is using a lot of resources just being opened, nothing running.

Can this be improved maybe ?

And sadly, we can't always upgrade the macbooks just because it would work better on the new one ...

Regards.

because it would work better on the new one ...

Regards.