Cubase 12.0.60 hanging more frequently on exit

For various reasons related to timing and schedule, I hadn’t been using Cubase Pro 12.0.60 (on Windows 10 Pro, fully updated) much until recently. Recent versions had pretty much done away with the hanging on exit that I experienced frequently in some early early versions of Cubase 12, but it seems like the more frequent hang is back, as I’ve had a couple of recent hangs after sessions of several hours (e.g. about 4.5 hours yesterday).

The specific scenario seems to be that I close the project first, then wait for the Windows close button to turn red when I hover over it, then try closing that, but it hangs. Yesterday I took a procdump after it had hung for some non-trivial number of (I’d guess at least 10) minutes. The DMP file (inside a ZIP file) can be found at:

I also did a quick analysis of this in WinDbg Preview, and it shows the following:


Microsoft (R) Windows Debugger Version 10.0.25200.1003 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\Rick\Downloads\Procdump\Cubase12.exe_230518_161544.dmp]
Comment: '
*** procdump64  -e -h -t Cubase12
*** Hung window detected: b05bc'
User Mini Dump File: Only registers, stack and portions of memory are available


************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
Symbol search path is: srv*
Executable search path is: 
Windows 10 Version 19045 MP (12 procs) Free x64
Product: WinNt, suite: SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Debug session time: Thu May 18 16:16:00.000 2023 (UTC - 7:00)
System Uptime: not available
Process Uptime: 0 days 4:32:25.000
................................................................
................................................................
................................................................
..............................................
Loading unloaded module list
................................................................
For analysis of this file, run !analyze -v
ntdll!NtWaitForAlertByThreadId+0x14:
00007ffa`10b30a74 c3              ret
0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

*** WARNING: Unable to verify checksum for WavesLib1_14.12.102_Win64.dll

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 8733

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 59613

    Key  : Analysis.IO.Other.Mb
    Value: 24

    Key  : Analysis.IO.Read.Mb
    Value: 1

    Key  : Analysis.IO.Write.Mb
    Value: 45

    Key  : Analysis.Init.CPU.mSec
    Value: 203

    Key  : Analysis.Init.Elapsed.mSec
    Value: 7021

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 633

    Key  : Timeline.Process.Start.DeltaSec
    Value: 16345

    Key  : WER.OS.Branch
    Value: vb_release

    Key  : WER.OS.Timestamp
    Value: 2019-12-06T14:06:00Z

    Key  : WER.OS.Version
    Value: 10.0.19041.1

    Key  : WER.Process.Version
    Value: 12.0.60.453


FILE_IN_CAB:  Cubase12.exe_230518_161544.dmp

COMMENT:  
*** procdump64  -e -h -t Cubase12
*** Hung window detected: b05bc

NTGLOBALFLAG:  0

PROCESS_BAM_CURRENT_THROTTLED: 0

PROCESS_BAM_PREVIOUS_THROTTLED: 0

APPLICATION_VERIFIER_FLAGS:  0

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 0000000000000000
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 0

FAULTING_THREAD:  00000c58

PROCESS_NAME:  Cubase12.exe

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE_STR:  80000003

STACK_TEXT:  
00000000`0014f3a8 00007ffa`10af38ad     : 00000000`0014f414 00000000`00000000 00000000`0014f670 00000000`16352d97 : ntdll!NtWaitForAlertByThreadId+0x14
00000000`0014f3b0 00007ffa`10af3762     : 00000000`00000000 00000000`00000000 00000000`0014f498 00000000`005a02c8 : ntdll!RtlpWaitOnAddressWithTimeout+0x81
00000000`0014f3e0 00007ffa`10af357d     : 00000000`005a02c0 00000000`00001722 00000000`00000000 00000000`00000000 : ntdll!RtlpWaitOnAddress+0xae
00000000`0014f450 00007ffa`10abfcb4     : 00000000`0014f608 00007ff9`00000008 00000000`fffffffa 00007ff9`d96f95a0 : ntdll!RtlpWaitOnCriticalSection+0xfd
00000000`0014f530 00007ffa`10abfae2     : 00000000`0000000c 00000000`00000090 00000000`005a0000 00000000`16351357 : ntdll!RtlpEnterCriticalSectionContended+0x1c4
00000000`0014f590 00007ffa`10ab5d87     : 00000000`00000002 00000000`0000000c 00000000`163f0b30 00000000`00050dfc : ntdll!RtlEnterCriticalSection+0x42
00000000`0014f5c0 00007ffa`10ab5b74     : 00000000`005a0000 00000000`005a0000 00000000`e9ff4d30 00000000`005a0000 : ntdll!RtlpFreeHeap+0x187
00000000`0014f770 00007ffa`10ab47b1     : 00000000`005a0000 00000000`005a0000 00000000`0000000b 00000000`00800000 : ntdll!RtlpFreeHeapInternal+0x464
00000000`0014f830 00007ffa`10a944af     : 00000000`e9ff4d40 00000000`004d0000 ffff0000`ffff0101 00000000`16351300 : ntdll!RtlFreeHeap+0x51
00000000`0014f870 00007ffa`10ab0f01     : 00000000`004d0270 00000000`00001000 00000000`00000001 00000000`ea035000 : ntdll!RtlpFreeUserBlockToHeap+0x2b
00000000`0014f8b0 00007ffa`10b3721f     : 00000000`000402c0 00000000`8cce7280 00000000`00000000 00000000`005a0000 : ntdll!RtlpFreeUserBlock+0x125
00000000`0014f900 00007ffa`10ab47b1     : 00000000`004da5c0 00000000`005a0000 00000000`00000000 00000000`00000000 : ntdll!RtlpFreeHeapInternal+0x81b0f
00000000`0014f9c0 00007ffa`0e39f05b     : 00000000`0000000c 00000000`1f7cf7a0 00000000`00000000 00007ffa`10ab5ba1 : ntdll!RtlFreeHeap+0x51
00000000`0014fa00 00000000`051c1e83     : 00000000`00640090 00000000`00000000 00000000`00000000 00000000`00000000 : ucrtbase!_free_base+0x1b
00000000`0014fa30 00000000`0519bf72     : 00000000`02512c40 00000000`1f7cf7a0 00000000`0000000c 00000000`1f7cf7a0 : baios!ExitDll+0x10d93
00000000`0014fa60 00000000`051a1014     : 00000000`1f7cf6e0 00000000`00000000 00000000`00000001 00000000`00000000 : baios!GetPluginFactory+0x1c12
00000000`0014fac0 00000000`051b4374     : 00000001`2ceabd18 00000000`00000000 00000000`00000000 00000000`00000000 : baios!GetPluginFactory+0x6cb4
00000000`0014faf0 00000000`05196097     : 00000001`2ceabd18 00000000`00000000 00000000`00000000 00000000`00000000 : baios!ExitDll+0x3284
00000000`0014fb20 00000000`0522b856     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : baios+0x6097
00000000`0014fb50 00000000`051985ad     : 00000001`2ceabd18 00000000`00000008 00000000`00000000 00000000`05196080 : baios!ExitDll+0x7a766
00000000`0014fbb0 00000000`051a9461     : 00000001`25e519b8 00000000`00000001 00000000`1f7cf7c8 00000000`00000000 : baios+0x85ad
00000000`0014fbe0 00000000`051a6d2e     : 00000001`25e519a0 00000001`25e519a0 00000001`25e519b8 00000000`1f7cf6e0 : baios!GetPluginFactory+0xf101
00000000`0014fc10 00000000`051a783d     : 00000001`25e519a0 00000000`1f7cf6e0 00000000`00000001 00000000`1f7cf6e0 : baios!GetPluginFactory+0xc9ce
00000000`0014fc70 00000001`41c61b4d     : 00000000`0ec7eb00 00000000`0014fe49 00000000`00000000 00000000`00000000 : baios!GetPluginFactory+0xd4dd
00000000`0014fca0 00000001`42a7ec23     : 00000000`0571b1e0 00000000`0571b1e0 00000000`00000000 00000000`0000000e : Cubase12+0x1c61b4d
00000000`0014fcd0 00000001`4260b10c     : 00000000`00000001 00000001`207ffbf0 00000000`00620d90 00000000`0014fd48 : Cubase12+0x2a7ec23
00000000`0014fd40 00000001`4316d799     : 00000000`00620d90 00000000`00000000 00000000`00000001 00000000`00000000 : Cubase12+0x260b10c
00000000`0014fd80 00000001`4319dab4     : 00000000`00620d90 00000000`00620d90 00000001`45484d50 00000000`00620d90 : Cubase12+0x316d799
00000000`0014fdb0 00000001`4316cd94     : 00000000`00620d90 00000000`00000000 00000000`006306b0 00000000`00620ff0 : Cubase12+0x319dab4
00000000`0014fde0 00000001`4316f456     : 00000000`00620d90 00000000`0014feb0 00000001`40000000 00000000`00000000 : Cubase12+0x316cd94
00000000`0014feb0 00000001`44087cf6     : 00000000`00000001 00000000`00000000 00000000`00000000 00000000`00000000 : Cubase12+0x316f456
00000000`0014fef0 00007ffa`0fa47614     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Cubase12+0x4087cf6
00000000`0014ff30 00007ffa`10ae26a1     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x14
00000000`0014ff60 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21


