Great insight! And a great way of troubleshooting.
Wouldn’t there be some notice of this in the crash reports?
When you think of a modern DAW ( and a huge one like Cubase with a staggeringly huge code base of various ages and probably approaches) with all the VST’s we load up doing God-knows what, it’s amazing the damn thing works at all!
Yes, I would think that the crash dumps would indeed provide some indication of where to start looking, but the problem with temporary files is that they could be gone before you can analyze them, and that you don’t really know what source application created them in the first place unless they have identifying data within the file itself, (only discernible by viewing in a hex editor or maybe a text editor sometimes).
I also think there’s an overall issue of “limited scope” in these kinds of discussions, which speaks to your “amazing it works at all” comment (which is really spot-on).
Let’s just take a simple example of loading a Kontakt library on one track with, say, a Kilohearts flanger insert and other track with a simple UVI Falcon synth. While it may sound simple, what’s really going on in the background is that upon load, NI actually instantiates “in-app” web framework objects to post web data to their “native-config” analytics site as well as to akamaiedge_dot_net to grab the library images, and of course licensing checks, and even downstream license checks if you’re using a 3rd party library. Even if you’ve purchased the stand-alone version of Kilohearts plug-ins, they still post a call every single time you load the project to their api to make sure you’re licensed and up-to-date. Then NI opens your pal.db to check out your configurations, and your favorites.db3 files (db3, db3-wal, db3-shm, etc) and actually uses localhost port connections for the SQLite daemon to read them. UVI Falcon not only loads your preset, but it also loads the associated ufs files from the Collection the preset is based on. You’ve got Cache.db updates going on in the background with a veritable maelstrom of temp file access spawning tertiary processes making their own temp files (e.g. SQLite). That’s not to mention what is happening within the Windows stack to support HTTP access for these processes, so “amazing” indeed!!
I would encourage the OP (an interested parties) to also just take a look at what’s going on in the background even outside of a VM testing environment. On MacOS one can launch “Activity Monitor,” search for “Cubase” and double-click the instance to then examine memory, stats, and “open files.” The Open Files and Ports tab gives us a detailed look into what is going on in the background. On Windows, you can do this in PerfMon (and I think TaskManager to a degree) but I personally would use Sysinternals Process Explorer (distinct from Sysinternals Process Monitor) though that can be a bit thick for the casual user. In fact, that approach may be as valuable as the VM environment, though I find VM-based solutions to be more valuable overall, particularly when testing apps and try-before-you-buy scenarios.
It may take a bit of effort, but I think it would be valuable. Who knows, one may find that running cleanmgr_dot_exe with a /sagerun:x flag on a schedule every night to clean out temp files could reduce (or even fix) the issue. But I would start with hard-data analysis first 'twer it I.
I have also worked with Cubase since Atari and from version 9 onwards, that was when the problems began, as you describe.
The problem in my case is surely Cubase, I have tried everything following the steps of the technical service and without a solution, now I am using other software and without problem.
I have opened Cubase with only the steinberg plugins and it also crashes when closing.