I actually rolled back to the September edition.. Better but still acting up..

Interesting observation...or at least might be interesting to Noel & Co.
 
I ran Process Monitor to see if it might expose a clue as to what sonarplt.exe was doing at the moment of failure. To clean up the display, I set a number of filters so that only SONAR-related events were being logged. That took a few minutes. Then, with procmon running, I loaded CA-2A. No crash!
 
To see if this was a fluke, I repeated the test several times, rebooting between each try. In every instance, CA-2A did not trigger an exception as long as procmon was running. Without procmon running, I could consistently duplicate the crash by starting a new project and dragging CA-2A into an audio track.
 
Thinking maybe it was just that the time it took to set up procmon might be allowing some initialization process to complete, I rebooted, opened SONAR, started a new project and just let it sit there for 20 minutes. Dragged in CA-2A and crash! Every time.
 
There is a universal principle in science that you cannot measure anything without affecting the process you're measuring. Stick a voltmeter across a capacitor and you introduce a 10 megohm shunt that effects its time constant. Strap on a blood pressure cuff and a patient's blood pressure goes up. Check your tire pressure and you let some air out in the process. Check up on your kids and they're on their best behavior.
 
Process Monitor installs a kernel-level driver that intercepts system calls. Normally, this is completely transparent and most programs/processes have no idea they're being observed (although some installers actually check for procmon and refuse to proceed if it's running, because proprietary secrets could be revealed).
 
Usually, the only impact of procmon is a general slowdown due to the extra overhead of examining the thousands of events that are happening. Could this experience be revealing a race problem of some kind? (A race problem is a situation where a specific sequence of events - hardware or software - is crucial, but the actual order in which they occur cannot be guaranteed.)
 
 

regarding windows 10 updates, it's easy enough to see when they were installed, in control panel, "Installed Updates"

You're obviously on to something Dave. Too many moving parts to synchronise and the gears are getting jammed up. Given that all these things are happening at virtually the same time, what do you do? Add speed bumps to slow down the traffic?
These blue collar metaphors work for a civilian like me. 

Jesus....what a probably true but completely tripped out answer

This was all foretold. Just sayin' :)
Buckle up!

bitflipper
Interesting observation...or at least might be interesting to Noel & Co.
 
I ran Process Monitor to see if it might expose a clue as to what sonarplt.exe was doing at the moment of failure. To clean up the display, I set a number of filters so that only SONAR-related events were being logged. That took a few minutes. Then, with procmon running, I loaded CA-2A. No crash!
 
To see if this was a fluke, I repeated the test several times, rebooting between each try. In every instance, CA-2A did not trigger an exception as long as procmon was running. Without procmon running, I could consistently duplicate the crash by starting a new project and dragging CA-2A into an audio track.
 
Thinking maybe it was just that the time it took to set up procmon might be allowing some initialization process to complete, I rebooted, opened SONAR, started a new project and just let it sit there for 20 minutes. Dragged in CA-2A and crash! Every time.
 
There is a universal principle in science that you cannot measure anything without affecting the process you're measuring. Stick a voltmeter across a capacitor and you introduce a 10 megohm shunt that effects its time constant. Strap on a blood pressure cuff and a patient's blood pressure goes up. Check your tire pressure and you let some air out in the process. Check up on your kids and they're on their best behavior.
 
Process Monitor installs a kernel-level driver that intercepts system calls. Normally, this is completely transparent and most programs/processes have no idea they're being observed (although some installers actually check for procmon and refuse to proceed if it's running, because proprietary secrets could be revealed).
 
Usually, the only impact of procmon is a general slowdown due to the extra overhead of examining the thousands of events that are happening. Could this experience be revealing a race problem of some kind? (A race problem is a situation where a specific sequence of events - hardware or software - is crucial, but the actual order in which they occur cannot be guaranteed.)
 
 

It is indeed a race condition but not in SONAR but the plugins themselves. One that has existed for decades and got exposed by a new windows 10 update. We'll be posting some more information soon and are working on a fix. What is sure is that the 2010.11 update has nothing to do with this specific problem. i.e. rolling back SONAR will not help since the issue isn't in SONAR itself.

What Noel said :-)  And again, thanks to everyone here for helping out - it made all the difference.  Stay tuned.
~Bob

It always crashes with first launch. With the second launch, it works relatively stable.
But I noticed, after having started my Sibelius as first music software in a PC session, and, after closing it, then Sonar launches without crash. It should have to do with some engine both programs use - either with MIDI itself, of with the way VSt plugins are connected to their host programs (I have a handful of VSt working on both programs.) Maybe that helps in locating the bug. But I am hoping that thing could be hotfixed before next monthly update.

Problems are reported by Win 7 users. Problems seem related to CA-2A and Rapture Session.
I will have to see more information before I accept the VST+ Win 10 explanation.