Dorico 4.3 often crashing on first document load/creation

[rickpaul]

I’m a very new Dorico Pro user (on Windows 10, fully updated), just starting with 4.3 a few weeks ago. I have noticed that Dorico will often crash the first time I try to either load a document or otherwise create a document, such as with the create function or loading a MusicXML file.

In today’s case, I’d started Dorico to get to the hub, then double-clicked on the document I’d been working on a few days ago. Dorico disappeared. Restarting it again and taking the same action, it loaded the document without incident.

The diagnostic report was too big to upload here (about 12 MB), but it can be downloaded at Dorico Diagnostics.zip - Google Drive.

A few other bits of information that may be worth noting: I’m just using the generic ASIO driver and my onboard soundcard and computer speakers so I can use Dorico without having to start my MOTU 828x interface and studio monitors. When Dorico starts, it takes a very long time to start the audio engine. Sometimes it also takes a long time (or even hangs) sitting at a notification mentioning silk service and ping response (I don’t recall the exact wording at the moment).

Once Dorico does successfully load a document, it seems stable thereafter. It is just the first load/creation of a document that seems to sometimes have issues. It is possible, too, that going into the audio/MIDI preferences prior to loading a document may avoid the crash as I think there was one time where I’d gotten a bunch of crashes of this type in a row then tried the preference changes and was able to load or create a document after that. (But maybe there was some other form of coincidence working there.)

[dspreadbury]

Thanks for the diagnostics, Rick. I’m looking into them and will report back here with anything I learn.

[rickpaul]

Hi Daniel, in case it is of any additional use, I’ve uploaded another diagnostics file today at Dorico Diagnostics, 2022-12-09.zip - Google Drive. This time it is from Dorico 4.3.11.1117 (earlier file was from the original 4.3 release).

All I did today was double-click on my “.dorico” project file in File Manager, then it took a long time for Dorico to start the audio engine, and it again got some kind of message about a ping response from silk service, then it disappeared. After that, I started Dorico the exact same way – i.e. double clicking on the same file, and, while it still took a while to for the audio engine to start (but nowhere near as long as the previous time, which was my first time loading it after booting up my system for the day), it came up fine including with the project loaded. The DMP file shows an access violation (guessing that the same as before).

[dspreadbury]

Thanks for the updated diagnostics. It does appear that for some reason it’s taking a long time to initialise the audio engine on your system. Dorico is supposed to wait for the audio engine initialisation to be complete before it starts opening a project, but it appears that it is possible for this not to be the case.

To avoid this problem for the time being, please try running Dorico up to the Hub before you open your project, so start Dorico by double-clicking its own icon rather than double-clicking your project file. Once the Hub appears, that should for certain mean that the audio engine has been initialised. I’d be interested to know if you can make the problem recur if you open your project from the Hub rather than by opening Dorico by double-clicking your project in the Windows shell.

[rickpaul]

@dspreadbury

To avoid this problem for the time being, please try running Dorico up to the Hub before you open your project, so start Dorico by double-clicking its own icon rather than double-clicking your project file. Once the Hub appears, that should for certain mean that the audio engine has been initialised. I’d be interested to know if you can make the problem recur if you open your project from the Hub rather than by opening Dorico by double-clicking your project in the Windows shell.

Thanks, Daniel. Just to clarify, the first diagnostic report I sent was from a time where I opened the project from the Hub. This latest one is from having double-clicked on it in File Manager. So the symptom is the same, either way. Also, opening from the Hub on a second start does seem to work okay, just like double-clicking on the file in File Manager after that first crashed start.

Sometimes when I’ve watched the start more closely, I think I saw that the graph on loading the project gets to about 92% by the point at which Dorico crashed.

