RU works fine for me with TEMP directories on a ramdisk (created using ImDisk, just like yours).
Your error relates to a problem in Windows 10 v1809 (I think) or newer which I encountered myself - some fault in the Installer service prevents access to the actual MSI file extracted from the original EXE. It's not limited to RU, either - every MSI-saved-to-EXE I tried has it, too. You can get around the problem by getting the MSI file and running "msiexec /i file.msi" as admin; you can either get the MSI version directly, or you can run the executable, have it fail due to the error, but before you close it, copy the MSI file from the TEMP directory.
I already did, but did not observe any change. Note, though, that I did it remotely and wasn't able to restart RU, so I expect the change did not take effect yet. I will restart the computer tomorrow and then test how it behaves.
I can confirm I have the same issue on initial redraw. I don't think it came with 6.10.9, I faintly recall being annoyed by this behavior even with older versions (but I am not sure and I certainly don't remember which version started that). I also use direct connections, but I didn't try legacy capture yet.
1) I suspect this may be (partially) caused by the active screen saver. It might be a good idea to "move the mouse" on connection so that the screen saver is turned off.
2) The initial redraw is slow, even if the initial screens (blanking screen saver, fixed-color login screen) are very simple. Once the initial redraw is done, the succeeding redraws are much faster - in fact, redrawing a desktop with complex and diffult-to-compress background is maybe twice as fast as the initial redraw of a one-color lock screen...
I don't have any extensions in Edge, as far as I know. I don't use Edge at all, except that it gets started by your competitor's product to let me enter a description of what I did.
It may be the incompatibility occurs only in certain situations. I use a very non-typical connection scheme with RU, for example (instead of a connection server I use a direct reverse connection [from Host to Control] over a SSL tunnel, and I use screen blanking too; plus the Windows are set up with many specific settings). If RU is able to log the necessary system calls, I can activate the logs, reach the unresponsive state and then send you the results. Perhaps that would be the easiest way of debugging this?
I will also see whether I can replicate the error in a virtual environment, but that may be difficult to achieve.
Just remembered: This incompatibility wasn't always there. There was a time when RU and ME would coexist peacefully. Unfortunately, I can't remember how long that was, as I have been running into this issue for quite a some time until isolating the actual cause and resolution and writing here. It is possible it worked with a pre-6.10. RU or perhaps with an older version of Windows 10.
Recently I noticed a rather annoying compatibility issue between Remote Utilities (RU) and Microsoft Edge (ME):
I use RU to connect to a remote computer (RC). Everything works fine until I start ME on RC. At that moment the RU connection will fail. Particularly, the display will stop transferring data, will turn to black and white, report a lost connection ("connection was interrupted") and fail to reconnect. If I close the full control window and try to reopen it, I get a "certificate warning - potential security breach" and no matter the choice, the connection will not get established, even if I restart RU.
The only functional solution is to connect to SC in the Task Manager mode and kill Microsoft Edge. That solves the problem and I can once again connect to SC using full control.
Unfortunately, I can't avoid using ME, because there is a case where the application concerned (one that I have to use) will start it on its own. Also, if ME can cause this kind of a failrure, I can't help but worry about which other application will do the same thing. It also makes it rather difficult to switch to RU for my customer support needs (I use it for my own purposes now), because what would I do if the customer actually liked Edge and had it running?
SC is running Windows 10 Pro 1809, ME is updated, RU is 184.108.40.206 on both sides of the connection.
I just noticed that Remote Utilities seem to incorrectly interpret keys on the numeric keypad. At the very least, the numeric plus, minus, times and divide are sent as regular keys rather than numeric. It is easily noticeable in two-panel file managers where these keys have a different meaning - a regular plus is simply a plus, a numeric plus allows group selection of files.
Not really. I suggested PRO so that you wouldn't lose your income, but there's a lot of sense in allowing these temporary connections even when the number of bookmarks is unlimited: It would help keep the list uncluttered and easy to navigate (there is little point in keeping a connection which was purely one-time, and it might be rather difficult to actually find a stored connection if there are hundreds or thousands of them). Also, if a new Agent connection was to be stored permanently, the user would have to provide sufficient details to make the bookmark usable (e.g. think up a descriptive name), which would take some unnecessary effort.