Shouldn't this be the proper run-time distributables - Visual Studio 2013?
The one you posted was for 2012.
http://www.microsoft.com/en-us/download/details.aspx?id=40784

Again please run windows update first several times.
If that doesn't fix it please update using the link I've provided (VS2012 not VS2013). Cheers.

Feel free to shoot me your template in a PM and I can try to see if this is happening on my end here at HQ.
-DG

 
Windows update runs every day automatically. Running it manually won't accomplish anything.
 
I'll give the link you provided a try later today. I've been running some stress tests and I want to see how they pan out. (So far there is no trouble.)
 
But I don't see how a pure virtual call could be anything but a programming error.

Dan Gonzalez [Cakewalk]
Feel free to shoot me your template in a PM and I can try to see if this is happening on my end here at HQ.
-DG

I just PM'ed you with the info.
 
Thanks for offering to help, this is driving me crazy.

Thanks! Received.
-DG

CakeAlexS
Back up.
Run windows update several times. If that doesn't fix it install this:
http://www.microsoft.com/en-us/download/details.aspx?id=30679
 
Good luck.
 

Thanks for this possibility, it looked reasonable.
I installed, restarted and tried the test, but there was no change - same error.

Darn... Appears to be a bug....

Out of sheer desperation I searched for Pure Virtual Call errors and looked over a lot of them. There are several reports in various pieces of software in recent weeks by people running 8.1, but not being seen in Win 7.
 
My current theory on this goes as follows: Windows 8 is a new OS kernel with somewhat different threading processors than Windows 7. There was a recent patch Tuesday update "http://support.microsoft.com/kb/2887595"
that was not a security patch, it was a kernel patch. Among the many things changed, these stick out:
 
C:\Windows\System32\AudioSes.dll
C:\Windows\System32\comdlg32.dll
C:\Windows\System32\gdi32.dll
C:\Windows\System32\kernel32.dll
C:\Windows\System32\libstdc++-6.dll
C:\Windows\System32\libwinpthread-1.dll
C:\Windows\System32\shell32.dll 
C:\Windows\System32\twinui.dll
C:\Windows\System32\UIAutomationCore.dll
C:\Windows\System32\user32.dll
 
Which may indicated changes in threading in the kernel.
 
I only noticed this problem after the last Patch Tuesday (11/12/13 an ominous date).
 
What I think is happening in my case is that Sonar is creating the track in two stages. First it makes a MIDI track and an Audio track, then it destroys them and makes an Instrument track from them.
Another thread is using one of the old tracks after it is destroyed - resulting in the pure virtual call - that object no longer exists.
 
It explains why I see both tracks and not the instrument when it fails. Also it is somewhat unpredictable as race conditions go. The failure does not always occur.
 
That all makes sense to me, but *not* why it only occurs when I use my customized 'Normal' template. It shouldn't make any difference what the project looks like. I do not see this whenever I use an unmodified factory starting template. 
 
I hope Dan is able to track down an 8.1 setup to test this. It doesn't take long to try out.
 
All the crashes report events like this:
 
Faulting application name: SONARPDR.exe, version: 20.0.3.239, time stamp: 0x526fbabb
Faulting module name: MSVCR110.dll, version: 11.0.51106.1, time stamp: 0x5098826e
...
 
I could and probably should attempt to test this by restoring my system image made before Patch Tuesday (I always make one before Patch Tuesday). But I'll wait and see what Dan finds.

OK, I restore my system just prior to the last Patch Tuesday update and it made no difference, so we can eliminate that possibility.
 
I was hoping that MS blew it this time, but it's probably me.
 
I guess the next thing to try is the uninstall/re-install Sonar step.