Cubase 11 Crashes a lot - Help!

Cubase
1

Cubase 11 on iMac (2020, 10 core intel core i9, 128 Ram, Sequoia 15.3.1) crashes persistently, often multiple times a day and up to five times within an hour, frequently without generating a crash report.

Each crash mandates a frustrating 5-minute stall for the project to reload, causing significant disruptions.

With a decade of experience using Cubase, I have observed a deteriorating stability over the years, rendering the current situation unbearable.

Given these persistent crashes, the query arises: has anyone else faced similar challenges?

Contemplating an upgrade to version 14 as a potential remedy prompts caution, as investing in an update that may not effectively tackle the current issues is a concern. The thought of exploring alternative DAWs grows increasingly compelling if no resolution appears on the horizon.

As the crashes are triggered by various actions, including recent instances like engaging the playback macro of ‘move backword’ that I created, it suggests that the issue is not solely related to plugins. (From my perspective, even if crashes are tied to plugin-related challenges, they underscore a fundamental flaw in the DAW itself, because there are many plug-ins but only one DAW)

I welcome any recommendations or assistance to address this critical matter. Thank you.

2

Hi,

Cubase 11 doesn’t officially support macOS 15.

Attach the *.ips file(s) to be able to inspect, where do the crashes happen.

3

Cubase 11-2025-03-08-090545.ips (820.3 KB)

Thank you for your assistance. Based on my previous experience, updating from Cubase 10 to Cubase 11 did not resolve the occasional crashes, which was updated especially for that, Hence, it is imperative to confirm that the issue lies with macOS before considering another investment of $250 that fails to address the problem effectively.

4

Potentially a VST plugin. Are you using a convolution reverb or other impulse response-based plugin, possibly 3rd party? There’s reference to FFT HRIR processes and Cubase apparently waiting on a response from (potentially) a plug-in.

Maybe scour your project for something like that while the pro’s review your IPS. Might help.

[Attribution: ChatGPT analysis of file, not me knowing what I’m doing.]

1 Like
5

I appreciate your assistance. I have integrated reverb plugins into my project: Sparkverb, Crystalline, and THX Spatial Creator. These plugins are undoubtedly legitimate.

6

The question wasn’t if they were “legitimate,” I was implicitly suggesting you check to see if disabling them stopped Cubase from crashing. You’re using an unsupported version of Cubase on an unsupported OS for that (unsupported) version. Saying the plugin is “legitimate” is subjective, while the process of disabling them all is objective.

7

Hi,

This crash is in Cubase. Not in any plug-in.

8

Well that’s disappointing. I mean, it’s disappointing that both the GPT-4o and o3-mini-high models determined the crash dump “strongly suggested a VST caused the crash.” o3-mini-high went so far as to say:

Functions like:

_retrieve_hrir
_add_one_ir
_make_hrir_with_reflections

are present, which indicates that one or more plugins were using HRIR (Head-Related Impulse Response) data. HRIR is used for simulating 3D audio by replicating how sound reaches each ear, contributing to spatial audio effects.

Which I found interesting given the THX plugin. While probably not great to hijack dude’s thread to turn it into a critique of how well AI does in analyzing a crash dump, I was kind of hoping it would have been more accurate. Since we’ve got unsupported apps on unsupported OSs, I was expecting it would have been a more valuable tool to help folks in the absence of “official support.” Just a bit of a let-down.

Anyway, sorry for the side-channel content; was just hopeful there was a bigger opportunity here.

1 Like
9

Thank you both for your contributions.

I appreciate your insights on the ChatGPT solution.
Interestingly, upon testing ChatGPT myself by copy-paste the crash report, it correctly identified the issue as a macOS compatibility concern as Martin said.

But this occurred after I inquired it about compatibility between macOS Sequoia and Cubase 11, which it answered to me that there is a compatibility issue.

I am now contemplating whether this prompted the subsequent connected responses.

1 Like
10

Nah, please don’t be sorry for going the extra mile to tackle the issue. Au contraire, cheers, man!

I think it’s good to explore the AI tools we have to analyze what we got (crash dumps). It is not gonna be 100% accurate at all times, that’s for sure. However, details might come to light that point in the right direction.

To sum up: it’s worth it :wink:

1 Like
11

