In my S5 aud.ini file and there's a "FlushOnStop=On" setting.  Anyone know what that does?   I'm still having random Sonar lock ups, often shortly after stopping playback, so I was wondering if this setting might be something to experiment with??
 
So far I found the following after searching:
"It is related to the "Play Effect Tails After Stopping" option. This tells SONAR to keep processing pending data until the output buffers are empty."  
 
Thanks,
 
      Sonic

play effect tails after stopping http://forum.cakewalk.com/FindPost/3637515

That AUD.INI setting does not seem appear in SONAR Platinum looking at the S-Plat AUD.INI it seems to have been replaced with AlwaysStreamAudioThroughFx.  At a guess it probably has something to do with clearing the AUDIO buffers.

The option "Play Effect Tails After Stopping" is no longer in S-Plats preferences it has been replaced by Always Stream Audio Through Fx

Wookiee
That AUD.INI setting does not seem appear in SONAR Platinum looking at the S-Plat AUD.INI it seems to have been replaced with AlwaysStreamAudioThroughFx.  At a guess it probably has something to do with clearing the AUDIO buffers.

The option "Play Effect Tails After Stopping" is no longer in S-Plats preferences it has been replaced by Always Stream Audio Through Fx

can confirm

The purpose of that option is to avoid an annoying effect where you start playback and hear the reverb or echo tails from the previous playback. That happens when there is still residual audio in the buffer after stopping. "Play effect tails on stop" tells SONAR to let the remaining audio continue to play after stopping until the buffer is empty. This can also avoid unexpectedly chopping off the reverb tail when you export your song.
 
AlwaysStreamAudioThroughFx superseded FlushOnStop with X3. Why, I don't know. Maybe it's just a more accurate description of what's happening. In either case, you do want to leave it enabled.

I am quite curious as to why your system is occasionally locking up.  I cannot even dimly recall when the last time Sonar locked up or crashed on me, and if there were some easily stumbled into recipe for that happening, I would think we would see a whole bunch of other similar reports.
 
That makes me think that whatever IS sometimes locking up your Sonar, is something local to your situation.
 
The things that come to mind for that would include:
 
1) Possible failing when using a 3rd party 32-bit plugin in a 64-bit Sonar environment.  To use a 32-bit plugin in a 64-bit Sonar, the plugin must be used with bridging software - Sonar includes a free piece of software called BitBridge to provide that functionality, HOWEVER, not all 32-bit plugins are stable when running bridged with BitBridge.  There is a commercially available program called JBridge, that also provides bridging for 32-bit plugins, and for SOME 32-bit plugins that fail under BitBridge, they end up being able to work using JBridge, HOWEVER, some 32-bit plugins STILL fail no matter which bridging software is used.  Many, if not most, folks have made a deliberate decision to completely move away from using 32-bit plugins in 64-bit Sonar.  Most of the decent plugins also come in a 64-bit flavor - as a free download if one already has the 32-bit version.  I do still use a small number of 32-bit plugins, but I have those split off into their own folder with only that 32-bit folder added to the 64-bit Sonar plugin search path.  Those plugins were thoroughly tested by me, to make sure they were working, before I added them  to be able to be used in my 64-bit Sonar projects.
 
2) Possible failure with some 3rd-party 64-bit plugin.  There HAVE been some 64-bit plugins that don't always play nice in Sonar.  Try to see if any plugin shows up in any Windows Event Viewer messages at the time of failure, and see if you can spot any consistent presence of any particular plugins across multiple failing projects.
 
3) Make sure Windows and your plugins are all at current maintenance levels.
 
There are undoubtedly additional things others can think of suggesting you look at, but I DO think with some digging, and possible assistance from forum folks, that you might be able to get your environment stabilized.
 
Bob Bone

Thanks, you guys are great.  The system is XP Pro 32 bit and I have been using the same plugs for many, many years on the prior W2K DAW, as well as the same inteface (RME Fireface with WDM drivers - which i prefer). The prior DAW was pretty much flawless actually but ran out of horsepower.  This new DAW is a dual core Intel and ACPI (in other words I can not program where the interrupts go).  Plenty or RAM. I am using a firewire TI chipset as recommended. Separate hard drive for Audio. Doing all the things I learned over the years to insure the system is stable.  The new box runs awesome up until Sonar locks up randomly, which makes working very unsettling as I lose everything I've worked on between saves.  Once locked up I am able to close Sonar (Windows will say "Sonar not responding, end now?" and then it will close down). 
 
I can find no common denominator to reproduce it yet, I've tried every trick I can think of so far.  Messed with changing buffer sizes and latency and video settings and background priority and single-processor mode and 64-bit mix engine disabling and re-profiling, deleting picture cache, and pretty much all the basic stuff.  Ran memory and disk tests, ran DPCLat, etc.  I'm completely stumped and so bummed after months of building this box, and it working so well, but for this one major Sonar lockup problem.  It seems mostly likely to happen some time shortly after stopping playback, most often in a session where some recording has transpired, but it's difficult to say for certain if those are common denominators.
 
I could try a different video card and switch from a PCIe to PCI firewire card, BUT that is going to require punching out slots in the backplate of the DAW along with introducing a very high risk of getting Windows and/or Sonar all botched up internally - so those are last resorts to consider in my opinion.  ASIO is something else I want to avoid for a variety of reasons, so let's leave that off the table for now. Keep in mind I'm using the same exact software, plugs, interface, etc within the system that I was previously using on W2K and no issues with anything.  
 
Any help greatly appreciated, I am about out of ideas what else to try at this point or how to troubleshoot further.
  
    Sonic

BTW, lock up never happens during playing or recording, ever.  Usually after stopping the transport, or more typically when hitting rewind while the transport is currently playing (instead of hitting stop first).  Often the lockup is not immediately apparent because many times i don't realize until I click on something and then Sonar locks up - but it wasn't what I clicked on that caused it, rather Sonar had already locked up when the transport last stopped - but isn't apparent until you later click on something and Sonar no longer responds.   Many times the green PLAY button on the toolbar is still lit, as if Sonar was unable to complete the STOP sequence and got locked up.
 
Sonic

Hangs are usually caused by hardware or hardware drivers. Which is not to say that buggy software can't also do it, but if you're not using any new plugins you can probably eliminate that possibility.
 
I know this doesn't answer your mystery, but perhaps it's a clue.

I had a similar issue with an older XP install. It would lock up randomly when using a pretty Ram intensive VST instrument. It would not crash.... but lock up for maybe up to 30 seconds. Something about the way the memory was allocated could be a problem. Maybe check to see if  your disk cache the same as your w2K install?