Cubase 14.0.10 crash attempting to make WaveLab 12 ARA extension permanent

Cubase
, ,
1

Using Cubase Pro 14.0.10 today with WaveLab 12.0.51 as an ARA extension, I had multiple crashes when trying to make the extension permanent after using WaveLab’s Spectrogram editor to remove a few clicks in a vocal line. Unfortunately, none of the crashes produced a DMP file in CrashDumps, and, while some of Windows 10’s Event Viewer entries suggested a DMP file should have been produced in the WER (Windows Event Reporting, I think?) area, if they ever were, Windows must have removed them quickly, as all that was available there was a Report.wer file. (The forum software won’t let me upload that, nor a TXT file, so I’ve printed it from Notepad to a PDF file, attaching it as Report.wer.pdf in case it may be of any use. This was from the initial crash.)

Report.wer.pdf (44.3 KB)

The first time I tried this, I’d instantiated the extension on a slip-edited clip from comping some vocals, made a rectangular selection in the spectrum portion of the editor, then used audio inpainting to reduce the level of the selection. I repeated this for other clicks, maybe twice. I was doing this in the separate window. Going back to the main Cubase window, I tried making the extension permanent, and Cubase disappeared. The error entry in Event Viewer read:

Log Name: Application
Source: Application Error
Date: 1/10/2025 4:20:26 PM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: RP-Studio
Description:
Faulting application name: Cubase14.exe, version: 14.0.10.144, time stamp: 0x67449ebe
Faulting module name: ntdll.dll, version: 10.0.19041.5007, time stamp: 0x688f8c4b
Exception code: 0xc0000374
Fault offset: 0x00000000000ff3c9
Faulting process id: 0x4f24
Faulting application start time: 0x01db63a4d7a99083
Faulting application path: C:\Program Files\Steinberg\Cubase 14\Cubase14.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: 9cd69eaa-42a6-4f5e-9c29-247c0676f00f
Faulting package full name:
Faulting package-relative application ID:
Event Xml:



1000
0
2
100
0
0x80000000000000

105751


Application
RP-Studio



Cubase14.exe
14.0.10.144
67449ebe
ntdll.dll
10.0.19041.5007
688f8c4b
c0000374
00000000000ff3c9
4f24
01db63a4d7a99083
C:\Program Files\Steinberg\Cubase 14\Cubase14.exe
C:\WINDOWS\SYSTEM32\ntdll.dll
9cd69eaa-42a6-4f5e-9c29-247c0676f00f





Coming back to Cubase afterward, Cubase had saved a backup copy of the project, so I let it restore that. I think it was prior to having added the ARA extension. I tried again making the change as before, but this time, I saved a copy of the project with the extension in it after making the edits and prior to trying to make the extension permanent. When I did try, it got the same crash, with the same basic Event Log error.

Coming back to Cubase once more, the extension was there, but so were the clicks, so it wasn’t having the effect. I was able to remove the extension. I decided I need to try bouncing the clips in the vocal phrase I was working on to avoid WaveLab’s having to reference a region in a much larger tracking audio file, hoping it might be something related to that causing the crash. I put the extension on the bounced clip, made the edits, saved the file, then tried once more to make the extension permanent. Another crash with the same basic info.

Coming back into Cubase again, I played the clip again, but the clicks were still there, so the editing state had not been saved in the file. This time, though, when I tried to remove the extension, Cubase crashed, again with the same basic error.

Coming back to Cubase one last time, I was able to remove the extension this time (I think I didn’t attempt to go into the WaveLab editor or play back, so maybe that made a difference?). I again did the same sort of edits in the same sort of way, but this time, instead of trying to make the extension permanent, I just bounced the clip with the WaveLab changes, and that did work (and remove the extension as would be expected).

FWIW, my system is an Intel i7 5820k PC running latest Windows 10, with 16 GB RAM, a GeForce GTX 1050 2GB video adapter (running dual HD monitors), and a MOTU 828x audio interface (running on Thunderbolt II).

2

Hi,

Attach the source *.ips file, please.

3

Well, that would be difficult since I’m on a PC, not a Mac. :slight_smile: But, as I indicated above, no DMP files were created, so the only relevant information I could attach was the Report.wer file and the Event List entry.

That said, if you know of a way to try force the system to capture a DMP file when this happens, I’m open to seeing if I can recreate it again to do that. The thing is, though, this isn’t a hang situation, so I think the usual instructions to capture one in that scenario aren’t applicable here since the goal would be not to capture one immediately but to capture it at the point when the operation causes the application to crash.

It’s may be worth mentioning that, while this was a relatively simple project there were also plugins on the mono vocal track and downstream on a bus that were active. The vocal track and stereo bus behind that, the only other active track was a frozen piano track and, of course, the stereo out with both the piano track and bus feeding that. (There were also a few folder tracks containing disabled tracks, some for the vocals and some just MIDI tracks.)