RESOLVED: X3c project corruption - AGAIN !!!

Now this is getting really, really annoying. Recently I find myself wasting some much time on troubleshooting troubles I never had before X3 came around.
 
And now again: new project, created in X3, only a few synth tracks plus a vocal line, which was modified with Melodyne and frozen, then saved. Coming back to open the project I just get crashes, unfortunately all auto-saved copies behave likewise!! But the version saved manually one hour earlier loads perfectly. The only differences really between the crashing version and the working earlier one is that a couple of clips were shifted by a few ticks and then one track was frozen.
 
Sonar again somehow corrupted our work.
 
I had the same problem in a bigger project just 3 weeks ago. Reported problem, got re-directed to support, whom I contacted but they never got back to me.
 
Now, I assume there'll be plenty of posts saying "go fix your system", but it ain't broken! I did soooo many checks in the recent 2 weeks (drivers, updates for 3rd party software, memory, disk integrity, power options, viruses, malware, ... the list goes on). I can't think of anything else to check. And now that it has happened in an extremely simple project, I'm even more convinced that it can only be X3 that's causing this!
 
I think I just forget about X3 until somebody from Cakewalk can tell what is wrong with those projects and why they work one day and are broken when coming back to continue working ...
 
 
<<for cakewalk reference: CWBRN-21497>>
 
Edit: opening the project in SAFE mode, also causes a crash! so it's none of the synths (which would be FabFilter) or plugs (which would be WAVES mostly)

64-bit double precision engine disabled? There are some issues with it in X3c, though I'm not sure if any of them can cause a crash.
 
 

Sir Les
But in today's effort to make my system tweaks complete...I went into the bios just to check on things....And I found CPU Speed step was enabled....Seeing as this may have been causing CPU Spikes to occur or interupts...could it be the culpret in corrupting data when being saved?
 
So perhaps this could be part of the issues some overlook in setup or tweaking?...
 
Also there are other things that may be causing hickups in the os...that may be bound to bios settings....So it would be prudent to double check , make a list,...and see what happens when....
 

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 ...

Hi There -
I was just looking at your Windows 7 thread in software, and wondering if your backup changes may have reintroduced something.  If Sonar were looking for a saved copy through a backup app and now the app is disabled . . . . . .
 
Just thinkng.  Good Luck
 
Brian

OK - thanks for clarifying.  Perhaps it is something to do with the X3c update?  Have you tried rolling back to X3b?
 
I wish I was more help - maybe some more coffee, or more pain meds, would help.  I'll get right on that. :)
 
Bob Bone
 

Well over clocking will burn out the cpu faster if a fan/cooling goes unchecked when failing...And if overclocking...speed step is unnecessary as this will boost the cpu speed )overclock to a safe level( when not overclocking normally...So what happens when left on, and overclocking?....if it is on...I'd say that is a possible suspect for mayham...also I was told by the sweetwater people that VT in Bios should be turned off for the Avid user of Pro tools 9.0...when I bought in to that mess....So Some things in Bios may be overlooked..that can cause issues, by the faint of heart ....If saving in sonar, and a cpu spike occurs while saving a CWA file...what happens?....In my case with recorded audio, perhaps a anomaly is added in on all armed and recorded tracks...What happens with saving CWA's if same occurs at that same moment in time?

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 ...

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).
 
And yes, some of the settings in the BIOS can make all the difference in the world.  The simple fact is, if your Sonar X3c is misbehaving while hundreds (thousands?) of other users are working just fine, it's obvious the problem lies with your setup somehow.  Could be a setting, conflict, incompatibility, glitch during an update... You get the idea.  It's never fun to try to narrow it down, but is necessary.
I'd suggest starting with the BIOS.  Find the power management area (look for SpeedStep or C1E) and disable them.  If you don't feel comfortable in the BIOS, come back and we'll try and help you.

As far as I can tell the majority of people are not reporting corrupted projects, so it's unlikely the software by itself is the problem or there would be many more reports. I've had one corrupted project that I can remember since Sonar 1.0, and was able to recover it so I don't know if that qualifies. At this point we're grasping at straws, but an experience I had with the Mac may be instructive.
 
As we all know, Macs are Perfect and never crash because they are Perfect . But I kept having weird, and extremely intermittent, crashing and file corruption problems. I lived with this because the issue was rare, but every now and then I had to re-install the OS and start over.
 
To make a very long and frustrating story short, someone (it was either here or my SSS forum) suggested checking the RAM. So I checked the RAM, and it was fine.
 
BUT then it was pointed out to me that the only way to REALLY check the RAM on a Mac was via the command-line interface, because otherwise, I'd be using RAM to load the program to check the RAM. Or something like that. So I found a way to test RAM from the Mac's CLI.
 
