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.)
 
 

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

abacab
After reading Noel's explanation, which sounds reasonable, it left me wondering about one thing.  I am not having any problems, and I have all of the Windows updates current through November 2016 for my version of Windows 10 (Version 1511; OS Build 10586.679).  Does this mean that maybe the condition only occurs on the Anniversary Edition of Windows 10, version 1607?

It is timing related so even with the same update you may or may not see the problem. Fortunately Bob's machine had a repro and that led us to the problem. That code has worked for years (decades) despite it being faulty so its definitely a recent environmental change that exposed the problem.
Bitflippers procmon test introduces a delay and circumvents the problem by the observer effect :)