AAS plug in SPlat causes BSOD...

I recently updated Applied Audio Systems String Studio VS-2 to version 2.1.0 and tried instantiating it in a SPlat project (version 23.10.0 build 14).
 
It crashed my system...not just the SONAR application.  The blue screen described it as a "Page Fault in Unpaged Area".
 
This is 100% repeatable.  It blows up with the VST2 and VST3 versions.  This also occurs with all the other AAS softsynths I tried with the exception of Tassman 4.1, which is no longer being updated.  Other non-AAS softsynths I tried also worked fine.
 
My system information...
Windows 10 Pro, version 1709, build 16299.309
Intel i7-3930K @ 3.20 GHz
16 GB RAM
AMD Radeon HD 5450
 
This smells very much like an AAS problem, but attempting to contact them reveals that their support resources don't seem to be very robust.
 
Has anyone else had problems with AAS stuff?
 
Note that AAS plugs supplied with SONAR (like Strum and Lounge Lizard) seem to still work, but they seem to be built on the same older framework as Tassman.

I have contacted AAS support and compared to some companies they are pretty good but will not be instant. 
 
I don't have String Studio but have their other synths and have not had an issue with them. Normally a BSOD would be cause at the driver level and not software. What audio interface are you using and are your drivers up to date? 

In modern Windows (and other OSes), applications are unable to cause BSOD. Even intentionally (and I am sure AAS has no such intention).
 
But they can trigger BSOD in buggy driver or system itself.
 
There are 2 places where VST "speak" with the system, drawing own interface and in the anti-piracy checking.
 
Try to run VS-2 standalone.

I have String Studio and use it and the other AAS synths all the time. I hadn't used SONAR in quite a while so I just loaded platinum up (last/final build) and loaded up string studio (v 2.1, 64 bit VSTi2) and confirmed it is working properly here. I am using Windows 10 pro 64 bit and it is current and up to date as well. So not Windows 10 (per se) either as far as I can tell. As others have said it would more likely be something system specific.

I'm using an ancient M-audio ProjectMix which I expect may use the same firewire driver. I got it off ebay last summer, so I went to M-audio website and downloaded the latest driver. I think the release date of that driver was 2015 and may have been for win 8 - works fine with win 10 and no issues with my AAS plugs. If you are running a driver from 2010 I would recommend you update it for the latest one even if it isn't the cause of your problem.

Does it not name the offending driver at the end of the BOSD

Possibly, I know there are some tools out there that can read and give meaningful information but I have know idea which ones are the best been a long while since I had to deal with BSOD and dump files.

Is you MoBo bios up to date?

Furry paws crossed you find a solution soon.

dantarbill

Wookiee
Does it not name the offending driver at the end of the BOSD?

nope


I guess it might be instructive to find the dump file that the system creates and see if I can decode it.

Try this https://www.nirsoft.net/u.ls/blue_screen_view.html

I agree with azslow and 35mm.  Hardware and drivers are the usual culprits for BSOD.
 
+1 for BlueScreenView from NirSoft that Brando suggested for viewing BSOD mini dumps.  This can often point you towards an offending driver.

I have all the AAS instruments but on win7 OS so I can't offer any insight into your issue other than to say that I am not experiencing any problems at all on that system. 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?)

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.

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?