32 bit vs 64 bit plug ins and the blue screen of death

Sorry for such a long explanation, but I thought better to be thorough not to waste people's time. I recently purchased the 32 bit VB3 Virtual Tonewheel Organ plug in by GSI. By the manufacturers instructions it does not come with an installer. You put the 2 dll files they provide into your Cakewalk virtual plug in folder, which I did. It opens perfectly, runs fine, and sounds fantastic. The issue is that all of the other plug ins I use are 64 bit. When Sonar X2 starts, it loads the dll's in the 64 bit folder, and is not even directed at the 32 bit folder in preferences, even though all of those same plug ins have their dll's in the 32 bit folder. So instead of putting the VB3 dll's in the 32 bit folder, and directing Sonar to load all of the 32 bit dll's, I opted to put the 32 bit VB3 dll's in the 64 bit folder. The only issue is that since I've done that, every time I shut the PC down at the end of a session I get the blue screen of death, and Windows says that it recovered from an unexpected crash, and restarts itself. I am sure it is due to this plug in because whenever I work on another song that does not use the VB3 plug in it shuts down fine. Does it make sense, that I move all of the other 32 bit dll's to another folder for safekeeping, put the VB3 dll's in the 32 bit folder, then set Sonar to load that folder? My concern once again is that I don't know what would happen if I left all of the 32 bit plug ins in their present location and let Sonar load them in addition to the 64 bit versions of those same plug ins. More specifically, if I am using all 64 bit plug ins, does it even need the 32 bit version of those same dll's? I am concerned that if I move them, or direct Sonar to load them it might create some sort of conflict and render the system unstable. So thought I'd ask for some guidance first. Thank you in advance Here is the problem signature Windows shows after the blue screen crash: Problem Event Name: BlueScreen OS Version: 6.1.7601.2.1.0.768.3 Locale ID: 1033 Additional information about the problem: BCCode: 1000007e BCP1: FFFFFFFFC0000005 BCP2: FFFFF88005902EB6 BCP3: FFFFF88002FCC9D8 BCP4: FFFFF88002FCC230 OS Version: 6_1_7601 Service Pack: 1_0 Product: 768_1

Also, out of curiosity....

Have you made copy of the crashable project and remove the 32bit "offender" plug and closed the project just to be sure it's the 32bit plug that gives a BSOD? 

I'm not sure I have run the VB3 in X2a, I'll have to test.
I didn't make the jump to Sonar x64 until X2.
I've had some issues, Sonar X2 "locking up" with IK's CSR and Ampeg SVX.
These became hard crashes with the "a" patch installed.
I did get a BSOD or 2, it wasn't consistent; Sonar X2a crashing was, just not the BSOD.
I keep all my VST's in separate folders inside the VST Plugins folder.
I point "Plugin Manager" to the specific x32 VST's that I want Sonar to use.
Sort of like Bapsi, only different...

Tom

FWIW, I just downloaded the demo. Put in a project. Closed the project. Closed normally.

Also forgive my lack of knowledge on the subject, but lets say the project file is corrupt, and that it VB3 has nothing to do with the problem. If you make a copy of that project, will the corrupt data copy itself too?

On the corrupted project file - get VB3 back where it belongs (and/or delete it entirely) and with any luck you might find the project now loads.

Your 32 bit VST's will be fine.
Sonar "ignores" the duplicates, I think that's right.

Tom

Thanks you everyone for the help this has been very useful

This is very interesting.  For a long time, I had 32-bit v 64-bit confusion (meaning that it was tricky to make sure Sonar found the right dlls).  I also theorized that using a mix of 32 and 64 bit plugs-ins was affecting memory utilization, although some have told me that cannot be so.  I also attributed some crashes to this same cause.

Recently, Sweetwater upgraded all my remaining 32-bit plugs to 64-bit and I no longer need bit bridge, so this possible cause is now eliminated.

I am obviously not helping you solve the problem.  I am just saying that I think there is an issue deep in Cakewalk code.