The second one looked possibly GPU related, but that’s hard to say for sure. So I looked at the first one. The first one is not obvious. I see a lot of mediaclient in there, but not sure how Cubase uses that, and we don’t have Cubase private symbols, so I asked Claude Opus 5 to take a look, and with its understanding of our MIDI stack, ensure it’s not there, and if not, where the hang may be.
Here’s the section it recommended sharing with you:
For the customer
The freeze is in MediaBay (Steinberg’s media/preset database client), entered from a window-message hook chain. Things worth trying, roughly in order of effort:
- Rebuild the MediaBay database. Close Cubase, delete the MediaBay DBs in
%APPDATA%\Steinberg\Cubase 15_64\MediaBay\ (or via Preferences), restart. A corrupt/huge DB or a scan path pointing at a slow/offline network or NAS drive is the usual trigger for this exact stall.
- Remove offline/network locations from MediaBay scan paths (unmounted NAS, external drives, cloud-synced folders). A stalled path can leave the client waiting on a response that never arrives.
- Test with Guitar Rig 7 disabled. It has message hooks in the dispatch path here. Not proof of guilt, but it’s cheap to isolate — blocklist it and see whether the freeze recurs.
- Update Steinberg Library Manager / Activation Manager, since
mediaclient.dll is a shared component under Common Files\Steinberg.
- Report to Steinberg with these offsets — they can map them instantly:
mediaclient.dll 1.3.80.59, module base 0x2e250000, return addresses +0x861af, +0x2f96e, +0x1b3662, +0x13158, and the Cubase-side contended SRW lock call site Cubase15+0x44860c3.
Other third-party modules present, for context: Focusrite USB ASIO, Softube SSX (Bass Standard V8, Amp Room…), IK Multimedia AmpliTube 5 / MODO DRUM, Arturia, NI Guitar Rig 7, Groove Agent SE.
The second dump that shows DirectComposition does look more to be GPU related. It has nothing in common with the MediaBay-related hang. This one also looks possibly related to the PC going into a power saving mode, so I asked Claude to look at this one as well, and see if there was anything in common with the earlier issue. It agreed with my thought that you should check for updates on your GPU driver as it’s likely related to that.
New lead for the customer
The Intel iGPU driver is igd10iumd64.dll version 30.0.101.1371 — that’s a 2021/2022-era driver running on Windows 11 build 26200. A stale display driver stalling DWM is a very plausible cause of an indefinite NtDCompositionWaitForChannel, and igxelpicd64 (part of that same driver package) is sitting in the window-hook chain. Suggested actions, in order:
- Update the Intel graphics driver to a current DCH release (or the OEM’s latest). Highest-value change here.
- Ask whether the whole desktop stuttered/froze during these events, not just Cubase — that would confirm a DWM/GPU stall rather than a Cubase bug.
- If Cubase 15 exposes a hardware-acceleration / DirectComposition toggle for its UI, try disabling it as a workaround.
- Keep the MediaBay rebuild + scan-path cleanup from the first report — that one still stands on its own for the Aug 7 freeze.
- For Steinberg:
Cubase15+0x44860c3 (contended SRW acquire, 16 workers) and Cubase15+0x4b43484 (the DComp wait call site) plus the Aug 7 mediaclient.dll 1.3.80.59 offsets.
One thing I’ll flag as uncertain: user32!_fnPOWERBROADCAST+0x94 appears on the Aug 11 UI stack near the kernel-callback frames. If that’s a live frame rather than a stale apfnDispatch table pointer, a WM_POWERBROADCAST (sleep/resume, display off, or power-source change) was being dispatched when it hung — which would fit a display-reconfiguration stall neatly. Worth asking the customer whether the freezes follow the machine waking, the display sleeping, or unplugging AC power.
Hope that helps.
Pete
Microsoft