Interesting question. Take a look around - anything different in your studio…? Dimmed lights all of a sudden… might be AI taking over.
Yeah, you might be right about this result having something to do with your former inquiries. Creepy… but that’s exactly how AI works.

1 Like
12

Yeah, pretty interesting. 'Twer it me, I’d still try disabling the THX plugin just to see. The SB lads are the experts, but the crash being “in Cubase” doesn’t necessarily mean that the source wasn’t related to data it was expecting from the plugin. I mean, outside of what AI says, it’s curious that one of the last things it was doing before the crash was parsing HRIR data. May be worth a shot anyway.

1 Like
13

It is seems to me that ChatGPT is unequivocally confident.

This is his definitive answer:

Analysis of the Cubase 11 Crash Report on macOS 15 (Sequoia)

  1. Main Issue: Segmentation Fault (SIGSEGV)
    • The crash is caused by EXC_BAD_ACCESS (SIGSEGV), which means Cubase 11 tried to access an invalid memory address (0x0000000000000080).
    • This usually happens when software is not compatible with the system, resulting in memory allocation errors.
    • The KERN_INVALID_ADDRESS message confirms that Cubase 11 is trying to access a memory location that doesn’t exist or isn’t allowed in macOS 15.

  2. Compatibility Issue Confirmed
    • The error “mach_vm_allocate_kernel failed within call to vm_map_enter” suggests that Cubase 11 is trying to allocate memory in a way that macOS 15 doesn’t allow.
    • The crash happens in Thread 0 (Main Thread), which means it’s a critical failure in Cubase itself, not just a plugin issue.
    • Cubase 11 is not officially supported on macOS 15, so this type of crash is expected.

  3. Possible Solutions

A. Run Cubase 11 in Compatibility Mode

Try launching Cubase 11 with Rosetta 2 (if you have an Apple Silicon Mac):
1. Go to Applications → Cubase 11.app
2. Right-click → Get Info
3. Check “Open using Rosetta”
4. Restart and test again

B. Try Disabling Third-Party Plugins
1. Hold Shift + Option + Command while launching Cubase 11.
2. Select Disable all third-party plug-ins and see if it crashes.

C. Downgrade to a Compatible macOS Version
• Recommended: macOS 12 Monterey or macOS 13 Ventura (both officially supported for Cubase 11).
• If you want to keep using macOS 15, upgrading Cubase is the best option.

D. Upgrade to Cubase 14
• Cubase 11 is outdated and not built for macOS 15.
• Cubase 14 is officially supported on macOS 15 and will work without these crashes.

Conclusion

Your crashes are 100% due to macOS 15 incompatibility. The safest fix is upgrading to Cubase 14 or downgrading macOS. Running in Rosetta might help, but there’s no guarantee. Let me know what you want to try!

14

Hi,

I’m sorry, I don’t know, why chatGPT gives you this response.

Here, I can see, that the crash is in thread 0:

Crashed Thread:        0

And the thread 0 looks like this:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   Cubase 11                     	       0x104abc3b3 0x102f9d000 + 28439475
1   Cubase 11                     	       0x10458f7ec 0x102f9d000 + 23013356
2   Cubase 11                     	       0x1045990c2 0x102f9d000 + 23052482
3   Cubase 11                     	       0x104597f14 0x102f9d000 + 23047956
4   Cubase 11                     	       0x104597c51 0x102f9d000 + 23047249
5   Cubase 11                     	       0x104f2daa2 0x102f9d000 + 33098402
6   Cubase 11                     	       0x105111462 0x102f9d000 + 35079266

So on top of the thread, there is Cubase. Therefore Cubase is the one who crashed.

1 Like
15

Indeed. I believe I’m going to keep testing and tracking accuracy from my side (but not post about every time, of course :slight_smile: ). I think it’s worth the time to test, particularly if there may be a better model to use for crash dump analysis.

That’s a remarkably disparate response! Just to be sure, this is its response from the Cubase 11-2025-03-08-090545.ips file? That’s the only one I had. I mean, it doesn’t really matter at this point, but to get such dramatically different responses from the same crash dump file would be pretty concerning (to me, anyway).

16

The reason ChatGPT may have been mistaken is maybe due to copying and pasting from a different section of the file, possibly even the entire content. Verify if there was confusion stemming from this. I copied the section from the top down to “Thread 1”, inclusive. let us know if it changes the response accordingly.