Is LastUser also "administrator" and not "Administrator"? Remotly.exe is not starting as it is waiting for a hand-over. Full version will not start properly as it waits for booter to close (it is the same device - same Connection ID).The VM (win srv) remotly_boot.exe under SYSTEM remotly.exe under administrator. again, only administrator is used in VM.
View attachment 241
also tried to disable GPU-P for VM, and the same behavior.
Here everything works OK.this is windows 11 (the hyper-v host)View attachment 242
I am not aware there is difference between administrator and Administrator. aren't windows user name not case sensitive?Is LastUser also "administrator" and not "Administrator"? Remotly.exe is not starting as it is waiting for a hand-over. Full version will not start properly as it waits for booter to close (it is the same device - same Connection ID).
well, not sure if worth troubleshooting more as fresh installation does not have the problem. maybe related to being domain controller. or just unique with the specific VM I have.I have changed LastUser value by hand to make it case sensitive. Remotly.exe starts anyway. The difference is that I see two different devices as "ready to connect" one is the booter and the other being full version. But it does not prevent Remotly.exe from starting.
Something else is preventing full version from starting.
booter service does not start with GPU-P off (after installing with GPU-P on, but VM crashes, have to turn GPU-P off). once turn GPU-P back on, and boot up the VM, booter service starts. should be something about booter service interacting with GPU-P.Forgot one thing regarding booter service. It will not start when "Keep me logged in" is not enabled.
Booter service has nothing to do with GPU-P. It would also have happened our side if it did. We are testing on 6 VMs with GPU-P at the moment and do not see this problem on v1.33.booter service does not start with GPU-P off (after installing with GPU-P on, but VM crashes, have to turn GPU-P off). once turn GPU-P back on, and boot up the VM, booter service starts. should be something about booter service interacting with GPU-P.
We would already fix it if it had happened at least once in our labswell, not sure if worth troubleshooting more as fresh installation does not have the problem. maybe related to being domain controller. or just unique with the specific VM I have.
However, it would nice if you could fix the VM crashing right after installation while GPU-P is enabled. this happens every time and requires to turn GPU-P off, get remotely start for the first time, and then turn GPU-P on.
Actually this sentence:beat the dead horse one last time. using the official 1.33. install w/o GPU-P (hence no crash), then enable GPU-P.
remotly_boot.exe still sticks around preventing remotly.exe from starting and it is consuming decent CPU time . if manually kill remotly_boot.exe, remotly.exe start right away and works fine.
on the booter process, seems that an explicit logout/login (not just restart) is enough to get it running.
since these seem to be unique problem with my setup, should probably stop here. I will keep monitoring this in future versions.