P: Lightroom Desktop on macOS freezes & crashes at launch and export

I'm hitting the same freeze pattern and I've traced it to a specific cause. Posting the detail in case it's useful.

Environment: Lightroom 9.4.1 (build 20260625-0318-d30e963), macOS 26.5.2 (25F84), M5 Max / 128 GB, arm64 native. Reproduced identically on 9.4.

It's a hang, not a crash. No .ips crash report is generated for these events — every Lightroom entry in DiagnosticReports is a "disk writes" resource report. Adobe's own crash reporter also fails to launch, with error -1712 (Apple Event timeout), consistent with the app being unresponsive. So this class of failure may not be reaching you through normal crash telemetry at all.

What the spindumps show. Six spindumps across separate sessions, all identical. The process has hit the dispatch thread soft limit:

Processes reached dispatch thread soft limit (90): Adobe Lightroom

The main thread is blocked on window activation, which is exactly when the beachball appears — restoring a minimised window, or Show All Windows:

-[NSApplication _handleActivatedEvent:]
  -[NSNotificationCenter postNotificationName:object:userInfo:]
    -[NSOperation waitUntilFinished]
      __psynch_cvwait

And 83,000+ samples are parked in the GrowthSDK queue:

DispatchQueue "GrowthSDK"
  libAdobeGrowthSDK.dylib
    dunamis_ingest_flush
      dunamis::IngestInstanceImpl::flush(...)
        dunamis::Pipeline::flush()
          std::this_thread::sleep_for(...)

CPU time is only ~5.6s across those 83,000 samples, so the threads are parked in a retry loop rather than doing work. A healthy session on the same machine shows 16-17 samples across 2-3 threads.

What the Dunamis logs show. This is the part that identifies the cause. From ~/Library/Logs/Adobe/com.adobe.dunamis/, repeating for the length of a 100 MB log file:

xfr.req    cancel: code=dunamis_http_error:0 token=20651
xfr.req    request is cancelled: url=https://cc-api-data.adobe.io/ingest
           status=0 None reason= verb=POST
evt.store  push: bal=9268 name=main.anon_events.0.v1.<uuid>
xfr.req    cancel: code=dunamis_http_error:0 token=20652
evt.store  push: bal=9269
...

Three things there:

• POSTs to cc-api-data.adobe.io/ingest return status=0 — no HTTP response at all, not a 4xx or 5xx.
• Every cancelled request pushes its events back onto the store. The backlog (bal) climbs monotonically: 9268, 9269, 9270, 9271.
• Retries continue with no visible backoff and no drop policy, each consuming a dispatch thread, until the pool is exhausted and the main thread deadlocks.

Transfer token count exceeded 20,655 in a single session.

The endpoint itself is fine. From the same machine with Lightroom quit, DNS resolves normally and curl -X POST https://cc-api-data.adobe.io/ingest returns 403 in 0.82s. Whatever produces status=0 is happening inside the SDK.

Time to failure scales with telemetry event volume. Culling — an event per flag and rating — hangs within minutes. Develop work takes around two hours. Idle eventually hangs from queued events. Healthy sessions show status=200 and bal=0.

The account-level opt-out doesn't prevent it. With desktop app usage sharing disabled at account.adobe.com, the log shows:

W  ing.pipeln  discard all events: reason=optout  name=main.auth_events.0.v1.<uuid>

Only auth_events are discarded. main.anon_events keeps collecting and retrying — and anon_events is the queue that grows to 9,271.

Things I tried that didn't help: account-level usage opt-out; full CC sign-out and sign-in; quarantining the Dunamis caches in Application Support and Preferences; CC Cleaner plus a clean reinstall of 9.4.1; rollback to 9.4. Identical spindump signature after every one. The attached spindump is from after the clean reinstall.

Ruled out with evidence: memory (128 GB, 95% free, zero swap, Lightroom peak footprint 3 GB, no jetsam kills); disk space (4.3 TB free); catalog corruption (survives clean reinstall with the library intact); image-processing load (export and denoise spike the thread count past 150 and recover normally — the deadlock never does); DNS; VPN software (reproduced with all of it quit); and folder permissions on ~/Library/Logs, which are drwxr-xr-x with no ACLs — I checked because of the separate 9.4 permissions launch crash.

A few smaller things I noticed along the way:

• That log folder held 1.0 GB across 91 files, one at exactly 104,857,619 bytes — a 100 MiB rotation cap being hit.
• Repeated "fs lock failed: code=35" (EAGAIN) across three instance UUIDs, so multiple processes are contending for the same Dunamis store.
• A latency value of 18347258964us — about 5.1 hours — logged in a session that was six minutes old.
• The duplicate Objective-C class warnings at launch (SODSFileDecode, _GPUOperator, _CPUOperator in both WichitaFoundation and CameraRaw; VFExporter and friends in both CameraRaw and video_toolkit). Present on a clean install, and I've seen other users post the same lines.

What would fix it: bound the ingest retry loop with backoff and an eventual drop; cap the GrowthSDK queue's concurrency so telemetry can't consume the process-wide dispatch pool; stop requeuing events from cancelled transfers without limit; and don't block the main thread on a telemetry-dependent NSOperation during window activation. A telemetry endpoint that stops responding should degrade analytics, not make the application unusable.

Attached: an excerpt of the hang spindump (header plus the full Lightroom process block — the complete file is 29 MB, available on request); an excerpt of the Dunamis log showing the retry loop; and a healthy-state spindump from the same machine and build during a session that didn't hang.

The two spindumps side by side:

hang:     DispatchQueue "GrowthSDK"   83083 samples   cpu time 5.628s
          Processes reached dispatch thread soft limit (90)

healthy:  DispatchQueue "GrowthSDK"      16 samples   cpu time 0.005s
          (no thread limit reached)

The corresponding Dunamis logs show status=200 and bal=0 in the healthy sessions, versus status=0 and bal climbing past 9,271 in the failing one.

Happy to provide any of the six spindumps or the full logs.

​@Sameer K