RoonServer won't start on MacMini after update (ref#3KHR4Y)

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· I've just ran the latest "Update All" from my Roon desktop client. This includes updating my RoonServer (MacMini running Monterey 12.7.6). After the update, RoonServer refuses to start. I've tried the following:

1. Rebooted the MacMini
2. Opened Roon application to go directly to RoonServer and tried to manually restart.

Neither of these worked. Looking at Mac Activity app, RoonServer is not running.

Tell us about your home network

· I'm using Unifi UDM Router. All Roon connections are ethernet connected from the MacMini to my iMac running the Roon desktop app, to my UntraRendu to connected to my Chord Qutest. All hard wired that was working perfectly until today's update.

Hello @rayski ,

Thanks for reaching out. Was there any change after you reached out? We activated diagnostics for your account, and it looks like the Roon UI app updated to the latest build, but the log for RoonServer abruptly ends after installing the update. Are you seeing any errors in MacOS Console when trying to launch RoonServer?

Hi,

Nothing in the Mac Console for the install, but I do get the following log information every time I try to manually start RoonServer:


Translated Report (Full Report Below)

Process: RoonServer [1188]
Path: /Applications/Roon.app/Contents/RoonServer.app/Contents/MacOS/RoonServer
Identifier: com.roon.RoonHeadlessManager
Version: 0.0.1 (0.0.1)
Code Type: X86-64 (Native)
Parent Process: launchd [1]
User ID: 501

Date/Time: 2026-08-04 14:23:47.3233 -0400
OS Version: macOS 12.7.6 (21H1320)
Report Version: 12
Anonymous UUID: D7D75CF7-AE2D-65E5-E33A-DD1C28F01DB5

Time Awake Since Boot: 7300 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4
Terminating Process: exc handler [1188]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 AppKit 0x7ff80ba18488 NSCGSPanicv + 261
1 AppKit 0x7ff80ba18383 NSCGSPanic + 114
2 AppKit 0x7ff80b82b874 +[NSCGSStatusItem _statusItemWithWindowID:isReplicant:parent:confiningDisplayID:flags:priority:systemInsertOrder:preferredPosition:appearance:] + 354
3 AppKit 0x7ff80b82b8a2 +[NSCGSStatusItem statusItemWithWindowID:confiningDisplayID:flags:priority:systemInsertOrder:preferredPosition:appearance:] + 46
4 AppKit 0x7ff80b74019b -[NSStatusItem _wakeStatusItem] + 316
5 AppKit 0x7ff80b2855ba -[NSStatusBar _statusItemWithLength:withPriority:] + 95
6 RoonServer 0x1090ef9a9 xamarin_dyn_objc_msgSend + 217
7 ??? 0x11c9a32cf ???
8 ??? 0x11c9a31a9 ???
9 ??? 0x11c9a308f ???
10 ??? 0x11c074367 ???
11 ??? 0x11c073fee ???
12 ??? 0x11b5de545 ???
13 libcoreclr.dylib 0x10a7db0cc CallDescrWorkerInternal + 124
14 libcoreclr.dylib 0x10a6601d4 MethodDescCallSite::CallTargetWorker(unsigned long long const*, unsigned long long*, int) + 1572

About a thousand rows for the “CallTargetWorker(unsigned long…)” messages. Followed by scores of messages concerning images and other objects.

Then after all those the following messages to close the log:

“vmSummary” : “ReadOnly portion of Libraries: Total=1.3G resident=0K(0%) swapped_out_or_unallocated=1.3G(100%)\nWritable regions: Total=621.4M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=621.4M(100%)\n\n VIRTUAL REGION \nREGION TYPE SIZE COUNT (non-coalesced) \n=========== ======= ======= \nActivity Tracing 256K 1 \nColorSync 204K 23 \nFoundation 16K 1 \nKernel Alloc Once 8K 1 \nMALLOC 191.3M 279 \nMALLOC guard page 32K 6 \nMALLOC_LARGE (reserved) 944K 2 reserved VM address space (unallocated)\nMALLOC_NANO (reserved) 384.0M 1 reserved VM address space (unallocated)\nSTACK GUARD 56.1M 16 \nStack 23.4M 16 \nVM_ALLOCATE 2.2G 3731 \nVM_ALLOCATE (reserved) 64K 1 reserved VM address space (unallocated)\n__CTF 756 1 \n__DATA 41.3M 837 \n__DATA_CONST 50.0M 587 \n__DATA_DIRTY 2791K 359 \n__FONT_DATA 4K 1 \n__LINKEDIT 653.7M 38 \n__OBJC_RO 82.9M 1 \n__OBJC_RW 3200K 2 \n__TEXT 715.4M 846 \n__UNICODE 592K 1 \ndyld private memory 1024K 1 \nmapped file 178.9M 99 \nshared memory 796K 23 \n=========== ======= ======= \nTOTAL 4.6G 6874 \nTOTAL, minus reserved VM space 4.2G 6874 \n”,
“legacyInfo” : {
“threadTriggered” : {
“queue” : “com.apple.main-thread”
}
},
“trialInfo” : {
“rollouts” : [
{
“rolloutId” : “5ffde50ce2aacd000d47a95f”,
“factorPackIds” : {

  },
  "deploymentId" : 240000553
},
{
  "rolloutId" : "60f8ddccefea4203d95cbeef",
  "factorPackIds" : {

  },
  "deploymentId" : 240000025
}

],
“experiments” : [

]
}
}

Hi Roon Support,

Is it possible to fallback from this version of RoonServer to previous version?

Dear Tech Support,

The Community banner highlights the Server issue with the ROCK & Nucleus with a workaround (i.e. disregard the warning, your server is still running), but there is no recognition of the 2.71 Server’s complete failure in the MAC world, regardless of which version of the Mac your Roon Server is running on.

Although as a software developer myself, I appreciate the need for some patience, however a lack of communications here is frustrating. Us in the Mac world have been totally down now for over 24 hours without any update from Tech Support. Is a fix coming soon? Are there fallback options available to us? At this point I have no idea what today, tomorrow or next week brings in terms of being able to listen to music again.

An update, any update would be greatly appreciated.

Hello @rayski

The fix is out. Roon 2.71 build 1683 was released yesterday and it specifically fixes Roon Server failing to start on macOS 12 and 13. Your crash report matches it exactly.

Please download it from

and install over the existing copy in Applications, then launch it from Applications rather than from the mounted disk image. Your library and settings are untouched.

On your question about rolling back to a previous version: we do not recommend it, and it is worth knowing why. The database format is upgraded when you move to a new release, and older builds cannot read the upgraded database. Going backwards would mean restoring a backup taken before the update, and anything added since would be lost. As a rule, the way out of a bad release is forward rather than back, which in this case is build 1683.

Please let us know once you are on 1683 and everything is back up.

@vadim I’ve successfully installed 1683 and everything seems to be working fine again. Thank you.