STACK_COMMAND:  ~0s; .ecxr ; kb

SYMBOL_NAME:  ucrtbase!_free_base+1b

MODULE_NAME: ucrtbase

IMAGE_NAME:  ucrtbase.dll

FAILURE_BUCKET_ID:  BREAKPOINT_80000003_ucrtbase.dll!_free_base

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

IMAGE_VERSION:  6.2.19041.789

FAILURE_ID_HASH:  {1cb0c0ae-8318-003b-1bfc-f43e8699e195}

Followup:     MachineOwner
---------


Prior to killing the process (and also prior to taking the procdump), I checked in TaskManager to see what it was showing, and here is the result:

It may be worth noting that the project was running at 96 kHz (since I know there was some earlier Cubase 12 issue where the sample rate and time spent in Cubase apparently mattered with respect to likelihood of hang). In this case, though all the Microsoft Edge WebView2 processes seem to be a new thing (or at least I hadn’t seen them previously as Cubase subprocesses).

Hi,

Please make sure your plug-ins are up to date.

I’m pretty sure my plugins should be up to date. I check for updates pretty frequently and update whatever needs it at the time.

I have the same problem

Hello, I started to use Cubase with version 9 and it has always worked fine except this hanging problem. Then this problem almost disappeared maybe with Cubase 10 or 10.5 (I’m not sure).
And with Cubase 12… it’s back.

