scook
Maybe "Zero Controllers When Play Stops" is enabled. This is a per-project setting found in Preferences > Project > MIDI

Yep, but that wern't it either. Unchecking both options (zero controllers, searchback), had no effect whatsoever.

Try disabling non-destructive midi editing in preferences when you make the changes. Send the midi file to me @ arvidpeterson at gmail dot com. And I'll check it with a hex inspector to see if anything is going on in its guts.

swamptooth
Try disabling non-destructive midi editing in preferences when you make the changes. Send the midi file to me @ arvidpeterson at gmail dot com. And I'll check it with a hex inspector to see if anything is going on in its guts.

Nope, disabling non-destructive MIDI editing didn't help either. Files should be on their way.
Thanks

Could it be that distortion setting is the preset setting?  If so you will need to insert a CC93 to set the distortion level at a different setting.

I have had the same thing happen on a softsynth before; if I remember correctly it was the B4II distortion setting..  I had to insert a CC setting at the start of the track so it would go to where I wanted it to go.

If you do have a CC93 at the start of your file then I'm lost.

I'm pretty sure I know what's going on because the cc is assigned to 93.  I'll have a look in an hour or two and post back.  Thanks for the files - happy to help. 
 

Update:
I wrote a C++ program to filter out all of the CCs except the mod wheel from a midi file and ran the original file through it. The original file contained several CC 93s (chorus depth in GM). After running the file through my nifty little filter I no longer have a problem with the distortion amount getting reset on my Sylenth. Sylenth is particularly susceptible to this kind of issue because it doesn't use the GM spec for its CC assignments (every control is mapped to a CC). I suspect that you would never see the problem if you used a keyboard or soft synth that ignores CCs or responds in a GM compatible way. I always wondered what was going on, now I know.
However, it seems to me that it's a relatively serious bug in Sonar that deleting all CCs in the Event View doesn't really delete all the CCs, some of them still hang around (maybe only the ones that reset the values to zero, maybe it detects that the track set something to a value other than zero then automatically zeroes it when the transport starts, I dunno). If it's resetting controllers that get changed automatically, it should also detect when the controllers get deleted and remove the reset. It might be nice to have a dialog that would allow you to disable things it does automatically on a track by track basis, ideally it would also allow you to tell Sonar to delete the reset entirely.
I don't know what Sonar is doing in the bowels of the MIDI editing code but I don't think it should be remembering stuff you told it to forget about and then not telling you about it.
Anyway, now I have a program I can use to clean out midi files before importing them into Sonar.
EDIT: It's not a bug, it's a feature... see below.

Hey Tom, 
It's not a bug, it's a feature!
 
I looked at the files and yes, there are track header messages setting cc93 among other things in the midi file.  Sonar creates by default what Cakewalk calls a General Midi setup measure.  This essentially embeds all GM messages like patch changes and GM cc values that occur at the start of the track in the project and hides them in the event list.  You can see this because there are programs in the inspector and the chorus and reverb midi controls in several tracks are at a value other than 0 but they aren't in the event list.  
You can disable this by editing the ttsseq.ini  (found in C:\Users\<username>\AppData\Roaming\Cakewalk\SONAR X3 Producer) file by adding the following line in the [Options] header:
GeneralMidiSMFs=0.  
 
Here's the help page - TTSSEQ.INI
 
When you add that line, restart sonar, and open the midi file this is how your event list will appear:
Hope this helps!

 
 

I think what might be happening is that when a MIDI file is imported. Sonar analyzes the tracks and every time it sees a CC it adds a zero for that CC to the track pre-roll message list. When you edit the track and remove all the CCs Sonar doesn't reanalyze the MIDI so the pre-roll CC zeroes stick around forever. If you remove all the CCs then save the project as MIDI and re-import it, Sonar analyzes the MIDI, doesn't find any CCs so it doesn't add anything to the pre-roll message list. This explains the behavior I saw when I saved the test project as MIDI then re-imported it.
I need a re-analyze MIDI button or a way to edit the pre-roll list, running MIDIs through the filter works but shouldn't be necessary.
EDIT: This was incorrect, see below.

Nope, it's the midi setup measure - because it's hiding the options as initial settings that are only able to be edited in the inspector.  This is useful in a lot of instances, but not in others as when using sylenth which uses GM mapped cc's as defaults.  The only two options are to insert ccvalues overriding the initial ccs in the midi file or to just set the ttsseq option.  The latter is the only foolproof way.  

here's your bass track - if you notice there is a midi cc93 of 0 in the midi file itself.  Sonar is not adding anything, just importing the file. 
 

 
EDIT -
here's what the synth bass track in the midi file looks like I've highlighted the b1 5d values on the track which are cc93 change parameters followed by a value of 00 which is 0. You can read about the hex values for midi messages here:  MIDI Messages