I’m not sure if the number of plugins on a system affects the time it takes for the audio engine to start, but I do have a pretty huge number of plugins. Also, my system disk is a SATA hard drive from around 2014 that, while in good condition according to reliability tests, is slower than equivalent current models, no less SSDs. Cubase also takes a very long time to start the first time after a boot (where everything would be loading from disk instead of disk cache), mostly sitting in the VST3 scanning window in terms of where the most time is spent. Even on secondary loads (i.e. after closing a session then restarting the program) Cubase will often take 10-12 minutes to start and load a project. I know some plugins take an extraordinarily long time to go through their authorizations, especially NI Kontakt and Guitar Rig and some Waves plugins (at least when they are the initial plugins in a specific product group to be loaded/authorized). I mention all this just in case it may somehow be relevant.

At least lately, the crashing seems to be limited to the first start. When I first tried Dorico SE, that did not seem to be the case, and my “workaround” was to go into the device configuration and bring up audio interface properties (or something of that sort – I may not be remembering specifics correctly), which perhaps, based on your note here, gave the audio engine more time to start or something.

[Ulf]

Hi @rickpaul , I think indeed the plug-in scanning is the problem with you. First of all, yes, you have tons of VST plug-ins, on the other hand, not that many that Dorico would not be able to handle it. But what I see in the log, that there is always a gap between the VST2 plug-in scanning finishing and the begin of the VST3 plugs scanning. The gap is not always equal, but I saw runs with a gap between 2 and 20 (!) minutes. And to be honest, I don’t know what the audio engine is doing at that time.
Well, could it be that some plug-in is popping up an alert window that simply gets hidden behind the Dorico splash-screen? While starting up Dorico, do hover with the mouse over the Dorico icon in the Taskbar, little preview windows(s) shall be seen. Is there maybe some alert box to be seen? If so, bring it to the front by clicking on the preview window.
Additionally I want to mention, you have lots of VST2 plug-ins of which you apparently only use Kontakt5 and 6, at least only them are on the VST2 whitelist. But you also have Kontakt 7 which is VST3. So I think you don’t need Kontakt 5 or 6 and thus could simply empty out all VST2 search paths in the Dorico Preferences (Edit > Preferences) and by that completely bypassing the VST2 scanning. This alone already should speed up the overall scanning time. You could even just try it out and later put back the VST2 search paths, but it is definitely worth a try.
Let me know how it goes and I maybe can come up with even more suggestions.

[rickpaul]

Thanks, Ulf. I tried the hovering over the Dorico icon on the task bar while the splash screen was showing, and I did not see anything other than the Dorico 4 tool tip. I tried it twice, once being the first time after boot (see more on this below), and the second time shortly after that, resulting in the usually “working as intended” behavior.

The first time, I just brought Dorico up to the hub then went into edit/preferences/VST-plugins, with the idea of checking the VST2 paths that were there (to see what plugins were in each directory) and (ultimately) to remove all those paths. (I have no need for any VST2 plugins in Dorico, and I’d actually thought about clearing that before. In most cases, I don’t have need for them in Cubase, either, but there I have to be careful as there are still some I use frequently because there are not yet VST3 equivalents – e.g. some of the UJAM products, various PSP Audioware plugins, etc. – I do need to keep many/most of them on my system, though, due to compatibility with historical Cakewalk SONAR projects using them and the potential need to remix those and be able to reference certain settings). Dorico crashed shortly after my pressing the VST-plugins button. In case it is any different from the last round on the DMP file inside it (still an access violation), I’ve uploaded another Dorico Diagnostics file to Dorico Diagnostics, 2022-12-10.zip - Google Drive.

As for whether having removed the VST plugin paths will make a difference or not, I’ll need to wait until I can reboot the computer (probably overnight) before I can check since this only seems to happen on the first start after reboot. I’ll report back on that once I’ve had a chance to check it.