Son of a gun. One of the RAM sticks had a problem. I replaced it, and my Mac has been working fine ever since. I have since become a proponent of "No, the cheapest RAM you can buy off the internet is not necessarily the best option."

Anderton
As far as I can tell the majority of people are not reporting corrupted projects, so it's unlikely the software by itself is the problem or there would be many more reports. I've had one corrupted project that I can remember since Sonar 1.0, and was able to recover it so I don't know if that qualifies. At this point we're grasping at straws, but an experience I had with the Mac may be instructive.
 
As we all know, Macs are Perfect and never crash because they are Perfect . But I kept having weird, and extremely intermittent, crashing and file corruption problems. I lived with this because the issue was rare, but every now and then I had to re-install the OS and start over.
 
To make a very long and frustrating story short, someone (it was either here or my SSS forum) suggested checking the RAM. So I checked the RAM, and it was fine.
 
BUT then it was pointed out to me that the only way to REALLY check the RAM on a Mac was via the command-line interface, because otherwise, I'd be using RAM to load the program to check the RAM. Or something like that. So I found a way to test RAM from the Mac's CLI.
 
Son of a gun. One of the RAM sticks had a problem. I replaced it, and my Mac has been working fine ever since. I have since become a proponent of "No, the cheapest RAM you can buy off the internet is not necessarily the best option."

Craig, let me just state upfront that the problem is rare, and difficult to reproduce. I've been using Sonar since version 1 and it's happened at one point or another throughout multiple versions of Sonar (most recently with X2) across multiple systems. I'll bet that if you took a poll on these forums and asked "Have you experienced corrupt projects in Sonar" you'll get a larger number of responses than anyone would care for. I can see 3 threads just in the last week that reference corrupt projects. A forum search yields much more results going back years (which lines up with my experiences).
Now with the above said, unless my PC crashed during a save, my hard drive died, or the power was unexpectedly cut, corrupted projects should never happen. Ever. Otherwise, if something is failing in the save routine, Sonar should not commit the save. The save process should first perform a check to make sure the save was successful, THEN commit the changes. If not, display a "Save Failed" error message and don't apply the save, this would at least alert the user to the error and allow them to the necessary action.
 
By just essentially saying "it's got to be bad hardware, it doesn't happen to me" doesn't mean it's a non issue, nor does it mean the problem isn't in Sonar's save routines or project file format. Look at the "loops don't stay in sync unless the metronome is on" thread that you participated in just a few days. It was reported by multiple users, you tried (very much to your credit) to reproduce the issue and couldn't, and suggested that it might be a zero crossing issue. However, if the loops were loosing sync due to a zero crossing issue, then turning on the metronome wouldn't resolve it (and the OP confirmed that it wasn't a zero crossing). So there's clearly something going on here, that's not manifesting itself in all scenarios or systems, but it doesn't mean the hardware is at fault, it just means Sonar's not doing it on your machine. Some software is more "sensitive" to different hardware configurations than others, but that doesn't make the hardware at fault.
 
And finally, as I indicated in my post in the other thread, I've just never had this happen in other DAW software. Maybe that's just luck, but I suspect there's something that can be done under the hood in Sonar to bulletproof the save process. Perhaps just putting something out there on these forums that says "if you have a corrupt project 1) tell us what happened and 2) send us the file" might help diagnose the problem, being that it's so rare and difficult to reproduce. 
 
Just like Noel went in and took a look at the VST code, fixing a lot of bugs to increase stability, it couldn't hurt if someone did the same thing with the save routine. Maybe they'll find bugs, maybe they'll find some way to verify a save was successful before committing it (like a checksum type routine), maybe they'll look at the code with fresh eyes and decide that the CWP file format is a bit outdated and it's time to update the default project file format to a more modern standard (perhaps something XML or .txt based). Then again, maybe they won't find anything. The point is, there's enough anecdotal evidence on this forum to indicate their could be a problem, and the only thing it cost is a few hours of one or more developers' time. Those few hours seem like a worthwhile investment to me.

Funkybot you could try what I have suggested?

Regardless whilst your issue appears to have the same symptoms as the OP, the chances of it being exactly the same issue is slim. We could all delve into what our opinions are of what it could be, but the idea here is to rule out what it can't be.


BTW the name of the game is to find a reproducible bug, developers are not psychics or magicians and sadly it would be far more than a "few hours work" without steps to reproduce (needle in haystack assuming there is an actual problem, otherwise it's an invisible needle in a haystack), that's what customers and QA departments are for.

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.

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 ...

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.
 
 
 

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 ...

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.