Hmm, interesting...  I was just trying to create a very simple project -- one Dimension Pro track with the same setup as noted above (sound on sound, data in a take lane, and take lanes showing; recording MIDI) for the possibility of submitting a bug report.  This time, I saved the project as noted above, then started to record on the same track.  I didn't even get as far as stopping the recording, and it crashed.  The crash was different, though -- i.e. not heap corruption, but an access violation, and this time in the Dimension Pro DLL instead of ntdll.dll.  I just hope the workaround of turning take lanes display off when recording truly does work.  This is the first I've tried recording with Lexington, and I'd really prefer not to have to revert.
 
Here is the application event log information from this simpler case:
--------------------------------------------
Log Name:      Application
Source:        Application Error
Date:          1/10/2016 4:19:06 PM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      RP-Studio
Description:
Faulting application name: SONARPLT.exe, version: 21.11.0.25, time stamp: 0x566ebb2c
Faulting module name: Dimension Pro x64.dll, version: 1.5.0.11, time stamp: 0x4c7bcaa6
Exception code: 0xc0000005
Fault offset: 0x00000000000bc5da
Faulting process id: 0x1834
Faulting application start time: 0x01d14c01614b06be
Faulting application path: C:\Program Files\Cakewalk\SONAR Platinum\SONARPLT.exe
Faulting module path: c:\program files\cakewalk\vstplugins\Dimension Pro\Dimension Pro x64.dll
Report Id: 912291f6-32b9-429b-a6fa-966f85b2bce1
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Level>2</Level>
    <Task>100</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2016-01-11T00:19:06.472663300Z" />
    <EventRecordID>6310</EventRecordID>
    <Channel>Application</Channel>
    <Computer>RP-Studio</Computer>
    <Security />
  </System>
  <EventData>
    <Data>SONARPLT.exe</Data>
    <Data>21.11.0.25</Data>
    <Data>566ebb2c</Data>
    <Data>Dimension Pro x64.dll</Data>
    <Data>1.5.0.11</Data>
    <Data>4c7bcaa6</Data>
    <Data>c0000005</Data>
    <Data>00000000000bc5da</Data>
    <Data>1834</Data>
    <Data>01d14c01614b06be</Data>
    <Data>C:\Program Files\Cakewalk\SONAR Platinum\SONARPLT.exe</Data>
    <Data>c:\program files\cakewalk\vstplugins\Dimension Pro\Dimension Pro x64.dll</Data>
    <Data>912291f6-32b9-429b-a6fa-966f85b2bce1</Data>
    <Data>
    </Data>
    <Data>
    </Data>
  </EventData>
</Event>

And just to add a little bit more, there are three scenarios I saw with the simpler case:
 
1) The one described above with the access violation happening before I could even press the spacebar to stop recording.  I saw this twice in 4 tries to recreate the problem.
2) The same heap corruption issue I saw consistently with my real life project, where the heap corruption occurs after pressing the spacebar to stop recording.  I saw this 1 time in my 4 attempts.
3) A scenario that did not crash at all.  Specifically, in my second attempt to recreate the problem with the simpler project, I got delayed in juggling my computer keyboard and MIDI controller, and I didn't actually start recording the new MIDI part until after the end of the first one (a few lines from "Mary Had a Little Lamb").  Thus, the two takes did not overlap, so it just put the second part in the same take lane as the first one.
 
#3 would seem to reinforce the notion of the problem occurring at the point of creating a new take lane.  However, I haven't figured out what is different about #1 and #2 -- perhaps something relating to whether I start playing notes before or during the first take's left clip boundary?  In any event, my different results on this same project may serve to reinforce some of the different results noted above.  I never once got the Fault Reporter, though.  But maybe that is more likely to happen if using the Comp setting instead of Sound-on-Sound or something.  Or maybe it matters if you're using 32-bit versus 64-bit?  Or...?
 
Time to submit a bug report, then try to get back to work on my real project, hoping the workaround will, you know, work...
 
EDIT:  Well, I *tried* to submit a bug report, including uploading a small project.  At the end of it, it told me, "the Internet is Broken.  Well at least our little corner of it is."  I'm not sure if that means the report didn't get submitted at all, got submitted without the sample file, or...  It's too much of a pain going through the steps to try again, so hopefully others' reports, along with this forum entry, will get the problem fixed. 
 
One other thing I should add is that I have "store takes in a single track" and "create new lanes on overlap" set. For those who are not seeing the problem, perhaps there could be a difference in this area?  These are the settings I always use, but I think the last time I was doing tracking like this was approximately November 22nd -- I'm not sure what iteration of SONAR Platinum was the latest at that point, so I don't know if this issue is new with Lexington or possibly crept in somewhere between the Ipswich noted above and Lexington.

Hi folks,
We were able to repro and fix a crash with midi recording multiple take lanes.
I think a workaround for now may be to not open midi take lanes while recording, since the crash is in the ui.
Once it's recorded you should be able to on open lanes for editing.
Sorry for the inconvenience.

Hi Noel, yes, I confirmed earlier that the workaround worked, and it's good to hear a fix is in the works. 
 
However, and I don't know if this is related to the bug you found and fixed or not, once it got to the point of editing the same project, the project was all of a sudden painfully slow on the UI front (e.g. expanding the height of take lanes, zooming in and out horizontally, etc. -- in fact, during the process of using the workaround it was even slow stopping recording of a take to be able to open the take lanes, mute the most recent take, close the take lanes, then start recording the next take, but there did not seem to be any audio engine issues in doing that recording, and the MIDI takes came out fine), and it ended up having some other issues. 
 
In the latter category, trying to do splits with the split tool within takes sometimes behaved consistently weird (e.g. doing a "lasso split" across all the takes only split the tracks that had data inside the lasso area, rather than splitting all of them, for example to split the start portion of the clip from the end portion of the clip -- the user-level idea was to split phrases, where a few of the takes had "noise" between phrases) and sometimes less consistently weird (sorry, it's harder to describe this as I was just trying to find workarounds for the consistently weird one to do the same trick, and the slowness in the UI was also making it tough to figure out what was going on).
 
Looking forward to the fix.

Noel Borthwick [Cakewalk]
Hi folks,
We were able to repro and fix a crash with midi recording multiple take lanes.
I think a workaround for now may be to not open midi take lanes while recording, since the crash is in the ui.
Once it's recorded you should be able to on open lanes for editing.
Sorry for the inconvenience.

 
I didn't use multiple take lanes. I used the overwrite mode and simply replaced my scratch piano.

I opened a file started in Lexington 64 bit the previous day and started to replace my scratch piano part (Ivory Piano). I started at the beginning and played the whole song through 1x and at the end of the song, I hit stop and I got the Sonar Fault reporter box with a crash. I opened 32 bit Ipswich and had no problems for the rest of the day


Once the problem is fixed do you think it'll fix the problem I had also?