2025.2.13.1 update ARM64 to x64?

Hello Andreas,

Thank you for contacting Devolutions Support.

I will attempt to reproduce the issue and consult with our development team. I’ll keep you informed of any updates on our end.

In the meantime, could you please provide some details about your system? Specifically, which version of Windows are you using?

Best regards,

Hello,

I just attempted to reproduce the issue on my end, but I wasn’t able to do so.

This might be a bit unusual to ask, but would it be possible for you to downgrade and try to reproduce the issue again? I just want to confirm that the issue wasn’t a one-time occurrence.

You can find previous versions here:
https://devolutions.net/remote-desktop-manager/home/previousversions/

Best regards,

Hi,

now that you say.. I am using an Insider Preview version. Maybe not the most relevant setting.

Windows 11 Enterprise Insider Preview (26200.5622)

I will try the downgrade and see if I can reproduce it.

BR,
Andreas

Hello again,

not sure how to properly reproduce it. I am actually not sure what version I had before the upgrade to 2025.2.13.1. Can I see this in some log?
So I started with V2024.3.31.0, as this is the next older version that I can download from the website.

I could not reproduce it either.

What I tried:
Uninstalled --> installed V2024.3.31.0 --> auto-updated to latest version --> still ARM64
Uninstalled --> installed V2024.3.31.0 --> manually installed the downloaded exe file for 2025.2.13.1 (as with this was the version that was before suddenly x64 for me) --> still ARM64.

Maybe it was really just a glitch in the Matrix or so.

BR,
Andreas

Hi Andreas

It does sound like a glitch indeed and probably not worth pursuing but obviously if the same thing happens again, please post back.

I'll just clarify some things here because the landscape has got a little more confusing with 2025.2.

From the downloads available on our website, the .exe/.msi/.zip are architecture agnostic .NET binaries. This is the same as what we've always provided. In the downloaded or installed files, you have three copies of RemoteDesktopManger.exe:

• RemoteDesktopManager.exe
• RemoteDesktopManager_x64.exe
• RemoteDesktopManager_ARM64.exe

The plain "RemoteDesktopManager.exe" is the same file as the "RemoteDesktopManager_x64.exe". This is because the vast majority of customers are running on Intel, and so this is what they want. This will also run on an ARM system but as you note, it would be under emulation so performance is compromised.

At install time, if the system is ARM, we swap the x64 "RemoteDesktopManager.exe" for the ARM-native "RemoteDesktopManager_ARM64.exe" so you have a native ARM executable on an ARM system.

The .exe is just a native "launcher" that does the equivalent of "dotnet run RemoteDesktopManager.dll", but the architecture of that launcher determines the architecture of the application.

Now, with 2025.2, we also have architecture-specific downloads (e.g. .msi x64, .7z x64). There will only have a single "RemoteDesktopManager" built for the target platform; but there is also an extra optimization step performed on a subset of the assemblies to precompile them for the target architecture. This boosts performance since in a lot of cases, code no longer needs to be just-in-time compiled for the host machine; but the files will only run on the specified architecture (confusingly - the x64 binaries will of course run on ARM, but again under emulation).

You can see which "flavour" of the application you are running by checking the "About" window, which will have a suffix after the version number: "JIT" is the traditional architecture agnostic build, "PreJIT" is an architecture specific optimized build. You can also see in the bottom-right corner of the status bar of the main application window the effective architecture of the process (e.g. "64-bit" or "ARM 64-bit"). That should normally match the host architecture of the machine but that might vary if you are running under emulation, as you've seen.

Normally the auto-update should be smart enough to update a JIT build to a JIT build, and vice versa; but maybe something went wrong there, or perhaps you were running a JIT build, updated to a JIT build and the step in the installer which swaps the native binaries around had an issue.

If it does reoccur, it would be helpful to know which "flavour" of the application you were running.

I hope this brings some clarity to whoever reads that. Please let me know if something isn't clear.

Thanks and kind regards,

Hello Richard,

interesting. Thank you for those insides and details.
I was not aware that the those x64/arm64 versions are "faster" PreJIT versions. Makes sense. But harder to maintain (and explain. hehe) I guess. :)

Just that emulated x64 version was really slow which made me aware that something suddenly changed after that update.
I changed now to arm64 msi and I´ll keep my eyes open if this happens again.

Thank you again and kind regards,
Andreas