· I am currently in the trial, but at least once a week, I do something that causes Roon not to start or to start and have the not responding and I have to go different hoops to get it to work again. I have two monitors and from my reading that seems to be a problem for Roon. I am running a Roon Server on a Windows 11 25H2 PC and Roon on my office desktop on the same version of Windows. I have two 4K monitors and as I say, Roon, will work, work, work, then I do something simple like oops close it while it is in my left-hand monitor and that is it I killed it. This cannot be standard operating procedure. Is there a permanent fix as I will not be uninstalling and reinstalling every time, I forget it is monitor sensitive.
Tell us about your home network
· Verizon Fios, Mesh 6 routers, but most stuff (including all the PCs) are wired to a gigabit switch.
Am I understanding that the GUI hangs and you have to force it closed and restart? Does the server remain open in the background?
We’ve requested remote diagnostic logging from the affected GUI instance that should have pinpointed the event. Please open Roon at your convenience on that computer and we’ll follow up shortly once we learn more from logs.
Roon Server and Roon Client are both running on my Media “Server” running Windows 11. I have a dual monitor client stock and the Window I sent which is to say no real Roon running. It works fine for days, then I (based on what I have read), close the window on my extended monitor and then Roon never runs at all, or goes into this state. I believe I have fixed it before buy uninstalling the client, deleting everything and reinstalling. I just purchased the Hifi Rose RS420 today and would love to use Roon with it when it comes, but this will make me rethink and perhaps use the Hifi Rose App. Thank you.
Okay, that worked, Roon now starts on my client, and this is easier than reinstalling all the time. However, it still seems like a bug. Is there a setting to always start the primary monitor?
Logs show that these two monitors have separate scaling applied, with the Primary at 100%, Secondary at 125%; secondary positioned left of primary. It looks like the application tends to hang when you move the window to the left screen, just as you described.
That is generally the way I have it (Hey, I am 69 and sometimes I need things bigger). However, I just checked and they are both set to 100% scale currently. This is likely because I was troubleshooting Roon the last time.
For weeks the window sat at healthy positive coordinates on the primary and sessions were long and stable:
05/28–07/06: positions like 688|76, 321|248, 7|1, 611|215 — all on-screen, all fine.
Then the window got moved to the left/secondary monitor:
07/07 11:28:57: saving pos=M611|215... size changed to {Width=3456, Height=1408} (the M = maximized; note the different resolution, i.e. the second display).
07/07 11:29:01: saving pos=-2157|286... location changed to {X=-2157, Y=286}: window now at negative X = secondary monitor, left of primary.
From that point every single launch restored to X=-2157, Y=286, and the sessions turned short and unstable on the morning of 07/08:
log.07 (10:39–10:41, ~2.5 min): restored at -2157, then abruptly ends with no clean "closing window" (force-killed).
log.06 (10:43–10:44, ~1 min): same.
log.05 (10:47): restored at -2157, ends in a repeating crash cascade: Critical: scx: System.NullReferenceException at Sooloos.Broker.Distributed.DistributedBroker.LostBroker(...).
That rapid open→hang→force-close→reopen cycle is exactly your experience of "not responding, have to jump through hoops" description.
The good news is that the fix is now confirmed in the logs:
That is the moment the saved_window_pos file was renamed (@noris’s step). Immediately after, every launch restores cleanly at 688|288 on the primary, and the later sessions run normally through 07/09 evening.
All of this said, we’ll share this information with development to help with longterm diagnosis and a solution.
Glad the rename trick keeps you moving in the meantime. This is already flagged with the development team as a tracked bug (the window saving negative coordinates when it’s dragged onto the secondary monitor), so a proper fix can go in without needing the workaround. We’ll follow up here if there’s an update on that front.
Thanks for sticking with the troubleshooting; your logs made this one easy to pin down exactly.
We have a ticket in the queue with development to investigate and resolve this crash. We don’t have a timeline to a potential fix, but we’ll share more information promptly as it becomes available.
Thank you for your patience in the meantime, and we appreciate the diligence of your reporting.