One other thing that might be worth noting is that Cubase 12 also has one specific issue the first time after a reboot, specifically when loading either Kontakt 7 (or 6, but it still happens with 7) or Guitar Rig 6 in a project. There is no crash of Cubase, and the plugins work fine once they load, but they take a very long time (upwards of 2 minutes) to show up, and Cubase does produce a freezedump.dmp file. (These have been sent frequently to Steinberg due to the automatic prompting on that on starting Cubase 12.) I started a thread on that in the Cubase forum at Freezedump on loading Cubase 12 projects with Kontakt. I was advised to contact NI on that, and I did. They put in a good deal of effort looking into it and having me try various things and report back, but, at least thus far, there has been no verdict, and I think they may have given up in that it’s been well over a week since I last heard from them. My own theory on this is that there is something about the inordinate amount of time the loading is taking, possibly relating to authorization checks, that makes Cubase think the plugin has frozen when it is just taking a very long time. Or perhaps there is some VST3 protocol that those two plugins aren’t quite getting right (because the one time I observed this part in File Manager, the freezedump actually happened quite quickly, while the loading took much longer). I don’t think it is an NI-wide issue because I also tried a test using Massive X as the first NI plugin to be loaded after rebooting, and it did not generate the freezedump. My suggestion to NI was to check with Steinberg as to what causes freezedump files to be generated, for example in case there was indeed some VST3 protocol issue. But this issue may also be specific to my system as no one replied to my post in the Cubase forum that was mainly asking if others were seeing this issue.

[Ulf]

Hi @rickpaul, there is nothing special behind the Cubase freezedumps in the sense that it is a very simple mechanism. Whenever Cubase’s main thread is stuck or blocked for a certain amount of time then a freezedump gets automatically created. I don’t even know the time that is waited, but you see, it is a dead simple and stupid approach: Cubase appearing to be frozen for some time => create a dump file. On the other hand, we have to be careful here and not talk about crashing in this instance, because Cubase is still running, it’s just not responding anymore (or for a very long time), but strictly technically spoken, it is up and running.
Now, the Dorico diagnostics don’t show any freeze dumps, so I would like you to create a few manually while starting up Dorico. Therefore please download the free utility Process Explorer. Start it up and look in the list for a process called VSTAudioEngine. When you highlight that process and do a right click on it, from a pop-up menu you can do ‘Create > Create Mini Dump’. While Dorico is starting up, please create several of these mini dumps, zip them up and provide them to me. I want to see where it is hanging and if it is always the same location. Than you very much .

[rickpaul]

Thanks for the help, Ulf. Here are the additional results of the testing you’ve requested.

First, the VST2 path removals yesterday did not make a difference on first startup after booting today. To give some idea of the sequence on startup that first time, I started Dorico at 7:51 AM on the Windows clock. It ran through a number of status items then was at the audio engine initialization status fairly shortly after that time stamp. The next change I noted in the status items was the switch to “ping response received: from silk service” around 7:58 (it may have appeared a minute or so earlier, but this is when I noticed it). At some point between this time and the crash, I noticed a task bar icon for PCPushNotify that was there long enough for me to notice, but eventually disappeared. I’m not sure what this is from, and it may be something completely coincidental. While the ping response prompt was up, I also looked at Task Manager in the performance area, and I could see my C: drive (system drive, where applications and plugins reside) was showing 100% bandwidth use. (This is actually fairly common when plugins are being scanned.) I also noticed in Task Manager’s process area that there were three tasks starting with VST, one being the one you VSTAudioEngine5 and the others starting with VST3 and then something with “scan” in it (I did not take a screenshot, and I don’t remember if the names were the same or slightly different). At 8:06 AM, I noticed another task bar entry that did not have an icon or name, but hovering over it I noticed that it was Dorico’s file loading meter, which showed it at the 92% mark. (I probably had other windows covering up the actually screen.) Still at that same timestamp, Dorico disappeared (crashed without an error message).

Note that I did not do the Process Explorer test on the first start as I wasn’t certain if taking the dumps might affect whether or not Dorico would crash on the first start after rebooting. I might also note that I was starting Dorico by double clicking on the file I’d been working on recently.

