I had the same problem.

Running "MPRDP.EXE" instead of "MPRDP64.EXE" did help and I am able to successfully connect when using "MPRDP.EXE" while "MPRDP64.EXE" is crashing.

What I did to avoid having to run this manually, is the following:

* Unloaded multiplicity

* Created a copy of MPRDP64.exe to keep it for backup-reasons

* Created a copy of MPRDP.EXE and renamed it to MPRDP64.EXE

Then I can use the system tray conveniently to to KVM based remote connections and it works. I suspected that this might lead to 64-bit process loading issues, but so far it didn't.

Windows build: Microsoft Windows [Version 10.0.19042.508] (20H2)

I can confirm removing the license did not do anything. So I went through the process of purging settings and the install of Multiplicity on all machines.

On installing again I made sure it was 3.5 on all machines and it all works no connection issues, no crashing. All machines connect as expected.

Yes all worked as expected. I did not try what the other user did above in moving the EXE around. Before I downgraded to 3.44 and then upgraded to 3.5 to fix. But purging and installing at 3.5 worked.

We have a test build for the KVM crashing.  You can install this over what you have, on each box, reboot, and let us know if you still see the issue:

https://cdn.stardock.us/downloads/public/software/multiplicity/Multiplicity_3.51-j40-Setup.exe

Thanks for the patience and feedback.

Sean Drohan
Stardock Support Manager

Hi, my issue is the multipl2.exe crashing it crashes for about 20 mins repeatedly when i try to start it but it eventually stops

i was able to grab a dump but its very small 

https://1drv.ms/u/s!AjtwOUB1LvjqmldtZJU0S7EQ7JUD?e=CPssbs

should this be posted here? i was told to post my dump here in the main topic

it happens about once a day so ill try for a few days and let you know

crashing again with the new j40 build

https://1drv.ms/u/s!AjtwOUB1LvjqmmRGUoUHYdu_PalX?e=8jgU1f

Install this build, on each PC, and let us know, please.

https://cdn.stardock.us/downloads/public/software/multiplicity/Multiplicity_3.52-j42-Setup.exe

Thank you for your time and feedback.

Sean Drohan
Stardock Support Manager

new build, new dump, the crashing does seem less frequent however.

https://1drv.ms/u/s!AjtwOUB1Lvjqm1NI36tyzEPq8T2b?e=PRXUDi

hey, i dont have a multipl2.dll

i have am multip.dll and a multi2.dll

the multip.dll is feb 23 2020

the multi2.dll is September 4th 2020

also I found what causes the crash,

it has to do wit the clipboard, when there's like a blank or maybe just a spacebar character in my clipboard it crashes, as soon as I replace whats in my clipboard with text or something it seems to work. i have a clipboard history tool and the item that makes it crash appears to be just blank, I'm not sure what I  copied to get that, its possible I copied something else that multiplicity didn't like and so it makes the clipboard blank but it does seem to be clipboard related. cuz if I go back in my clipboard history and choose that particular item it will crash every time if I switch it to something normal the app wont crash.

Hi, its not the Microsoft clipboard history or sync. im using a third party tool called ditto, but it just records your clipboard and lets you search previous clipboard items. but i don't think the issue is due to the that software.

I do think the issue is related to clipboard items but i think its something else

I work in IT and am constantly remoting into other users computers through a software called screenconnect or "connectwise Control"

which also syncs clipboards from my machine to the remote machine and vice versa, it seems like something happens where the clipboard doesn't sync properly from the remote machine and makes my clipboard blank or perhaps some other sort of invalid value, and its when that happens and i try to move the other screen with multiplicity, that is causes the crash. as soon as clip something else the crashes stop.

I haven't been able to figure out exactly whats causing the clipboard items to go weird from a remote users machine. but i think if you catch or sanitize invalid clipboard values before trying to sync it to the other multiplicity machine that should help.

That is very strange.  I wonder why they would be putting an entirely blank text entry into the clipboard rather than just emptying it?

We will see if we can see whats going on as a 0 length entry shouldn't cause a problem.