Search results

client windows laptop, two finger scrolling on touchpad does not do anything on host. if this is not by design, can you add the function? making scrolling a lot easier.

It only consumes CPU when in remotely session. And killing it breaks the session.

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...

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.

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. However, it would nice if you could fix the VM crashing right after installation while GPU-P is enabled. this...

To make sure we don't waste time for one-ff, I did a fresh install. Fresh VM installation of Win Srv 2022 without GPU-P. enable GPU-P and install AMD drive inside VM. reboot, and install remotly (run as admin). after installation, during UI loading, VM crashes. shut-down VM, disable GPU-P...

I am not aware there is difference between administrator and Administrator. aren't windows user name not case sensitive?

this is windows 11 (the hyper-v host)

The VM (win srv) remotly_boot.exe under SYSTEM remotly.exe under administrator. again, only administrator is used in VM. also tried to disable GPU-P for VM, and the same behavior.

"lastuser" is administrator. the hand-over never happened. and there is never an reconnection during login or logout. i.e. with VM/GPU-P hand-over never happens, everything is handled by booter service.

In all my testing in this thread, only administrator account is used. when "no UI" (connect via remotely and login after reboot), both remotly_boot.exe and remotly_boot_svc.exe are both in task manager. one instance of every process related to remotly then connect and login via hyper-v...

finally figured out how to avoid VM crashing. repeat the setup, a previous copy of VM disk, which never had remotely installed. connect via hyper-v terminal 1. update to latest AMD driver that worked. GPU-P enabled and working, installe remotely, VM crashes while remotely UI is loading. 2...

what I meant by "no UI". 1. remotly.exe is visible and running in task manager, runs under administrator account. booter process runs 2. "start within windows "minimized" selected before rebooting. 3. connect via remotely client, login, remotely icon not visible in the tray (and no...

if virtual disk is disk-0, made a copy of it before installing remotely (disk-1). then play with all remotely settings in disk-0, (registry, new versions, update AMD driver), and eventually disk-0 works fine except for the no UI problem. now, use disk-1 instead, upgrade AMD driver and...

Not using checkpoint. Just copy virtual disk. Have done this for several years as way of backing up which hyper-v does not allow with Gpu-p

It is safe as long as hardware is the same and gpu-p status is the same

I had a previous copy of virtual dsk before installing remotly. Used that one and crash happened again.

new version about booter process in VM. re-install (use "run as admin") and reboot, no booter. login, no booter. logout and login again, there is booter. however, I did NOT need to run remotly.exe manually with "run as admin" Same no UI behavior in the new version

VM/GPU-P crash question -- for the 1.33 installer, are manual registry entries needed? I have been playing with remotely inside a copy of the VM machine in last a couple of weeks, accumulating all these fixes/versions. and it does not crash with 1.33 versions. today, I went back to earlier...

Always the same user which is the built in administrator