While I wasn’t certain if the minidumps you requested might be different on a second Dorico start after rebooting, I did take those on a second start (also double clicking on the file to start). You can find the dumps at Dorico startup minidumps, 2022-12-11.zip - Google Drive. Short summary is that all 10 mini dumps, taken between 8:13 AM and 8:17 AM, are virtually identical. I used Windbg Preview’s “analyze -v” command to get stack dumps of each file, putting them in text files, and a FC between the first and tenth file shows the only difference relate to times and file names. In all cases, the top of the stack shows “ntdll!NtWaitForSingleObject+0x14”. (I might note that this is the same as what is at the top of the stack on the Cubase freezedumps I mentioned for Kontakt and Guitar Rig – my having noticed that in the earlier Dorico DMP file analysis is what lead me to mention the Cubase freezedumps.)

A few additional things worth mentioning:

I’m guessing the first two items will be expected, but here is what the Dorico process tree looked lie in Process Explorer:

Also, when I was searching for VSTAudioEngine (which turns out to be VSTAudioEngine5), it found quite a number of occurrences:

The other thing was that, on this second start, at some point it put up an error screen that I’m not sure I’ve seen before (though I have seen it mentioned by others in this forum):

This screen stayed up for a while, then Dorico crashed again.

After this I loaded Dorico without double clicking on the file, and Dorico did load to the hub, and I was successful in loading the document from the hub. After that, I could also open Dorico by double clicking on the file after having shut it down.

With respect to the Cubase freezedumps, I understand they are not crashes, and I appreciate the explanation. Perhaps these are new to Cubase 12 because I do not recall having seen the startup issues (i.e. prompts to upload a DMP file) or so many DMP files accumulating in CrashDumps in Cubase 11, nor the long Kontakt load times, though it is possible I may just not be remembering correctly on the latter. (I haven’t used Cubase 11 since I started using Cubase 12.0.0.) The freezedumps are really just an annoyance in that I sometimes forget to wait to see if I will get a prompt, and I usually walk away to do other things while Cubase is starting up as the startup time is so long, and, when I forget to check, sometimes I come back to that prompt, meaning the long load time will come later, and I’ll actually have to wait. (And it truly is almost always from either Kontakt or Guitar Rig.)

[Ulf]

Hi @rickpaul , thank you so much for the tests and the extensive explanation. I will have a look at the minidumps tomorrow morning (Hamburg time).
But if that is true, that the minidumps look all the same, then it is most likely exactly the same as what you experience with Cubase, namely the app waiting for the VSTscanning to finish off. The scanning is part of our sentinel system and tries to load every available plug-in, perform some basic test on it and see if it is maybe unstable. If found not worthy it gets thrown onto the blacklist and the user will not be able to use it anymore.
Now, you saw the vstscanner process already in the Process Explorer.
I do not want to put too much stress on you, but would it be also possible that you make similar minidumps of the vstscanner process(es)?
That should show us in which plug-in it spends so much time.
Btw, the VSTScannerMaster process is not of interest here.
Thanks again for you effort, highly appreciated!

[rickpaul]

Thanks, Ulf, and no problem on the additional tests.

To clarify one thing first, the freezedumps in Cubase are not on plugin scanning. Rather, they are on the first load of a live (i.e. not frozen) instance of Kontakt or Guitar Rig in a Cubase project, and only the first time after rebooting. This load can be from a project with an active instance of Kontakt (or Guitar Rig), or it can be inserting a new instance of Kontakt (or Guitar Rig) in a project that did not have it (even an new/empty project).

Here are the additional minidumps you requested: Dorico VSTscanner Minidumps.zip - Google Drive.

A few notes:

These are from two separate cases where Dorico did not crash, and where it was starting fairly quickly (at least compared to what I’ve mostly seen). The reason there are two cases is that I had a hard time finding vstscanner in Process Explorer the first time, so it took a while to be able to get to a first minidump capture, and I was only able to get two.

Along the way (and also in the second case), I saw an error message:

I suspect this means that the specific process in question was shutting down or already finished by the time I got to it. There was also one other error message that I got a few times, but I did not get a chance to capture that, trying instead to maximize the number of minidumps I could capture.

What I saw in the Windbg Preview stack traces of all the cases I was able to capture were references to Waves, similar, but not always identical, to the top three items on this stack trace from the first minidump I was able to capture:

