RemoteDesktopManager.exe won't run - 2025.1.25.0 (64-bit)

Same problem here. The update process runs normal, but if the updater wants to start the "normal" RemoteDesktopManager.exe, the windows error occurs. We had this issue with also with 2025.1.24.0, so maybe there is a problem with the newest Windows 11 updates... (we have now OS Build 26100.3476)

Hello

That sounds strange. On the face of it, this looks like an installer issue but I'm not quite sure what the problem can be. It's interesting that this was noticed on 2025.1.24 as well, as we did have changes to the installer on 2025.1.25.

Some background: there are three executables deployed: RemoteDesktopManager.exe, RemoteDesktopManager_x64.exe and RemoteDesktopManager_ARM64.exe. These are simple .NET wrappers that just execute RemoteDesktopManager.dll; but the specific architecture lets us run as a platform-native binary on the appropriate architecture. However: RemoteDesktopManager.exe is RemoteDesktopManager_x64.exe; they're the same file as that is 99% of our install base. Only when installing on an ARM system do we swap the ARM64 binary in for the x64 one.

A couple of thoughts:

• To be really clear, when you navigate to C:\program files\... and manually launch RemoteDesktopManager.exe, it doesn't run? What's the error message when double-clicking the file?

• An installer log might reveal some more information. You can open a command prompt, navigate to the directory containing the MSI and run `msiexec /i {remotedesktopmanager.msi} /l*v {path-to-create-log file`. For example. `msiexec /i RemoteDesktopManager.2025.1.25.0.msi /l*v rdm-install.log`. Then run through the installer as normal, and find the log file that was created. You can send this direct to me by PM or to service@devolutions.net mentioning this forum thread in the message.

• @kevz - The other issue with SCCM might be an PatchMyPC problem, or it might be RDM. I'm not familiar with PatchMyPC but perhaps it's possible to invoke the command in a similar way, possibly providing a temp path for the log file, and getting that to us as well. Let me know.

Please, let me know any questions or problems, and I apologize for the inconvenience.

Kind regards,

Hello again

After working through this issue in a support ticket, we see a "Debugger" value present in the registry key "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\RemoteDesktopManager.exe". In that case, the value looked like this:

"C:\WINDOWS\IMECache\07897c94-786c-41fa-9b7c-2c8ac91193a9_1\patchmypc-preventstart.exe" /StopProcess /ApplicationName="remotedesktopmanager.exe"

This seems to be value that PatchMyPc adds to prevent the application being launched during an upgrade. It can be safely deleted to unblock this issue.

The question becomes: why did the upgrade fail in PatchMyPc, in a way that prevented it from removing this value itself?

I don't know much about PatchMyPc, but if you can share how you have it configured for RDM I maybe able to spot something. An install log from PatchMyPc would undoubtedly be helpful, but again - I don't know if it's possible to obtain that (i.e. can you modify the msiexec arguments to generate a log file in an accessible location?).

Please, let me know if something isn't clear or you have further questions

Kind regards,

Hello

If we can help investigate from our side, please let me know. This could be a PatchMyPC problem, or it could be some interaction with the RDM installer; without knowing the PatchMyPC environment it's hard to say. If you can provide any more details on how the installer is invoked, I'm happy to take a look.

Thanks and kind regards

PatchMyPC invokes the installation package using their ScriptRunner engine, more info on that here: https://patchmypc.com/what-is-patch-my-pc-scriptrunner

When the package is synchronized from the catalog and enabled in the Publisher (which integrated into SCCM), the SCCM installation parameters basically just looks like "PatchMyPC-ScriptRunner.exe /InstallPackage".

In the package content directory is the script runner, the installation MSI, a package/content definition XML file, and some other bits and pieces (like DLLs and scripts they use). The installer is pulled from https://cdn.devolutions.net/download/Setup.RemoteDesktopManager.2025.1.25.0.msi. The Package.xml file parses flags that are specific to their scriptrunner as well as handling a bunch of their own parameters -- the only MSI-specific flag this setup passes through is the REBOOT=ReallySuppress flag. The other parameters all look like this:

The <CommandLine> attribute of the Package.xml file (invoked by scriptrunner) looks like:

/MainFile=Setup.RemoteDesktopManager.2025.1.25.0.msi
/MainArg=REBOOT=ReallySuppress
/RecommendedPreScriptPath=PatchMyPC-dotNetCheck.ps1
/RecommendedPreScriptArgument=-Version 9
/RecommendedPreScriptAbortOnFail
/BlockingProcessPolicy=Notify
/UserNotificationTimeout=300
/PreventConflictingProcessRestart
/NotificationPolicy=AutoClose
/FocusAssistPolicy=ShowNotification
/ApplicationName=Remote Desktop Manager (MSI-x64)
/ApplicationID=0d092413-39d9-4420-8a67-9ea0c418909a
/KillProcessList=RDMAgent.exe|RemoteDesktopManager.exe|RemoteDesktopManager64.exe
/registry=Update|SOFTWARE\Policies\Devolutions\RemoteDesktopManager|DisableAutoUpdate|True|DWORD|1
/SdpTitle=Remote Desktop Manager 2025.1.25.0 (MSI-x64)
/UpdateID=7dcb9862-5965-402b-b142-e18fc6442494

And, the PatchMyPC-dotNetCheck.ps1 script looks like:

param (
    [Parameter(Mandatory=$true)]
    [string]$Version
)

# Check to See if .NET Windows Desktop Runtime specified version is installed and if not return Exit Code 1

if ([IntPtr]::Size -eq 4) {
    $Key = 'HKLM:\Software\dotnet\Setup\InstalledVersions\x64\sharedfx\Microsoft.WindowsDesktop.App'
}
else {
    $Key = 'HKLM:\Software\Wow6432Node\dotnet\Setup\InstalledVersions\x64\sharedfx\Microsoft.WindowsDesktop.App'
}

if (!(Test-Path $Key)) {
    Exit 1
}

if ((Get-Item $Key).GetValueNames() -like "$Version.*") {
    Exit 0
}
else {
    Exit 1
}

By the time the scriptrunner invokes the installer, it basically looks as you expect with `msiexec /i C:\Windows\ccmcache\abc123\Setup.RemoteDesktopManager.2025.1.25.0.msi REBOOT=ReallySuppress /qn`. However with this version specifically, SCCM ends up erroring out due to the job timing out. You mention there were installer changes in 2025.1.25 -- this could be related, because if something is preventing the scriptrunner from finishing the processing of the installer (because of a new flag/missing option/something else that is waiting for input), then this would cause the scriptrunner to wait until the semaphore timeout period is reached and SCCM declares the installation as unsuccessful.

Depending on what was changed, this might require PatchMyPC to add in something to the scriptrunner to handle this properly, or maybe we just need to pass-through an additional MSI flag. Could you provide some more details on what changed in 2025.1.25's installer?