All right, misunderstood you, LRL. I agree that my tone has gone through the roof. When I'm not trying to fight with deadlines and crashing software, I'm actually a pretty nice guy. Hopefully my good humour will return shortly :O)

Signing off and shutting my mouth now.

Slate VCC does not use Ilok somehow? .... So that the problem could occur here ... from the way that Windows allocates IRQ .... and USB modules are a big problem , too... they must be reinstalled on each port individually.

Zo

bitflipper
I don't want to aggravate your aggravation, Ludwig, but an unhandled exception raised by a DLL is more likely to be an issue within the plugin rather than the host.

unless it' was working great in version A and not version B of the daw ;)
 
had the isssue with VBC ...rolled back to X1 ...wating patiently ..X3 rocks but has been dangerous ....for me ..

Well, an unhandled exception is something not handled properly within the failing module, which I believe is Slate VCC in this case.  
 
This unhandled exception condition could certainly be exposed by some coding difference between two releases of Sonar, but without question the Slate component did not properly deal with a failing return code from calling some subroutine.
 
It may well be that there some fixes needed for one or more things between X3b and X3c, but this would be a separate issue than the VCC itself needing some tightening up of its error handling logic.  In typical error handling, routines are often written to have specific handling of the most likely kinds of failures that can occur when calling a subroutine, and then if a given error condition is not one of those, there is normally some generic reporting of the condition and some sort of controlled exit.  In this particular situation, that sort approach was not bulletproof, and one or more error conditions are not properly processed.
 
I DO agree that if you have something working in X3b, and then you end up with an issue like this in X3c, that rolling back to X3b makes perfect sense, while you wait for the fixes to the failing component that were exposed by processing with X3c.  
 
Bob Bone
 

Have you tried putting your ilok in a different usb slot? I know it sounds weird, but let me explain. I use VCC on every project, and every track. It's the one plug that actually made me quit pining for hardware. Current X3c project has 50+ channel and buss VCC plugs. All of my projects load without a problem. Back in January I was moving to a different city. I always had my ilok in the left USB slot on the front of my computer case. Everything else I plugged into the back of the computer. When I moved, I decided to put the ilok on the back of my comp to save it from getting snagged if someone walked by. Everything else was plugged into the exact usb slot. I kept getting crashes, and my projects wouldn't load under X2. Seemed to be hanging on VCC and various softube plugs. Since moving the ilok was the only change, I moved it back to the front slot, and all my issues disappeared. I was going through the motherboard manual a month later to hook up a new blu-ray player when I read that the ports in the back are usb 3, but usb 2 compatible. The ports on the front of my computer are usb 2 only. Maybe this helps.

Agreed Resonant.
And run Windows update, update your firmware and drivers everywhere, and make sure you run this afterwards:
http://forum.cakewalk.com/Driver-Boost-m2928792.aspx

And then chkdsk and SFC /SCANNOW.

It may not appear related, but best to rule everything out first...

Resonant Order is right! ... Many faults or crashes happen because of it! ... I happened to me with iLock from the Pro Tools... I threw up and I vowed not to ever use a soft with iLock...

How the ilok driver can be faulty since other Ilok plugins are working ...?
 
Anyway for my parts i upadted everything even if it's not at all logical ....ilok /plugin version /re install ect ....
 
And then in X3D things will re work again ...and all this psycho dance will end ....
 
IF some is working a time T and not at time T+1 then what have changed since T : if nothing but sonar , so it's SONAR !!
 
as simple as that ....
 
LJB don't waist your time by going in to deep ..roll back if you have an back up ...work and then re check in X3D ....

Assumptions are merely that. Sometimes an update can expose an existing shortcoming that was not noticed or used before, or there was something else going on that was not noticed.

I have to also have the view that even if the only thing that changed was Sonar, that there may be one or more issues in plugins that are only exposed by the Sonar code, but not CAUSED by the Sonar changes.
 
This is quite common in things like plugins, as every developer has to interpret the specifications for things like VST 3, and often these kinds of specs can be interpreted in multiple ways, if some parts of the specifications are a bit on the vague side.  So, it is quite possible that Sonar is correctly following these specifications, but some plugin is not quite doing the same kind of thing in THEIR interpretation of the specification, then problems can show up after updating Sonar - when the fault may actually lie within the plugin code, and only just now failing.
 
I LITERALLY had this happen with a program I use, called Forte, from a company called Brainspawn.  (GREAT program for live gigging for keyboard players, by the way), and my Presonus AudioBox 1818 VSL audio interface.  In this case, Forte got updated, and problems immediately showed up with it following the update, but it turned out that the Presonus developers had used some really obscure parameter in their drivers that only got exposed through the Forte update - but the problem was actually in the Presonus use of the obscure parameter.  The Brainspawn folks actually entered into dialog with me, and they were kind enough to actually change their product to allow the Presonus use of this goofy parameter that nobody else on the planet was using, so that's how my situation got resolved.  The point is that these kinds of scenarios actually DO exist. 
 
Bob Bone