The scenario (several times a week) is like yours: I close the project then I hit the red Windows cross and nothing happens until I kill the task

OR (new case with Cubase 12)

all seems to be fine but when (for example the next day) I launch Cubase again, I see that it didn’t close correctly the time before…
Otherwise Cubase works well, so it’s not really serious but somewhat annoying.

I think that third-party plugins are faulty, because that often happens with some projects and not others. It seems that some plugins doesn’t clean up memory upon closing…
I have noticed that the following manufacturers are very often present in my “faulty” projects :
ToneBoosters (TB Barricade)
AIR Music Technology (great plugins but that sometimes freeze some projects).

My audio interface is a Roland QUAD-CAPTURE (see complete configuration by clicking on my nickname).

I hope that helps.

I believe I started with Cubase at 9.5, but only started using it as my main DAW for new projects around 10.5. I don’t recall having many hangs on exit in those earlier versions, but I did start seeing it with Cubase 11, especially in the case of Waves Nx series plugins (e.g. Abbey Road Studio 3, Ocean Way Nashville, CLA Nx) being live prior to Waves’ adding the ability to turn the head tracking off by default. Once I could do that, the hangs on exit became pretty rare, so I was attributing them to the extra (outside of Cubase) Window those plugins put up for head tracking (which I wasn’t using anyway for lack of appropriate hardware).

