Oh one last thing, when I've upgraded I still tend to stick to the apps (and version of app) where the projects were originally created. I appreciate this is not for everyone (esp when they don't own that version) but it can save a lot of hassle.

As a developer I know upgrading file formats with different versions and configurations is probably about the most complicated thing there is. So I tend to stick with the same egg cracker to crack the same egg.

BTW to say other apps such as pro tools or cubase never corrupt is baloney. Even Microsoft word and excel corrupts every now and then. 99 times out of 100 its generally down to upgrading a file format or an app not closing down properly thus corrupting the file. In fact all files are prone for corruption every now and then...

BTW if a file does not save properly the only thing that will flag that is the operating system not sonar (sonar reports what the os tells it to report).


Anyways please check my suggestions.

@OP - file corruption may be a combo of overclocking and your I/O buffers, more explanation below. The specific plugs you are using may also be a source, but the only one I saw was Melodyne, and I have not seen this issue.
 
Definitely check your system using the latency monitor, and use that to see the effects of changes you make. It is at http://www.resplendence.com/latencymon (then "Free Downloads" on the left, and "LatencyMon" in the "System Monitoring Tools" section) if you do not have it already.
 
I overclocked my system just for grins last week to see the "overall effect" and at moderate overclocking, the CPU ran double its normal temp and began throwing faults which the latency monitor picked up easily. The faults being created by the heat actually degraded overall performance (and also the thermal degradation will compound over time). Here is a link to CPU benchmarks http://www.cpubenchmark.net/high_end_cpus.html and your CPU is much higher on this list than mine (like #14). As you have an ASUS board, when you enter BIOS there is an "EZ mode" and "Advanced Mode." In EZ Mode there are three quick choices on boot (Power Saving, Normal, and "Turbo" (I believe)). I just set mine back to "Normal."
 
Another check is the I/O buffers. I use the X3 demo project to tailor the best latency and I/O buffers (mute the mix down track and play the rest), and I/O buffers outside of the 256/512 range start to mess with SONAR's ability to write to disk (for me). In fact, due to the size of this project, when the I/O buffers were set at 256 I got "general program error" trying to save the file. This did not crash X3, but X3 did nothing but throw that error box at me. I had to set the I/O buffers to 512 to get it to save.
 
That said, my system will run that X3 Demo Project at 14% CPU usage, and trucks along fat dumb and happy at ~20C. (With AI Suite II (ASUS utility) you can pop that open and click the "Monitor" button and then "Sensor" to check temps in your machine.)
 
 

Thanks to all of you for that overwhelming number of replies and your time and effort trying to help. I really appreciate that :-)
 
It just read myself through the replies and will try to combine all of my thoughts/replies into a single post in a minute.
 
First I need to mention, though, that we continued working on that troublesome project that got corrupted. We started from the last saved file that opens without a crash and put about 8 hours of creative work, recording, editing etc. into it, continuing on X3c, rather than rebuilding on X2a so that we could continue the creative flow ...
 
Well, and it all worked fine. No crashes while working. No file corruptions, every single manually versioned file opens and plays back nicely.
 
So that particular corruption problem will be awefully difficult to reproduce, but there are all those minidumps to give hints on what could be causing it, yet only Cakewalk can read them; I can't.
 
Despite all that I found another one of those simple projects that was created on X2a (containing only a few audio/MIDI scratch tracks) which opens perfectly in X2a and immediately crashes X3c. File successfully saved sometime in Feb 2013 with X2a, never changed since ...
 
I can't help thinking that something got overlooked/broken between the versions that jeopardized the forward compatibility. I have the feeling that it might not be all that save to keep working on projects in the new Sonar version if created with an earlier version ... yet that would mean that any sort of template is also a risk and if you want to be safe you waste a lot of time always starting from scratch (anybody else relying on templates?).
 
OK, as regards all your most welcome replies:  

