Forget recording for a second. If I select one track, I cannot delete data present in its controller lanes. If I move the clip to a new midi track, I still have all this extraneous data in the lanes. If I delete all the notes in the track, I still have indelible controller data. If I remove every plugin and turn off every controller, I still have this gunk in the track, which leads me to believe that it is entirely a problem with Sonar.
 

Stuntpickle
I see posts where people complain about Sonar being buggy and replies from others who claim to have no problems. My guess is that the people with no problems are using relatively few tracks or samples as I, myself, have no problems in similar situations.
...
I'm using quite a few samples from East West, but my computer is nowhere near taxed. It seldom reaches over 60% cpu.

I am with you with an impression that Sonar is crashing a lot. I had more crashes in Sonar then in any other program I was using in my life (may be because I have never used DAWs before). But most of these crashes was not in Sonar itself. That is hard to realize since Sonar while "hosting" tons of third party programs has no internal problem tracer (feature request?). That is the same as at MS DOS time, when program crash was equal to the system crash even when there was nothing wrong with the system.
 
If your workflow is the same when working with small number of tracks and you have no crashes, the probability that the reason is some bottleneck in resources is hight. 60% CPU (mean value) does not mean you have no problem here. Small example: on old Atom based computer I get glitches with under 1024 buffer size once I see CPU is used more then 20%. CPU/system should manage to process things in semi Real Time when working with audio, that means once the time comes, it should make it in time. Does not matter either is stay idle 90% of physical time or is doing something. All that is hard to explain without going too deep into underlying technology.
 
Components involved are: Sonar itself (with its settings), Audio driver (with its settings), Windows (with auto updates enabled it is doing fancy things several times per day, as was already mentioned before), all (!) devices and there drivers attached to the computer, even your mighty HDD (recently we had a situation when one faulty hi-speed SSD has managed to slow down the whole RAID controller, with many parallel sets of disks attached).
 
Back from the theory to practice. Try to find out how to reproduce the crash fast. Put all settings as pessimistic as allowed (1024-2048 buffer size, other audio device, in case possible no audio device at all, no windows update, no other programs running). Every time you can reproduce the problem without some component, you know the problem is somewhere else. Till the problem is in some part you can not exclude (power line, power supply, motherboard), you normally can localize it is reasonable time.

Sonar became very stable for me in X3 and even more stable in 2015, so a month or two ago I finally turned off Auto Save and decided to hit Ctrl+S frequently. The other day, I was so focused on editing and completely forgot to hit Ctrl+S, then Sonar suddenly crashed and I lost about an hour of work. Of course, I immediately turned on Auto Save again (25 minutes here).
 
 

Kamikaze
Guys I think we are missing the point focusing just on this. StuntPickle, can you let us know more about the other 98 problems, maybe we can help there?

 
Yes, and please only include one or two problems per thread if possible, and don't post the threads at once. 

Karyn

mudgel
Audio from the graphics card. what is that?

If you connect a TV or monitor with HDMI it can get an audio feed through the HDMI cable.  This is connected to your graphics card,  the card has drivers loaded that route audio through the graphics card for the purpose of feeding the HDMI link.  The intended use is for large screen TVs.  All of us use dedicated audio interfaces and professional quality studio monitors so this particular function is never (or rarely) used.
 
It has been demonstrated that removing these drivers can improve Sonars performance.   It is unlikely to be the cause of the issues in this thread, but it would not hurt to try.

I have one of my monitors connected via HDMI, but the sound card is not the source of the sound, the HDMI connector passes video and audio. The audio is passed through from the onboard sound chip.all perfectly stable on my system.

John
Your graphics card can be the source of trouble. Mr. Anderton pointed out awhile back that disabling any audio from the graphics card can solve a lot of strange problems.  

I am sure it can, but changing MIDI data because the HDMI driver for the video card is active requires a truly gargantuan leap of imagination.

slartabartfast

John
Your graphics card can be the source of trouble. Mr. Anderton pointed out awhile back that disabling any audio from the graphics card can solve a lot of strange problems. 

I am sure it can, but changing MIDI data because the HDMI driver for the video card is active requires a truly gargantuan leap of imagination.

I will give you an example what can happened, and you decide either you can imagine that
 
Mr. Anderton pointed that this graphics card audio driver (just installed, not in use, from his tests not even completely enabled!) can course  significant increase of generic system latency. After he has removed/completely disabled it, he could decrease the buffer size from 128 to 64 even for relatively big projects (if I remember correctly, it was working for small projects without changes).
 
And in case your overall "fixed" latency (coming from VSTi, some of them have huge, they are thought for mixing/mastering only when that does not matter) is close to your current settings, there could be "no time" to process something else correctly (like MIDI data). For example, a chain of FXes need 18ms of data to work (not CPU dependent, they just "consume" that amount of audio data for the algorithm before they produce any output)  and you want 20ms input->output time, many things should happened exactly during the last 2ms. And in case during that time some driver (like HDMI audio) block the complete system for 2ms, close to everything can glitch.
 
Note, I am not pretending that it works that way. I have never seen Sonar core engine source code. But I mean that I can imagine such dependency...

icontakt
Sonar became very stable for me in X3 and even more stable in 2015, so a month or two ago I finally turned off Auto Save and decided to hit Ctrl+S frequently. The other day, I was so focused on editing and completely forgot to hit Ctrl+S, then Sonar suddenly crashed and I lost about an hour of work. Of course, I immediately turned on Auto Save again (25 minutes here).
 
 

Kamikaze
Guys I think we are missing the point focusing just on this. StuntPickle, can you let us know more about the other 98 problems, maybe we can help there?

 
Yes, and please only include one or two problems per thread if possible, and don't post the threads at once. 

Agreed,
your problems in the first place aren´t Sonar specific (sure this software isn´t  perfect),
it´s the person sitting in front of stuntpickle´s monitor.
 
Sorry , but this has to be said cause of the thread title which obviously has to be changed.

slartabartfast
I am sure it can, but changing MIDI data because the HDMI driver for the video card is active requires a truly gargantuan leap of imagination.

I can't imagine it either, but the OP has enough problems that it makes sense to eliminate all possible sources. Craig Anderton's post yielded a long thread of speculation about this issue. Here it is: 
http://forum.cakewalk.com/FindPost/3103263

I use MIDI-OX to monitor MIDI input. Sometimes I find hardware sending sporadic MIDI data.
 

So basically something is writing data on it's own.  IS this midi data?  Add another track, record but don't input anything and see what happens.  What version of Play are you using?  Play was recently updated.