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.
 

Nice thread Craig !
 
In Control Panel -> Programmes, I have multiple entries for Visual C++ 2005, 2008, 2010 and 2012. OK, given some are x86 and others x64, can I delete the double entries ?
 
I get the impression every programme using such libraries installs its own version. I am probably wrong, but then why do I have, for example, 5 different version numbers of C++ 2008 (x64) Redistributabl ?
 
Yours perplexed !
Jerry

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.

One of the major causes of issues is "Multiple Versions" of the Visual C++ Redistributable being installed.

I check my "Programs and Features" section regularly to eliminate the multiples and only leave
behind the current version of each...2005, 2008, 2012, 2013, etc...in both 32 bit and 64 bit versions.
This has eliminated all my issues.

Also, once this is done, if I reinstall a program that tries to install a VC++R, I cancel it before it can 
install.  The Program install always finishes and everything is fine. It's extra work, but it saves me a 
LOT of headaches I've found...

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

According to all of the MS posts I just read, you shouldn't remove the older versions.
http://social.technet.microsoft.com/Forums/windows/en-US/e55213da-c158-4d6f-9977-d56ac2a848fc/why-are-there-multiple-versions-of-microsoft-visual-c-libraries-on-my-computer?forum=w7itproappcompat
http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/multiple-microsoft-visual-c-redistributable/0608a19a-38a8-4885-9eb4-128a2bfad0a3
Reading these posts make me want to see a Linux port of everything. After all these years, windows is still a complete mess. :)

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.

mettelus
I agree with Dave about getting Noel involved, as the term "LOT" in the title seems misleading based on questions in the forum.

Well, that's why I'm asking the question...I don't have an answer, but if you discount pilot error issues and known bugs, I see a lot (there's that word again!) of threads where people have some off-the-wall issue and the thread ends with "well I re-installed Sonar and now it's working." I don't know much about about software, but I don't think programs tend to go "stale" by themselves; as pointed out by people who know a whole lot more about this than I ever will, there are dependencies in Windows that can get out of sync with the C++ libraries. At least I think that's what people are saying. 
 
I haven't escalated this to Noel because I thought there might be an answer that's obvious to anyone who really knows software (and this forum has quite a few such people - see the above post).

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.

Sorry if I'm repeating.
 
I had a situation once where my IK plugs would not work. I was at a loss and finally found a tidbit of info that worked a charm and fixed my problem. I went to the Microsoft site and found the C++ runtime files, in this case the 2005 version, downloaded it and installed it. (Beware, only use these distributions from Microsoft) I was back up and not using Amplitube 3 still, but not because it didn't work. ;-)
 
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)