Hey People Who Know About Computers - Is this a Fix for a LOT of "Sonar" Problems?

Yes, I pay attention to this forum. And quite often there are threads along the lines of some weird issue that hasn't happened before and leaves everyone else scratching their heads, error logs that identify strange DLLs, instruments that don't show up, etc. And then there are the threads where this kind of stuff happens and people re-install Sonar, and that fixes the problem. The logical conclusion therefore seems to be that Sonar got corrupted and re-installing fixed it.
 
Well, there was another one of these "corner case" issues of some people not being able to install SD3. There were too many of them for it to be someone's odd system problem yet I don't think this is something that happens all the time or the forum would be up in arms. 
 
scook pointed to this knowledge base article: http://www.cakewalk.com/S...recognized-by-SONAR-X3
 
And I couldn't help but notice that this referenced the Microsoft Visual C++ Redistributable and how Sonar is missing certain files from same. Also, there are some other threads floating around with crash dumps that reference DLLs found in Visual C ++.
 
So, smart computer people, I have two questions:
 
1. When people fix a problem by re-installing Sonar, what are the odds that they're fixing the problem because Sonar is installing files from the included Visual C++ Redistributable that were overwritten, missing, abducted by alien code snatchers, or whatever?
 
2. If all else fails and someone feels they need to re-install Sonar, would it make more sense to try re-installing the Visual C ++ Redistributable that comes with Sonar first rather than Sonar itself?
 
Enquiring minds want to know...

I'm watching this thread w interest. Having problems in the past until I reformatted and reinstalled the OS /x3. All is well now, but the fact I had so many c++ redistributables installed back then bothered me. Now as new programs come along, many of them automatically install yet another older version of the c++ redistributable. They are starting to pile up in numbers again. That approach appears unnecessary and worries me that trouble lies ahead.

Sanderxpander
If there were some kind of "repair" option in the Sonar installation that would definitely be helpful.

Interesting. I wonder if having "repair" simply re-install the C++ stuff would solve a lot of people's issues. I don't experience the off-the-wall problems some people have, or find the need to re-install Sonar. I attributed a lot of this to the reliability of the PC Audio Labs computer, but the various threads about possible C++ issues make me wonder if the fact that I don't do a lot of new installations that install their own Microsoft library variants might be a contributing factor. 

Certain development code is dependent on certain levels of maintenance having been applied to Windows.  This is why (think it was X2), was the last version some folks could install, if they had XP, because the Sonar update had a minimum requirement of a set of C++ redistributable routines that only came into existence with Windows 7 Service Pack 1, so XP would NEVER be able to run beyond whatever that last release was prior to the one that needed Win 7 SP 1.
 
Many applications require particular versions of run-time executable routines to be present, and I wish these programs would check for newer versions, to see if the older ones were really required, but for whatever reason they don't, so a bunch of older run-time libraries end up getting installed.
 
I just put up with it, and wish someone would simplify things so that if older routines are covered by newer library releases, why not fix it so the older libraries can be removed.
 
Maybe that is just wishful thinking, 
 
Bob Bone

Well, I have been involved with multiple threads, maybe 3-5 or so, from folks where C++ runtime libraries were the heart of the problem.
 
It is one of the reasons folks ask if Windows maintenance is up to date, as some folks choose not to run updates for Windows for really long periods of time.
 
Others do not know they need to.
 
I see this pop up maybe every six months or so, it depends on if a given release or maintenance update has dependencies and folks start downloading and applying them, and all of a sudden someone's computer will go 'nope - not this time buddy', and we have to dig into maintenance levels and such, usually with Dependency Walker, sometimes Cakewalk will dig things up in dumps.
 
Bob Bone
 

IME, a lot of odd issues happen as a result of individual applications expecting a certain version of C++ runtime.
The latest version *should* work fine... especially if you're running recent release software... but that's not always the case.
 
As others mentioned, the first thing I'd do is get the OS up-to-the-minute.
If that fails to resolve the issue, I'd do a full/manual uninstall of Sonar *and* the C++ Runtime libraries.
That means getting rid of all traces of Sonar (including Registry entries).
 
