I can see where the crash happens but for the sake of making reproducing the issue easier, can you maybe provide the file you were trying to export?

As I wrote, the crash is unreliable. I would like to supply you with a version of the file that fails the export, but for exporting the old autosaved file versions I didn't have an issue. It seems to be related to working on a file for some time, just opening and exporting, even changing some things and then exporting seems to work fine with all files I have so far.

Will add a file if I find one.

If you have the possibility to upload larger files somewhere, you could also run OpenMPT with the /fullMemDump command line option. The resulting memory dump file will be much bigger, but it will compress quite well with 7z or RAR (not so much with zip). This would be very helpful.

I found a potential reason for the issue, which should be fixed in r13962 and later (soon available from https://builds.openmpt.org/builds/auto/openmpt/bin.win64/1.29/ ) - however if you can provoke the crash with the current stable version using the /fullMemDump would still be appreciated as it would help understanding how OpenMPT ended up in this situation that led to the crash.

Sure! I don't use OpenMPT very often, but I will run it with that command line option from now on.

I can reliably reproduce the/"a" crash with this file:

1. Open it
2. Go to Instruments Tab
3. Replace the only and only instrument with Piano 1 from SGM-V2.01.sf2
4. Export as MID, just click OK

Thanks for the steps. I can reproduce the problem now. It seems like you forgot to add the link to the memory dump but as I now have a way of reproducing the issue, it is no longer required.

Okay, I can now confirm that the root cause of this issue is in SF2 instrument extraction and thus won't happen after saving and re-loading the module. The root cause was fixed in r13988 and the problem won't happen anymore in the next OpenMPT release.