STACK_TEXT:  
00000000`0014b928 00007ffe`8065b03e     : 00000000`0014b9e8 00000000`00526250 00000000`00003a98 00000000`0014b984 : ntdll!NtDelayExecution+0x14
00000000`0014b930 00007ffe`193ebb3e     : 00000000`0052a028 00000000`00000000 00000000`c00000bb 00000000`00000000 : KERNELBASE!SleepEx+0x9e
00000000`0014b9d0 00007ffe`193afd34     : 00000000`02a0f150 00000000`00000000 00000000`0014c0a0 00009d4b`dc7a8f6a : WaveShell1_VST3_12_7_x64!wvWavesV12_7_0_216::WCSharedMem::openSharedMem+0x247e
00000000`0014be60 00007ffe`193afdaa     : 00000000`0014c170 00000000`00000000 00000000`0014c0a0 

However, the specific version of WaveShell varied, with the six instances in successive minidumps references as follows:

WaveShell1_VST3_12_7_x64
WaveShell1_VST3_12_7_x64
– end of first Dorico run captures –
WaveShell1_VST3_12_10_x64
WaveShell1_VST3_12_10_x64
WaveShell1_VST3_12_10_x64
WaveShell1_VST3_12_10_x64

That is both of the first run captures referenced WaveShell 12.7, while all of the second run captures referenced WaveSell 12.10. Perhaps this was just “luck of the draw” in terms of my timing in successfully capturing the dumps, especially given the issue I mentioned above about sometimes getting errors when I tried to capture a specific instance. (On the second run, I was refreshing the Process Explorer view between captures, hoping not to try capturing process that had already expired.)

I also do know that Waves plugins can sometimes take a very long time to instantiate within Cubase. For example, on a recent project, when I added Waves Tune RT, it took upwards of 2 minutes. I think this likely relates to authorizations (and I’ve seen others complain about this in the Cubase forum) as it is generally something that only happens on the first load of a Waves plugin within a given series that shares the same authorization. Then again, if some are using different versions of WaveShell from the others, that could also be a factor. (I do keep my Waves plugins updated.)

[Ulf]

Hi @rickpaul , thank you so much. But yes, I now definitely think that the Wave plug-ins are the culprits for the long startup times. What irritates me though is the fact that there are two version installed and both are somewhat active.
Now, how about if you move the WaveShell files temporarily out from C:\Program Files\CommonFiles\VST3 ? Let’s say you put them on your desktop and therefore out of view from Dorico. If you then start up Dorico, is it then still so slow?

[rickpaul]

Dorico started in roughly 3 minutes without the WaveShell plugins in the VST3 directory. I did not try just double-clicking on a document in File Manager this time, so this isn’t apples-to-apples with yesterday’s startups, but opening the document I’d been working on from the hub did not crash on this first startup after rebooting, either, so that may be hopeful, or maybe just “luck of the draw” since I’m not sure whether there may have been other times where it did not crash the first time opening a document after rebooting.

FWIW, here is a look at my Waves VST3 files:

If I’ve counted correctly, there are 19 of them! If each one further has to scan some number of specific plugins (I have MANY Waves plugins), that would certainly seem to explain long scanning times. (Side note is that Cakewalk explicitly shows what plugins it is scanning on startup, and I have noticed it enumerating multiple WaveShell scans at times when I’ve started it.) I guess it will be a question for Waves as to why there are so many versions on my system (all plugins in Waves Central show V14.0, though there would have been ones I initially acquired as far back as V12).

After adding the WaveShell files back into the VST3 directory, I started Dorico again, and it did not take as long as usual (of course, the other plugins would already be cached by that point), nor did it crash on loading the document from the hub.

One other thing to note: I looked at the VST preferences, where I’d previously deleted the paths, but they were back. I figured their return could signify either user error on my part (e.g. failing to press the Apply button) or some effect of an earlier crash that caused those preferences to be reset. Thus, I tried deleting all those paths again, hitting Apply the Close, closing Dorico, then restarting it. The paths were still there:

Since the prompt after hitting Apply says Dorico has to be restarted for the changes to take effect, this means my test of the other day (i.e. the crash after thinking I’d deleted the paths) was likely invalid. So at this point, I don’t know how to permanently remove the VST2 plugin paths.

[rickpaul]

One P.S. is that I found a function in Waves Central to uninstall old versions of the plugins (since I should not need anything other than V14 at this point – there was one V13 plugin still in my list, but I updated that to V14 first). This still left 7 V14.x instances of WaveShell in the VST3 directory, but at least that is a big improvement over 19 earlier. Starting Dorico after that took on the order of 2 minutes. (This was not the first time after rebooting, so it may be longer tomorrow morning.) But at least localizing the extremely long startup to WavesShell should provide a huge improvement on start time (hopefully in Cubase, too?), and I’ll have to check with Waves to see if there is some way to reduce the number of instances further.

The next start of Dorico after rebooting I can also try again to see if the crashing on first direct project load has come back or not.

[Ulf]

Sounds good so far. Lets keep fingers crossed…

[rickpaul]

BTW, I noted that there was a Dorico Freezedump.dmp file in my crashdump folder from today – it was not from the first start. Quick stack dump from it shows:

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


Loading Dump File [C:\Users\Rick\Documents\Steinberg\CrashDumps\Dorico 4 AudioEngine 5.5.0 64bit 2022.12.12 9.16.20.123-freezedump.dmp]
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: Mon Dec 12 09:16:40.000 2022 (UTC - 8:00)
System Uptime: not available
Process Uptime: 0 days 0:18:09.000
..........................
For analysis of this file, run !analyze -v
ntdll!NtFlushBuffersFile+0x14:
00007ffe`8798da24 c3              ret
0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