The hangs on exit came back big time in some of the early versions of Cubase 12. I don’t recall now if it was the first (.0) release or .10 or .20, but then it became regular. There was a theory (I think later proven correct) at the time, that there was some sort of counter (sample counter maybe?) inside Cubase that should have been a 64-bit variable but was only a 32-bit variable), and higher sample rates (I almost always use 96-bit) would see the issue earlier, while longer sessions could almost guarantee it with high sample rates. This issue got fixed at some point (.30 or .40 maybe?).

I haven’t used Cubase Pro 12.0.60 sufficiently yet to be sure of a pattern. However, I can say I had a pretty long session yesterday where I did not experience it. Just thinking about it now, though, it is possible I broke that session down into two separate sessions due to some other weird thing I was experiencing with getting sound from a specific track.

I have seen this one, with freezdump.dmp files created frequently with two specific plugins, and only for the first load after a reboot. The two plugins are Kontakt (both 6 and 7 had this issue – not sure about earlier versions as I was already using Kontakt 6 by the time Cubase 12 came around) and Guitar Rig Pro. To date, I have not noticed it with other NI plugins. I think there is something there about the length of time those plugins take to initiate (possibly reading their libraries and large numbers of presets, respectively?) because that first load after a reboot takes an extraordinarily long time (even if loading Kontakt standalone), and Cubase seems to assume it has become non-responsive, though it eventually loads and works fine. In that case, the freezedump is essentially a false alarm. I was trying to look into this with NI, but nothing they suggested ended up changing it, nor seemingly led to any clues as to what made it happen. However, a Steinberg developer did mention the thing about the non-responsiveness and the “simple” mechanism used here. (I have a pretty slow system disk and many, many plugins, though my sample libraries are not loaded on that disk – the disk they are loaded on is of similar vintage, but doesn’t tend to get bottlenecedk like the system disk can.)

I don’t have that plugin, or any from that developer. In the project I had running recently, it was mainly Waves StudioRack plugins, with other plugins loaded inside those, plus Ozone and a PSP Audioware dither plugin, plus some IK tape emulation plugins. On the virtual instrument front it was a few instances of Kontakt, EasyDrummer 3, IK MODO Bass 2, and maybe an Acoustic Samples guitar library that runs under UVI. But most of the virtual instruments and plugins on those tracks were frozen at the time of the hang. I think there were only a few live plugins on group tracks.

I am pretty sure that the plugins that were live at the time were up to date. (I actually checked this morning to be safe.)

One additional note is that the WebView2 instances seem related to Waves StudioRack, at least when using it with StudioVerse (which I have been doing). I noticed this yesterday when inserting a new instance of StudioRack stereo, where there hadn’t been any instances of WebView2 in Task Manager ahead of that, but then inserting the instance created something like 3 instances.

1 Like

I also use many NI and Waves plugins. Kontakt and Kontakt Player are really really slow to load the first time in a session. It’s a well-known NI problem (even in standalone mode) that they attribute to some other programs like antivirus but I am not convinced.

At least on my system, the slow load of Kontakt (and Guitar Rig) is only the first time after rebooting the system. Thus, I am attributing it to needing to load whatever it is loading from disk, whereas after that it is likely cached in memory. It often takes upwards of 5 minutes on my system.

That said, some Waves plugins can also take multiple minutes to load on a first load (not just in Cubase, but also Cakewalk), though typically not as long as that first Kontakt load after rebooting.

it hangs on exit all the time. this happened since i bought cubase 10.
why and how is this still an issue? what is steinberg doing? unbelievable. jesus christ.