I can't stress this point enough... but when everything is running well, that's exactly the time you want to create a backup image file using True Image, Paragon, or similar.  If anything odd happens to foul up your configuration, you can reload that backup image file and be back to a properly functioning DAW in just a few minutes.
If you're under tight deadlines or dealing with clients in-the-studio, this is even more important.
This can save hours and days of potential frustration and down-time!!!
It's human nature to put-off backups when all is working well.
After all... it isn't a problem... uhhh... until it's a problem.  
Take the time to backup.
 

I think my point about the nightmare is well proven :)
I think it would be a good idea if Sonar could reinstall its own dependency libraries through some kind of "repair" option in the installer.

I agree with Dave about getting Noel involved, as the term "LOT" in the title seems misleading based on questions in the forum.
 
[Even on issues beyond the C++ Redistributable] The "repair" option is the most feasible; however, due to the customization/registry edits made by the user, this option is not as "cut and dry" as it would appear on paper. To validate files/registry pointers, a file would be required for each person's install, and manual edits to these would be missed unless logged during the startup of SONAR itself (which would encompass a bit of programming overhead).

The problem of file version dependencies has been around for as long as late-linking has, going back at least to Windows 3.1. There's even a long-established name for the phenomenon: DLL Hell. I remember dealing with similar issues even before Windows existed, when I was doing O/S support for a mainframe manufacturer.
 
When I first starting distributing my own application back around 1996, my business partner did most of the installs. We pulled more than a few all-nighters back then troubleshooting DLL conflicts, he in some remote city, me back here on the phone.
 
I finally wrote a diagnostic program that finds all of our program's dependencies and their dependencies, compares versions to what we expect, verifies that registered libraries have been registered, and enumerates duplicates. This diagnostic was then incorporated into our standard install so that every workstation has a copy. DLL conflicts still occur, but now we can quickly identify and fix them.
 
Over the subsequent years I've extended that approach to make my application largely self-diagnosing, self-documenting, and in some cases self-correcting. I don't have as big an installed base as Cakewalk, but I couldn't possibly support as many remote users as I do without some software assistance. If I had as many seats as CW has to support, I'd definitely make my product self-diagnosing.
 
Adding minidumps at SONAR 8 was a big step in that direction for CW. Prior to that, figuring out which plugin had crashed the DAW was a guessing game. If I were in Noel's shoes I'd be looking at automated diagnostics such as a version checker, a debug logger and perhaps a basic minidump analyzer, and bundling them with SONAR. Their support staff should be lobbying for this, too.

Unless I have seen recent examples of a particular problem posted and resolved by MS library updates, I don't usually mention it as a solution. I refer those cases to tech support. The SD3 issue was one which played out on the forum. It was an instance where Noel intervened and suggested using a dependency walker tool which lead to the resolution and ultimately (I suspect) the knowledge base article. As an example of another library specific issue in SONAR, IIRC, SONAR use to ship with two run time libraries because the VC-64 could not run without an older version of the library.
 
As far a re-installing SONAR, I have never done it. Can't credit the my hardware though. I use off the shelf general purpose machines configured and used for a variety of applications.
 
There are instances where installations have failed and re-installs fix the problem. Re-installing software fixes registry problems , file and configuration issues which to some extent can be repaired with SHIFT or CTRL+SHIFT when starting SONAR. I would suspect there are also cases of user error which appear to be fixed by re-installing software when in fact some subtle change in usage actually solved the issue.

Sort of on topic,,, so on a new OS install Is it best to let all windows updates do their thing BEFORE installing your audio software?? I just did it backwards and it's not running very good DPCLAT wise... Never had the red spikes before... So I was tempting the re install Sonar/  Focusrite driver plan??  I do remember a few of my software programs installed C++ in the mess... Then Windows update did a bunch too.. 

Guitarpima
A little off topic about A3. I don't understand why it has two inputs in the audio setup. I set the 2nd one to something that would get no signal and would you believe it sounded better? (shaking my head)

Not sure if this is what you mean, but you can enable stereo routing in Amplitube via 2 of the 8 routing presets (the numbers on the top left of the window). Numbers 2 and 6 give you the option of changing the "mono in" setting to "stereo in," after which you can then process the left and right channels separately with different stomps, amps, cabs and racks. 

Please do not uninstall C++ libraries. Upgrade yes, repair yes, but don't uninstall (unless there is no option) as it could lead to far more serious problems (you are playing with fire).

And C++ libraries aren't ever an issue until you see a specific related issue logged. If in any doubt run windows update (including optional updates) several times which will sort out most problems.