Just to try and test the theory @cubace alluded to above with the amount of audio engine runtime thing, I did a little testing today before getting started with my session. Of course yesterday’s session had hung, so I started out with the normal “freeze” dialog box on startup. I got past that, then let Cubase 12.0.10 start while going away and doing a few other things. I was probably away from my computer for 15-20 minutes. When I got back, I played my project through once (on the order of 3 minutes), recreated my groove quantize setting from the drums track (one super annoying thing is that these hangs on shutdown don’t preserve that, so it has been reverting to a setting from the last song I worked on), then saved the project and shut down Cubase once the red close button was available. Hang! So this was after way less than an hour, probably less than a half hour, of runtime.
So it seems obvious that, even if the long session consideration alluded to is always an issue that can lead to this hang on shutdown, it is not a required catalyst (since my session was nowhere near the amount of time needed to trigger that specific issue).
Next I decided to try one other thing I’d seen alluded to by some others with respect to this problem. Specifically, I’d seen some mention issues in a multi-monitor setup when windows are left open on the non-primary monitor at the time of closing a session. The mentions I’d seen seemed to involve some virtual instruments or plugins, and I did not have any of those open on my second monitor. Rather, I had the MixConsole and the Markers window up. It’s possible I may also have had the Quantization settings up since I’d tweaked those again after getting back into my session. I think I again saved the project, then I shut down Cubase. No hang this time. This would have been a much shorter time between starting Cubase and closing it than the previous time, though – almost certainly less than 10 minutes.
So now I wanted to try opening some second monitor windows again and closing the project. I opened the MixConsole and Marker windows. I think I also opened the quantization window at one point, but I noted that was always on top (i.e. it didn’t go behind the MixConsole window when selecting the MixConsole window), so I closed that. I didn’t think I’d actually made any changes to the project (apparently wrong, as Cubase prompted me to save the project on shutting down), so I didn’t save it when closing Cubase. Again, no hang.
Opening Cubase again, I noted that it did not open the MixConsole or Marker windows (I guess, “duh!” since I hadn’t saved the project), so I opened them again, this time did save the project, then shut down Cubase again. Again no hang.
Opening Cubase again after that, the extra monitor windows were back. Hmm, could it be that the project had to be both started and closed with the windows open to trigger this? The short of it is that I’ve done the same opening with extra monitor windows open at least 3 times since then, a few times with playing parts of the project and or trying some other experiments in between, and, so far, it has not hung on shutting down again.
This is obviously not to say it won’t do that at the end of my session late tonight. In fact, based on similar experiments this past week, I strongly suspect it will hang tonight. Thus, I have no clue whether this experimentation actually tells me (or anyone else) anything. But perhaps there is some connection to what happened in the previous session, not just the session in question??? For example, maybe if it hung and had to be killed with task manager on the previous session, plus there was some other necessary condition (windows open on a second monitor, something else???), this audio engine runtime counter (if it really is involved in the hangs on shutdown) doesn’t get cleared (e.g. maybe there’s some reference to the previous value made at the start of the session and a corrupted value from that session already starts things off on a bad foot), and that somehow also gets combined with the value from the current session, only needing one of the conditions (i.e. corrupted previous session value or overflowing a samples processed counter) to cause the situation, but a short previous session, even with a crash, then a current session that doesn’t overflow the value, gets past it and everything is cool until the next long session??? (Yeah, this is a totally wild guess, so probably unlikely, but for entertainment value???)