At today’s gig, I was playing along and all the sudden, no sound. I looked over at my laptop and Cantabile has abruptly, abnormally ended without any exit/abend dialog box. It was just…gone.
I’ve had this happen only a small handful of times throughout the past few years, but never at a gig (that I can recall). Because we were in the middle of the set, I wasn’t able to capture the log file. I just restarted Cantabile and it ran flawlessly the rest of the evening.
So what are the “common” causes for Cantabile to end task and disappear while playing? I’m on build 4300, so I suppose it could be related to the technology platform update that Brad just released. Anyone else seen any weird behavior with the latest experimental build?
And yes, shame on me for playing live with a brand new build…
That happened to me a hand full of times during some gigs last year. I don’t remember if I emailed the logs. In my case, the laptop shut down.
It always did it while manually selecting a song on the setlist. Everytime, I scrambled to get back up. It even happened twice during a gig.
I may be wrong, but I think you will still have a crash log file for that date.
Thanks, Corky, for sharing your experience. I too recall having the “crash on song select” issue some time ago, but haven’t seen that in awhile.
This crash was weird. I was already a minute into the song and everything was working perfectly when all of the sudden the Cantabile Windows task spontaneously ended. Poof, gone. I’ll check to see if I can locate the log file, but I assume that when I restarted Cantabile, it created a new log that overwrote the previous. Also, I didn’t have to reboot the laptop, just restarting Cantabile restored full function.
In my (limited) defense of gigging with a new build, I practiced for several hours with build 4300 on Friday and gigged on Saturday without a trace of a problem. I suppose I should revert to 4225 or even 4220 to rule out the technology platform uplift as a root cause. The problem is, this crash is nearly impossible to replicate on demand.
Perhaps @brad can elaborate on the factors that could cause Cantabile to terminate without a crash dialog?
UPDATE: I didn’t find a crash log, or any log file timestamped on Sunday. I have logging currently disabled, but will reenable in case this happens again.
It’s not helpful now but there is a “previous” log file for these situations where a crash occurs but no crash report is generated. If it happens again at a show restart Cantabile to carry on with the set but when done the set and you have shut down Cantabile save the “previous” log file to a safe location before starting Cantabile again. Then we would have something to look at from Cantabile’s viewpoint. Sorry you got bit at a show, worst case issue for sure.
Thanks, Dave. What are the appropriate or suggested settings in the Diagnostics tab to log sufficient information for these types of crashes (which could occurs hours into a performance)?
This is the default diagnostic setup that Cantabile does I’m pretty sure. The extra logging options do cause some resource loading so use the advanced logging options in a non performance situation. And make sure crash dumps are turned on.
If Cantabile crashes without prompting to send a crash log it’s usually because of either:
A lower level driver crash
An exception that corrupts memory in a way that prevents the crash from being captured - the most common example of this is a stack overflow exception.
If you’re getting these kinds of crashes I’m happy to investigate but will require you to manually capture a crash report - as explained here.
Thank you, Brad and Dave. I set my Diagnostic defaults as Dave noted, with the exception of the crash dump option disabled. I also installed and enabled ProcDump on both laptops. If or when this issue recurs, I will send Brad the zipped dmp file(s).
Brad, I captured a crash dump using procdump after Cantabile spontaneously crashed mid-song. This has happened several times this week. Due to the file size, I am sharing the crash dump file on my Google Drive at this link:
Please let me know if this is what you need to analyze and identify the root cause. I am currently on build 4302, although this has occurred ever since 4300.
I had a look at the crash report and it’s showing the crash is in SampleTank. If you’re getting this crash repeatedly I’d like to see a few more crash reports and see if they’re all in the same place. You can upload them to me directly here.
One thing I did notice is you’re using quite a few plugins that are creating lots of threads - for a total of about 370 threads. You might want to consider reducing Cantabile’s audio thread count since it seems most of your plugins are all multi-threading anyway. Also, if you can control the thread count in any of those plugins you might want to consider that too.
Not that I think the thread count is the cause for this crash, but there’s an awful lot going on there.
Brad, thank you for the super-quick analysis of the crash dump. It is curious that SampleTank crashed, as I have used ST4 for years without issues until just recently. ST4 hasn’t been updated in at least 3-4 months.
I have rolled back to stable build 4220 to rule out the tech platform update as a cause.
Regarding your suggestion to reduce Cantabile’s audio thread count, how exactly would I go about doing that? Are there audio engine settings that would help reduce the thread count? I am open to trying anything within reason, although this basic setup, including racks and songs, has remained pretty stable over the past year or so without issue until this latest crashing issue.
UPDATE: I played two gigs this weekend on build 4220 with no crashing and no issues. I will revert back to build 4302 this week in an attempt to capture another crash dump.
Let me know how things go after rolling back to 4220. I’d be particularly interested if you find any difference between 42xx and 43xx.
Cantabile’s audio engine thread count can be controlled in Tools → Options → Audio Engine → Number of Audio Threads. The most efficient setting for this 1 (ie: single threaded) as it removes the need to synchronize threads - but you lose the extra processing power of the other cores. That said, in your case looks like your plugins are all trying to leverage the extra cores anyway.
Brad, I uploaded another crash dump from build 4302 that just occurred this morning, this time on a different (my backup) laptop. Still Windows 11 24H2 and all libraries in identical locations. Please take a look when you have an opportunity and let me know which app crashed this time.
Also, at your suggestion I lowered the number of audio threads to 2 on this laptop hoping that it might make it more stable, but obviously that’s not the issue. That’s as low as I could go, as with 1 thread it was glitching.
Another day, another crash on build 4302. @Brad, I uploaded the crash dump file for your review.
Prior to today’s session, I had rescanned all of SampleTank library content, modified the SampleTank streaming options to back off the buffer setting to “medium” (instead of “large”), and reinstated a system-managed pagefile. Since my system has 64gb RAM I had disabled the Windows pagefile for performance reasons, but there are various opinions about this being a bad practice even with a lot of RAM.
If this is truly a SampleTank issue, I’m not sure I know where to go from here, besides reverting back to build 4220. However, that excludes me from any further updates if I am indeed stuck at that version for stability.
UPDATE: I had a crash on build 4220 this evening. Crash dump file has been uploaded. Looks like the 4300 series technology update may not be a factor in whatever is going on.
If it makes any difference, the SampleTank instance that keeps crashing is within an embedded rack (from a rack file) that is within a linked rack. I wonder if this “nesting” is creating an issue, as I don’t seem to have issues with just a SampleTank plugin within a linked rack?
Hi Bruce, Brad,
I reported ST4 issues here Crashes of SampleTank 4 without getting a real solution, you may read a bit of frustration.
My conclusion is that
Syntronic is ok
ST4 and Miroslav crash when having more than 1 instrument in the rack, typically when switching instrument, even when the different instruments are loaded into one ST4 instance.
My solution is
limit use of ST4
Use 1 instrument per rack
never ever use virtually linked racks with ST4
use VST2 instead of 3
Now I still have crashes loading a setlist with ST4 when I had that loaded before, second time it loads and runs???
I have the impression that crashing started around the time I wrote my first mail, but cannot make this hard.
By the way, I’d think that ST4 us a legacy product now with limited or no support from IK. I asked a few times support on this topic and never got an answer.
