It has something to do with the Administration access.
Seer has to have the exact same privilege with dopus.exe.
A straightforward way to run them with same privilege is to open Seer's installation folder, then double click Seer.exe to run.
Here is what I found. @Leo
Everytime you start the main process, dopus.exe, it runs the helper process, dopusrt.exe, with same privilege.
When you quit dopus.exe, dopusrt.exe is still running in the background. The next time you start the main process with different privilege, dopus.exe and dopusrt.exe will have different privilege. This is the case dopusrt.exe stops working.
Even if the dopusrt.exe has Admin privilege and dopus.exe hasn't, it still doesn't work.
Running Opus elevated should be avoided as it causes problems exactly like that, many of which are unavoidable due to how to the Windows APIs we have to work with behave.
Instead, people can use Opus's UAC support, which includes the ability to elevate a window and keep it elevated, without elevating the whole process.
If you run DOpusRT elevated when Opus isn’t elevated, DOpusRT will be able to talk to Opus but Opus won’t be able to send results back to it. (If it’s the other way around then the problem is the opposite.)
DOpusRT should be run at the same elevation level that Opus is at, which in turn should (almost always) be the same level the Windows shell (explorer.exe) is at, i.e. unelevated.
DOpusRT has a /runstd mode you can use to run any command unelevated, so you could use that on itself to drop elevation if needed:
We use that in our installer to launch Opus, but it’s also there as a general utility since it’s otherwise quite hard to run things unelevated from something that is elevated. (It’s like Microsoft didn’t think of it when designing UAC.)
