Okay, so the process IDs in question were MMCs. I closed all of them, and the last process ID was Fujitsu's DeskUpdate (the computer I'm using is a Fujitsu workstation). I closed that as well, and now I don't receive any error message at all, just a the Window Picker after a short while. Very strange!
That's weird. I'm not able to reproduce the issue. Can you reproduce it on a different machine as well?
Sorry for the late response. No, I couldn't reproduce it because I didn't h ave access to a different machine. However, the issue hasn't resurfaced so far. So fingers crossed it was just a one-time incident, probably related to increased solar flare activity.
I see. Thanks for getting back. Please let me know if you see the issue again.
cheers,
Stefan
I can confirm this:
|
Looks like Royal tries to find the Putty session for embedding the terminal, and searches every process ID for its name. But thats only a uqualified guess from my side
We actually know the PuTTY process ID and we are looking for a specific window created by that process ID. We don't pull in a window from a different/unknown process id.
Just updated to 5.2.60420. I see the same error here.
That's weird. Are you running a Windows Insider build? Do you have some secuity/personal firewall tool installed which may interfere?
If I start Royal with Admin rights, the error message is gone, and its way quicker to embed the connection
Hmm, it looks like that the PuTTY executable is started elevated then but I have no clue how that's even possible. Are you using the shipped PuTTY version included with Royal TS or are you using your own PuTTY from a specified path in the plugin settings?
Using shipped putty. Plugin - Terminal - putty has no modifications
Can you please check if the process started by Royal TS (when not started as admin/elevated) is elevated using the task manager:
Thiesi
1 person has this problem