i use live as well and i NEVER had this issue. EVER. NOT ONCE.

This sounds like a problem with your antivirus, which is checking the files when loading them.
I had the same issue with windows defender.

An antivirus is never a good idea to run when working in a DAW.

@Tj99 Maybe, but…

First, I unfortunately cannot dedicate my system to DAW use, even though that is a fairly significant portion of my use. Thus, anti-virus is necessary, and I use the built-in Windows Defender, which is at least relatively low impact.

Second, I’ve expressly excluded the Cubase12.exe process in Windows Defender, which, if I understand it correctly, should mean that files Cubase loads (but not Cubase loading itself) should not get scanned in real time. I had not excluded “Kontakt 7.exe”, which I don’t think should be applicable when using Kontakt within Cubase, but I was curious to see how it might affect loading standalone Kontakt since it also loads extremely slowly the first time after rebooting. It did not help – we’re still talking multiple minutes.

Third, while Kontakt was loading, and I could see from Task Manager that my C: (system) disk was getting hammered, I went into Resource Monitor to check where the key impacts were in terms of total bytes per second. Most of those were from Kontakt (though also a few from Edge and the system). Here is a screen shot of the top portion of the Disk Activity screen:

It’s even reading Arturia and Applied Acoustic Systems data. Huh??? I could maybe see this if it was Komplete Kontrol, but within Kontakt?

Anyway, the bottom line is it just seems to be doing a lot of direct disk activity on my system drive, and that drive is genuinely relatively slow (I built my system back around 2014, I think). Once the disk activity calmed down and Kontakt started (quite a few minutes, but I lost track as it put up a dialog box for audio and MIDI settings so I didn’t realize it had finally come up as I was doing other things), I responded to that dialog, shut down Kontakt, and started it again. This time it took just a few seconds (less than 5, I think). So I’m pretty sure this relates to disk caching, with it having to actually read off hard disk the first time after a reboot, but being able to use data cached in memory on subsequent starts.

You can. Its basically about the real time protection feature, which is messing with DAW use. Check your system manually after every work day manually or automatically, to get around that.

Try to set C:\ entirely to the exluded paths, just to see if the issue is gone then.

SSD or HDD?
If HDD throw that away and get a SSD, as it is probably about to fail. And if not, HDD are not advisable for that kind of work anyway anymore.

Well, I want (need) the real-time protection feature since I am also using email and doing web stuff in parallel with working on Cubase projects. But, as my check this morning suggested, the disk throttling Kontakt was doing wasn’t about the virus protection. When that is going strong, its process shows up in the top disk consumers.

It is an HDD, and it checks out just fine with Crystal Disk Info. When I did have a validly failing HDD, a few years back that program helped me diagnose it. But this one is a slower disk than current models, and not an SSD, of course. Unfortunately, replacing it with an SSD is not in my budget in the near future, though I’m happy to accept donations. :slight_smile: I did replace the earlier failed HDD with an SSD as it was my audio drive (though even relocating project files temporarily to a more recent HDD worked temporarily to avoid the issue I was having at the time). At any rate, the Kontakt slow startup issue is really just a once-a-day (when I’m using it) annoyance since it is only on the first load after bootup.

There is a way to make Kontakt fast load. Guitar rig loads fast here. ill try to find a link just a sec:
Its called to batch resave the library after load. It does nothing other than instantiate a quick load of libraries. if you move the library or update kontakt etc., you will need to batch resave again, hope it helps :slight_smile: it did for me. :boom:

I remember seeing the batch resave idea in the past. I don’t recall if I tried it – I think it may have been too unwieldy for my situation – but, if I did, it didn’t help.

What eventually resolved the problem for me was, after old system hard disk failed, replacing it with an SSD. So, in essence, speeds loading the first time after booting are similar to what they’d be with the files already cached in memory. Despite the hard disk’s having passed CrystalDiskInfo tests in the past, I think it was on its way to failing, with a big symptom being degradation in speed over time.