*** WARNING: Unable to verify checksum for asioglld.dll

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 5952

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 23896

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

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

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

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

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

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

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

    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: 5.5.0.67


FILE_IN_CAB:  Dorico 4 AudioEngine 5.5.0 64bit 2022.12.12 9.16.20.123-freezedump.dmp

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

FAULTING_THREAD:  00001ebc

PROCESS_NAME:  VSTAudioEngine5.exe

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

EXCEPTION_CODE_STR:  80000003

STACK_TEXT:  
00000000`0014f228 00007ffe`856d35bd     : 00000001`41288f8c 00000001`4062b17b 00000000`0014f3c0 00000001`40731d8b : ntdll!NtFlushBuffersFile+0x14
00000000`0014f230 00000001`407faf94     : 00000000`005906e0 00000001`41288f8c 00000000`00000004 00000000`00000006 : KERNELBASE!FlushFileBuffers+0x2d
00000000`0014f270 00000001`40617df7     : 00000001`4126f908 00000001`41288f8c 00000000`00000004 00000001`404e8ec4 : VSTAudioEngine5+0x7faf94
00000000`0014f2a0 00000001`4098060a     : 00000000`006305f8 00000000`0014f3a0 00000000`0544df48 00000000`06f3c480 : VSTAudioEngine5+0x617df7
00000000`0014f310 00000001`4077ab2f     : 00000000`0014f3c0 00000001`40731cb7 00000000`0014f3e0 00000000`00630570 : VSTAudioEngine5+0x98060a
00000000`0014f340 00000001`4097f877     : 00000000`00630570 00000000`00655d60 00000000`000609d8 00000000`0014f3f8 : VSTAudioEngine5+0x77ab2f
00000000`0014f380 00000001`40bd8fa8     : 00000000`0014f3c0 00000000`00604520 00000000`000fedc2 00000001`409805f0 : VSTAudioEngine5+0x97f877
00000000`0014f420 00000001`40c22f70     : 00000000`000609d8 00000000`00000000 00000000`00000113 00000000`00589c80 : VSTAudioEngine5+0xbd8fa8
00000000`0014f450 00000001`40c5457d     : 00000000`00000001 00000000`00000000 00000000`00000113 00000000`00000000 : VSTAudioEngine5+0xc22f70
00000000`0014f480 00000001`40f8881c     : 00000000`0014fa20 00000000`00000000 00000000`0063b938 00000000`00000000 : VSTAudioEngine5+0xc5457d
00000000`0014f990 00000001`40c503e7     : 00000000`0014fa20 20d81560`e8c4445a 00000000`00000000 00000000`0066c3c0 : VSTAudioEngine5+0xf8881c
00000000`0014f9c0 00000001`40c54971     : 00000000`00000113 20d81560`e8c4445a 00000000`000509da 00000000`00000000 : VSTAudioEngine5+0xc503e7
00000000`0014f9f0 00007ffe`869ee858     : 00000000`00000001 00000000`00000001 00000000`00000001 00000000`00000000 : VSTAudioEngine5+0xc54971
00000000`0014fa70 00007ffe`869ee299     : 00007ffe`8798d0a0 00000001`40c548a0 00000000`000609d8 00000000`00000113 : user32!UserCallWinProcCheckWow+0x2f8
00000000`0014fc00 00000001`40bd7605     : 00000001`40c548a0 00000000`00604560 00000000`005906e0 00000000`00604560 : user32!DispatchMessageWorker+0x249
00000000`0014fc80 00000001`40c22cbd     : 00000000`00630570 00000001`40c22af8 00000000`0014fc90 00000000`00000000 : VSTAudioEngine5+0xbd7605
00000000`0014fcb0 00000001`40c22b49     : 00000000`0de40000 00000000`00000000 00000000`00000000 00000000`00000007 : VSTAudioEngine5+0xc22cbd
00000000`0014fce0 00000001`4097dfda     : 00000000`00000005 00000000`005906e0 00000000`005906e0 00000000`0060e790 : VSTAudioEngine5+0xc22b49
00000000`0014fd10 00000001`40614ad3     : 00000000`005908c0 00000000`0060e790 00000000`00590860 00000000`005eb360 : VSTAudioEngine5+0x97dfda
00000000`0014fd50 00000001`40e3f7e2     : 00000000`005906e0 00000000`005908c0 00000000`0059c2c0 00000000`0059c2c0 : VSTAudioEngine5+0x614ad3
00000000`0014fef0 00007ffe`86e174b4     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : VSTAudioEngine5+0xe3f7e2
00000000`0014ff30 00007ffe`879426a1     : 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:  vstaudioengine5+7faf94