• I don't just want to disable over-clocking "because there is no need for it". This beefy DAW was build to track a large number of tracks at lowest possible latencies with plenty of plugs and synths working in real time (that's what it did really well for the past 10 months); so we want every little bit of that performance
• Resetting BIOS and disable over-clocking: I would consider that but I would like
  • (A) to have a word from Cakewalk that this is indeed a (semi-) frequently seen reason for problems (I follow the forum closely and can't remember seeing anything negative) and
  • (B) a way to rollback if this is not the reason (100% rollback as push-button solution as my system went through a 24 hr stress test right after set-up, even more than recommended here - a post which makes great reading BTW with lots of excellent input from Jim Roseberry)
• Standard windows memory test at boot returns no problems, will try some other tools ...
• All backup software is now totally disabled; I had Acronis True Image (a very poor product IMO) cause problems in the past months with it locking up the file manager or delay DAW shut-down by minutes (so I turned all its services off and only turn them back on for a backup). As I never used any auto-backup or synchronizing or whatever, it never interferred with Sonar performance, though  
• When Sonar crashes, it creates those mini-dumps that I manually upload to the Cakewalk problem reporter. The DAW is not on the net. Hence, it does not send these auto-reports to Cakewalk

OK, need to post this now before replying to other posts ...

JonD
The way a DAW works is much more complex than your average application (say, MS Word).   A PC can be operating at 40% efficiency and still crank out a perfect Word document.  Not so with a DAW (You'll get clicks, pops, dropouts, file corruptions, etc).
 

I don't get any clicks, dropouts, performance problems during playback. Yet I ended up with corrupted projects twice. Each of these projects were saved with nothing go on (0% CPU utilization) as these were the last saves with playback stopped, right before exciting the program and shutting down the DAW ..

CakeAlexS
This isn't a speedstep or power saving issue, I would expect windows to crash if it were.
Assuming it's the same type of crash in safe mode then it isn't plugins (that is just an assumption however). It could be drivers or firmware (unlikely but needs to be ruled out).

Please try this (even though your drivers may be up to date):
http://forum.cakewalk.com/Driver-Boost-m2928792.aspx

And SFC /SCANNOW in an admin command prompt if you've done everything else as you have said in the original post.

Failing all of this I would recommend an uninstall and reinstall of Sonar and then looking at updating firmware + BIOS.
 
Sidenote:
Are you saving files away from the local hard drive/s?
Please check for errors in the windows event viewer.
Do you get crashes in new projects that have been started in X3. (i.e. haven't been anywhere near X2 or X1 etc...
If you open an existing project, then create a new project in X3, and then copy/paste everything from old project to new project, then use this new project (discard old project).. do the crashes stop happening?
 
Please report back when you've exhausted these possibilities...

Thanks

Alex

Alex,

• I had tried SFC /SCANNOW - nothing detected
• all files saved on one local hard dedicated to Sonar projects only
• can't tell if this wouldn't happen if it's all just done in X3c - potentially not as it doesn't even happen now when continuing to work with the project - but I can't just leave everything from X2a and re-start in X3c ... life is too short for that ...
• there's only a single message in the event viewer (due to WAVES which I did report to them) but that's been there since August (as long as I can trace it) and didn't cause anything bad in X2a

 
Log Name:      Application
Source:        SideBySide
Date:          11/11/2013 08:37:39
Event ID:      35
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Event
Description:
Activation context generation failed for "c:\program files (x86)\Waves\applications\wlc.exe".Error in manifest or policy file "c:\program files (x86)\Waves\applications\WavesQtLibs_4.8.2_Win32_Release\WavesQtLibs_4.8.2_Win32_Release.MANIFEST" on line 8. Component identity found in manifest does not match the identity of the component requested. Reference is WavesQtLibs_4.8.2_Win32_Release,processorArchitecture="AMD64",type="win32",version="1.0.0.0". Definition is WavesQtLibs_4.8.2_Win32_Release,processorArchitecture="x86",type="win32",version="1.0.0.0". Please use sxstrace.exe for detailed diagnosis.
 
 
 

Are you at a spot where you could try reverting to X3b?  I am wondering if whatever is ailing your system was introduced in the 'c' update.
 
I have not yet updated to X3c, as I am trying to decide if doing so would introduce some new bugs, and my X3b is cheerfully NOT giving me any problems (that I am aware of).
 
When problem solving in the programming world, one thing to look at is the delta (change) between one version of code and another, as a potential place for having issues.  IN other words, if things worked in a particular set of functionality in one release, but something is good up in the newer release, there is a good likelihood that the code that changed is the culprit.  Sooooo, reverting to X3b to see if it has a positive impact on your ability to open these projects is worth exploring, from my perspective.
 
Anyways, if you want to try reverting to X3b and need assistance with the steps to removing the X3c version, just post back to that effect, and I (or someone) will post the steps for removal.
 
Anyways, hang in there - I will keep on aye on this thread, so that if you want to try to move forward by moving backward (to X3b'), I want to be able to be responsive in a timely manner.  I have a 1-hour appointment this morning, from 10:00-11:00 Eastern Standard Time, and then I am back home and will be working with Sonar the rest of the day, and available to try to help.
 
Bob Bone
 

Hi Bob
 
Thanks again for stopping by.
 
I have first observed this problem with X3b, now once more with X3c, so I'm hesitant to go back to a version with the "same" issues ...
 
One of the "delta" changes with every new version is the save/restore functionality because every new feature implemented requires its settings to be saved and restored. Hence developers need to adjust save/restore with every major and probably also every minor release. What's the likelyhood of missing one of the zillion parameters that now sits there happily uninitialized, referencing some memory it got no reason accessing in the first place?
 
I still hope that eventually the uploaded crash logs will be reviewed by somebody at Cakewalk as this should give a fairly clear idea of what function call blew up. I also hope that Cakewalk will come back asking for the project which is only 170 MB zipped and crashes even in SAFE mode (e.g. in a plug free environment!!). I would have attached it to the problem reporter but that allows only 10 MB ... plus I got a 2nd similarly small project behaving badly as well ...
 
As this project corruption issue will be very hard to reproduce on purpose, I reckon I just continue working with X3c during the experimental creative sessions as it has some definitive advantages (melodyne ARA yields super fast access to adjust vocal lines, new comping for all these quick'n dirty tracking attempts), but I will for safety reasons do the following:

• version manually even more frequently
• bounce tracks and stems after creative "milestones"
• save more track templates and VST settings as presets

All of this should make me better prepared for quick rebuilds in case of another project file that decides to close itself forever.
 
When it gets turning concepts into productions, I will stick with X2a until X3something brings back the confidence ...

FreeFlyBertl
Yeah, the BIOS is about the last thing that I haven't gone into ... and I'd rather not go there ...
 
From my specs you can see that my system is overclocked, but that was done by a professional about a year ago and tuned to a save level. Worked fine so far, never caused hickups and hence I'm reluctant to go fiddle with BIOS knobs I'm not familiar with, especially as it's just Sonar corrupting its own files, but no other application is behaving funny ...

If the over-clock is completely stable, there's no other BIOS setting that would affect the integrity of saved data.  
 
FWIW, It's relatively easy to disable/re-enable the over-clock.  That would allow you to quickly rule it in/out as a culprit.
 
All that said, running the 3930k at 4GHz isn't much of an over-clock... so I doubt that's the issue.

Just on a wild hunch, are you saving projects to your SSD? I had flaky behavior with mine initially, so save all "data" files to magnetic media when possible. I still get this if I try to fire off large installation files from the SSD instead of magnetic media.

mettelus
Just on a wild hunch, are you saving projects to your SSD? I had flaky behavior with mine initially, so save all "data" files to magnetic media when possible. I still get this if I try to fire off large installation files from the SSD instead of magnetic media.

nope. SSD is system only drive. got 1 SATA drive for samples and 1 SATA drive for sonar projects.