You can try adding the following lines at the bottom of your mptrack.ini config:

[Sample Editor]
UndoBufferSize=200

where 200 is the total amount of memory that the undo feature is allowed to consume, in megabytes. If that doesn't help, memory consumption is probably not the reason for this crash but maybe something dodgy in the undo handler. If the crashes don't happen anymore with that setting, please also try a larger setting - try doubling it until it crashes again.

I have experiencig this bug in the past with large samples. I will try your suggestion, but this is possible even if you have 4GB of RAM?

I actually had a very hard time reproducing this bug with 4 GiB of RAM - I first had to increase UndoBufferSize to 4096 (by default it's 1024 if you have 4 GiB installed), create many large samples and copy / paste them a few dozen times; i.e. I have only been to reproduce it under very artificial conditions. If I hadn't set the UndoBufferSize so high, the undo buffer would have stayed at 1 GiB all the time and nothing would have happened.

I have been having huge problems with this myself. It seems more likely to happen with large (5min or longer) samples, or whenever I am doing rapid copy/paste work in the sample tab (ex: taking a drum break and splitting it up into individual samples). I find that I have to force myself to do operations slowly and deliberately to avoid triggering crashes.

Kind of a bummer, this never used to happen in older versions.
(win7/4gb ram)

edit: for what it's worth, this crash is highly repeatable for me even when the sample size in question is not abnormally high. using larger samples simply increases the frequency with which it occurs.

ilkae, can you please also try out the suggested modification in your settings file from the first comment above?

<i>Edit</i>: Also, do you have any other applications running that consume huge amounts of memory, so that less than a gig of RAM is available to OpenMPT?

I added the lines to the .ini file, and while it did seem to reduce the frequency of the crashes, it did not stop them. I have plenty of RAM available to OpenMPT. Copy/pasting/editing sample data will cause this crash more often when working with larger samples, but it is not a prerequisite. Slicing up a 5-6 second long drum beat via copy/paste within the sample tab tends to cause a hard crash about 50% of the time for me. The quicker I try to perform these copy/new sample/paste operations, the more likely a hard crash becomes.

ilkae, please use the latest test version located at http://sagagames.de/stuff/mptrack.exe if you are not doing so already. If it crashes, it should create a memory dump in %TEMP%\OpenMPT Crash Files. If you can reproduce a crash with that version, please zip that .dmp file and upload it here.

"Good" news: I was finally able to reproduce this bug on another machine rather frequently and I have most likely found the cause for this crash.

Ok, revision 1268 / OpenMPT 1.20.01.02 should fix the issue. Please test it: http://sagagames.de/stuff/mptrack.exe

The problem with reproducing the problem was that if there is only one sample loaded into sample slot 1, the crash is not reproducable. There must be an unmodified sample slot before the one you modify so that the crash can happen.

Marking as resolved because of lack of feedback and own tests seem to indicate that the problem is indeed fixed.