MODULE_NAME: VSTAudioEngine5

IMAGE_NAME:  VSTAudioEngine5.exe

FAILURE_BUCKET_ID:  BREAKPOINT_80000003_VSTAudioEngine5.exe!Unknown

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

IMAGE_VERSION:  5.5.0.67

FAILURE_ID_HASH:  {264e3d8d-225b-830d-5dc8-17d625167cfb}

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

Cubase definitely got to the project loading much faster than usual, too, though it may be that was helped by Dorico's already having effectively cached plugins (in addition to fewer Waves DLLs).

[Ulf]

Could you please post the complete dump file? Thanks

[rickpaul]

Sure, this one is small enough to attach here:

Dorico 4 AudioEngine 5.5.0 64bit 2022.12.12 9.16.20.123-freezedump.dmp (442.5 KB)

[Ulf]

Thanks for the dump file. It happened during idle handling while flushing data to the disk.
Now, I would not take the freezedumps too serious, at least not in this case. As I explained, just because some operation took a little longer than expected, it does not mean that it crashed or something bad happened. So let’s put this incident on the save side. But good that you keep always an eye on it.

[rickpaul]

Just to follow up after a reboot, so starting Dorico the first time after that and by just double-clicking on my document, it took on the order of 5 minutes to start (a big improvement from previously), and it did not crash but rather opened the document successfully (included in the startup time). Thus, while there may still be a question as to why Dorico had been crashing with all the additional WaveShell instances, getting rid of those appears to have resolved the issue on my system.

I still cannot get the removal of the VST2 paths to stick (I tried again this morning just in the odd case the reboot may have made a difference), but that is a different topic from this thread.