RW Classic project frozen

I have added over 250 photos + text using Accordion stack on the following page

It worked smoothly while editing. The page was published and all the photos are there (in the host server, verified with Cyerduck)
However, the day after, when I opened the RW project, it is frozen, the wheel is spinning…
I did not save the original picture after editing, but building up progressively this page over several days, it appeared to be not necessary, RW page opened correctly. This issue happened only after the final version.
Any idea about this issue ?

additional info (system log):
AMMuxedDeviceDisconnected, mux-device:31

AMPDeviceDiscoveryAgent[490]: Entered:__thr_AMMuxedDeviceDisconnected, mux-device:31

AMPDeviceDiscoveryAgent[490]: tid:2313 - Mux ID not found in mapping dictionary

AMPDeviceDiscoveryAgent[490]: tid:2313 - Can’t handle disconnect with invalid ecid

Heaviest stack for the main thread of the target process:
17 start + 1903 (dyld + 25631) [0x7ff808c3141f]
17 NSApplicationMain + 817 (AppKit + 14753) [0x7ff80c0c69a1]
17 -[NSApplication run] + 586 (AppKit + 194440) [0x7ff80c0f2788]
17 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1214 (AppKit + 250118) [0x7ff80c100106]
17 _DPSNextEvent + 858 (AppKit + 254556) [0x7ff80c10125c]
17 _BlockUntilNextEventMatchingListInModeWithFilter + 64 (HIToolbox + 191144) [0x7ff812ae5aa8]
17 ReceiveNextEventCommon + 657 (HIToolbox + 191822) [0x7ff812ae5d4e]
17 RunCurrentEventLoopInMode + 292 (HIToolbox + 192317) [0x7ff812ae5f3d]
17 CFRunLoopRunSpecific + 560 (CoreFoundation + 503601) [0x7ff809064f31]
17 __CFRunLoopRun + 2452 (CoreFoundation + 507695) [0x7ff809065f2f]
17 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 9 (CoreFoundation + 770565) [0x7ff8090a6205]
17 _dispatch_main_queue_callback_4CF + 31 (libdispatch.dylib + 64519) [0x7ff808df6c07]
17 _dispatch_main_queue_drain + 751 (libdispatch.dylib + 65284) [0x7ff808df6f04]
17 _dispatch_source_invoke + 2184 (libdispatch.dylib + 96175) [0x7ff808dfe7af]
17 _dispatch_continuation_pop + 463 (libdispatch.dylib + 23397) [0x7ff808decb65]
17 _dispatch_client_callout + 8 (libdispatch.dylib + 12339) [0x7ff808dea033]
17 __39-[RWDocumentController removeDocument:]_block_invoke + 55 (RapidWeaver Classic + 1129175) [0x10385dad7]
17 -[RWApplication performShowProjectsBrowser:] + 79 (RapidWeaver Classic + 599935) [0x1037dc77f]
17 -[RWLaunchWindowController showWindow:] + 117 (RapidWeaver Classic + 1141861) [0x103860c65]
17 -[RWLaunchWindowController updateRenewalStatus] + 97 (RapidWeaver Classic + 1141009) [0x103860911]
17 _dispatch_semaphore_wait_slow + 98 (libdispatch.dylib + 14837) [0x7ff808dea9f5]
17 semaphore_wait_trap + 10 (libsystem_kernel.dylib + 5438) [0x7ff808f4c53e]
*17 ??? (kernel + 1911616) [0xffffff80004aeb40]

Looks like your using the Foundation Framework if you are I would check in with weaverspace forum if thats the case. Could be related to that or the Stacks plugin

@zdenek Hi, All these indicate problems related to USB device connection and disconnection. The first thing to do is to check the condition of the USB cables. The second to identify the USB device marked as mux-device31. Strange problem… good luck :four_leaf_clover::+1:

@zdenek Any chance you can post the full crash report or email it over to

strange, I’m not using any USB, connected via Ethernet cable
Have re-installed RW, but it is the same issue.
crash report sent
refreshed the system.log:

Jun 16 19:43:04 mbp-de-zdenek AMPDeviceDiscoveryAgent[498]: tid:371b - Can’t handle disconnect with invalid ecid
Jun 16 19:44:09 mbp-de-zdenek AMPDeviceDiscoveryAgent[498]: Entered:_AMMuxedDeviceDisconnected, mux-device:6
Jun 16 19:44:09 mbp-de-zdenek AMPDeviceDiscoveryAgent[498]: Entered:__thr_AMMuxedDeviceDisconnected, mux-device:6
Jun 16 19:44:09 mbp-de-zdenek AMPDeviceDiscoveryAgent[498]: tid:371b - Mux ID not found in mapping dictionary
Jun 16 19:44:09 mbp-de-zdenek AMPDeviceDiscoveryAgent[498]: tid:371b - Can’t handle disconnect with invalid ecid

I can also add following observation I have just made:
I have another old RW project which is much smaller (not using Foundation) which can be opened and is not frozen. Keeping it open, I open the issue project - the page appearing after opening is not blank, but I cannot do any changes (it seems blocked). Trying to open another page inside this project file, it appears blank.
My issue seems to be linked to the current project file (using foundation 6, recently updated).
Perhaps this could help a bit …

Yes it’s weird : ecid refers to iOS device. Again it’s like an USB problem, a device now call mix-device:6 is searched. It appears the system considers a wrong (or uncomplete) disconnected device. Don’t understand what it is. Can’t help more. Sorry.

another element - signature issue ? :
spindump RapidWeaver Classic com.realmacsoftware.rapidweaver8 ||| 9.2.1 (21062) ((null)) hang noop YES
SenderMachUUID: 98F8E391-14A0-309C-98A1-21A556884AB1

Nothing worthy here, just a crash report from macOS to Apple.

Before having this issue, I remember updating Foundation 6 theme. Today, I got another update (6.18.1 from 6/10/2024) without any change. I don’t know it this can be the origine of the RW file freezing, but to check it, would it be possible to download the older version of Foundation 6 (not the penultimate, but 2 versions ago).

Not sure there are any public archives you could download old versions from. You could probably contact Weaver’s Space support and they could send you an older version of Foundation 6 though if you want to test.

Also do you have Time Machine backups enabled? If so you should be able to restore an older version of Foundation 6.

Hi everyone,
Finally, the source of the freezing were the 2 “Compostelle” accordion stacks. Most probably due to the over 200 pictures originally directly embedded by drop&drag in the RW file. However, I did not really catch up why the first day this worked but not after.

So, from TimeMachine, I recovered the previous version of my RW project file and rebuilt completely both Accordion stacks. I did not embedded the pictures in, but used the warehouse link option with URL adresses for each of them.

As my website is mostly dedicated to photography, I think using ressources weights down the file size and it would be better to keep this in mind for the future.
However, if you can dig out some information from the crash report, it would be interesting to know if there is something else generating this issue.
Anyway, thank everyone for your help.

Most of us with very large projects keep assessts warehoused this way it keeps the project file size down and publishing is a lot faster when and if you need to republish pages.

1 Like