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

Makes no difference the order you install it. The error itself could be with the distributable or the application calling it (Sonar).

It makes sense to update the c++ distributable first to the latest and not reinstall anything, all versions are backward compatible. Often (not always) windows update (you need to check optional updates as well) will sort it as well.

If there is corruption (rare) SFC /scannow may fix it.

In my experience often (not always) the issue occurs when windows update isn't run very often or an application didn't update itself correctly or bundle the correct library.

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.

I don't have a lot of experience with this with Sonar exactly, but I will say it is a nightmare to try and navigate all the possible Visual C++ redistribution packages offered by Microsoft directly. If there were some kind of "repair" option in the Sonar installation that would definitely be helpful.

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. 

The repair simply looks at a file and check to see if it is the right one with an appropriate checksum. Sorting out the libraries will only resolve issues relating to c++ DLL's (found through some error reporting mechanism such as the windows event viewer). I wouldn't recommend playing with c++ libraries unless an identified c++ error could be located (usually a c++ DLL failure) or windows update recommend a patch.. Cheers.

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

This would be something to take up with Noel. The support folks at CW must look at a lot of dumps, and may even keep statistics about faulting modules. If so, they'd be able to tell you how common problems relating directly to C++ library version mismatches really are.

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
 

CakeAlexS

It makes sense to update the c++ distributable first to the latest and not reinstall anything, all versions are backward compatible. 

Do you have a reference for this? The experience of thousands of users in forum problem reports seems to indicate that some code at least is written to require specific versions of the runtime, and will not work with more recent versions.