dantarbill
I managed to narrow down the likely culprit.  It appears to be related to the ancient ASIO driver for my M-Audio Firewire 1814 interface (running version 5.10.0.5058).  When I run in WASPI mode, the AAS stuff doesn't blow up the system (but then I have to run at at least 12 ms latency in order to get smooth audio).
Also...

• Set system to WASPI
• Instantiate a recent AAS synth (like Ultra Analog VA-2) in a project
• Verify that it works
• Close the project without saving it.
• Reopen the project (still with no AAS plug).
• Change the driver mode to ASIO
• Click on Apply
• Gets the same BSOD

It appears that the AAS plug has left the system in a state that pisses off the driver, even though the AAS code is no longer running.

That makes sense. ASIO runs in user mode and is susceptible to heap corruption or any other bad things that happen inside the app. If the plugin is corrupting memory in the right place it can conceivably indirectly cause a BSOD in the driver. Or it might not be related at all to the plugin if there is a bug in the driver.

paulo
...FWIW though, I have always found AAS support/customer service to be among the best, so if there is a significant delay in getting back to you I would say based on my experience that is unusual, so it might be worth checking that something hasn't gone wrong in the communication process. (IE did they get your message in the first place / did they already reply and you didn't get it for some reason?)

I eventually called them directly and got an instant response.  So far, I'm the only one reporting the problem.  I've also forwarded them the post I did here yesterday (04/21/18).


There are some other tests that I might try here...which would include running the same M-Audio interface on a Win10 laptop and a slightly older version of SPlat (2017.06).

Noel Borthwick [Cakewalk]

dantarbill
<stuff>

That makes sense. ASIO runs in user mode and is susceptible to heap corruption or any other bad things that happen inside the app. If the plugin is corrupting memory in the right place it can conceivably indirectly cause a BSOD in the driver. Or it might not be related at all to the plugin if there is a bug in the driver.

I tried running the same M-Audio Firewire interface (with ASIO) on a laptop with a different OS build (Win10 Pro 1607 vs 1709) and older version of SPlat (2017.06 vs 2017.10).  All the AAS stuff works fine there.
 
I realize that there are a bunch of differences in the two scenarios besides the SPlat and Windows versions.  One is the fact that the firewire interface is on an ExpressCard plugged into the laptop as opposed to one built into the motherboard.  But humor me here...
 
Were there any audio engine or VST implementation differences between 2017.06 and 2017.10?

Ok...there's more information.
 
The failure appears to be project specific.  More to the point...it may have to do with the project template that the project was started with.
 
I have a legacy project that had its genesis at least before 2008.  Pulling in new AAS synths in that project have no problems.  Another project from last year that was likely started with "4 Track Audio.cwt" crashed when I instantiated a new AAS synth...but it only crashed SONAR.  It didn't do a BSOD on the whole machine.
 
The project that did the BSOD was from a "kitchen sink" template that I put together that includes AD2 with a full fan out of individual tracks for each kit piece as well as tracks and folders for guitar, bass, vocals and keys with Rapture Pro.