Title:
Cubase 14.0.41 — Reproducible UI hang (BusyHang) when adding/moving
tracks in large audio projects; main thread loops while holding SRW
lock, 16 worker threads blocked
Environment
- Cubase Pro 14.0.41 Build 374 (64-bit)
- Windows 11 24H2 (Build 26100)
- RME Babyface Pro FS, ASIO Fireface USB driver (latest, firmware
up to date) - Large post-production project: many audio tracks, third-party
plugins loaded (UAD Native, Waves, iZotope, etc.)
Symptom
When adding, moving, or deleting a track in a large project, Cubase
becomes unresponsive (“Not Responding”) for a very long time, or
seemingly indefinitely. During the hang, Cubase14.exe continuously
consumes ~7-11% CPU (about one full core), so this is a busy loop,
not idle waiting. In small/early-stage projects the same operation
completes instantly. The hang duration scales with project size.
What I have ruled out (each tested separately)
- Safe Mode with all third-party plug-ins deactivated: NOT
reproducible. (Note: with plugins disabled the engine graph is
much smaller, so this may reflect workload size rather than a
faulty plugin — see dump analysis below.) - “Disable program preferences”: still reproducible.
- Audio interface driver: updated to latest RME driver + firmware,
still reproducible. - ASIO Guard: reproducible with Guard on Low AND with Guard fully
disabled.
Dump analysis (two separate hang dumps, WinDbg)
Both dumps were classified as:
FAILURE_BUCKET_ID: APPLICATION_HANG_BusyHang_cfffffff_Cubase14.exe
Main thread (thread 0) in both dumps is executing inside Cubase code
dispatched from a UI message (user32!DispatchMessageWorker →
UserCallWinProcCheckWow → Cubase14). The mid-stack call chain is
IDENTICAL across both dumps:
Cubase14+0x29834c1
Cubase14+0x4624c70
Cubase14+0x3b229ba
Cubase14+0x3b22048
Cubase14+0x466773a
…
user32!DispatchMessageWorker
Only the leaf differs between dumps (0x1ae10f0 vs 0x320ed83),
i.e. the same operation captured at two different moments — the
main thread is progressing inside a very large loop. In the second
dump the current instruction was sub r8,1 (counting down inside
a loop), consistent with the sustained CPU usage.
Meanwhile, in BOTH dumps, 16 internal worker threads are blocked
at the exact same location waiting on a shared SRW lock:
ntdll!RtlAcquireSRWLockShared
Cubase14+0x4585283
Cubase14+0x4586121
Cubase14+0x4608651
No third-party module (plugin or ASIO driver) appears anywhere in
the hanging call chains; all plugin and driver threads are idle in
normal wait states.
Interpretation
A track add/move triggers a main-thread recomputation whose cost
appears to scale with total track/plugin count. The main thread
holds a lock during this loop, so the entire application (UI and
workers) stalls until it completes. In late-stage projects this
takes minutes or appears infinite.
Repro steps
- Open a large audio project (many audio tracks + plugins).
- Add a new audio track, or move an existing track.
- Cubase shows “Not Responding”; CPU stays at ~one core.