Synth1 works just fine here, both the 32-bit and 64-bit version. It could of course be another Windows 10 specific issue, but I only have a 32-bit VM to test.
Are you using the latest Synth1 version? Do any of the Windows compatibility options help?

Well, it's V1.13 beta3 from 2014. Should be the latest.
But how can I use Windows compatibility options on a dll ?

You don't, you enable them on mptrack.exe. And please attach the generated crash dump to have a look at.

Compatibility options on mptrack.exe don't do anything for the plugin. And as only the plugin itself crashes, and not openmpt, there is no crash dump (isn't it?).
I will test the plugin tommorow on a different win10/64-system...

Okay, so it seems related to the version of OpenMPT.
I first installed OpenMPT 1.26.14.00 on the other system and Synth1 64bit worked.
Switching to an 1.27 / 1.28 build made the crash return.

And as only the plugin itself crashes, and not openmpt, there is no crash dump (isn't it?).

Sorry, I forgot that you actually got an error message from OpenMPT's plugin handler and not from the crash handler. (If the process crashed, it would not matter which part of it crashed).

I cannot really think of anything right now that would cause the crash that would be new to OpenMPT 1.27, so if you have the time, please perform a regression test:
This is done by downloading various old builds and performing a binary search to find the bug.
The first archive 1.27 version at https://builds.openmpt.org/builds-archive/auto/openmpt-win64/ is r6782 and the latest is r8649. Calculate the average of those two values (7715), find this (or a revision close to it, not every revision will be available on buildbot) and download it. Does it crash? -> Repeat the step by taking the lower bound (6782) and the new upper bound (7715), if it doesn't crash, repeat the step by taking the new lower bound (7715) and the upper bound (8649). This way, you should be able to find the revision at which the fault was introduced in about 14 steps.

Synth1 still works:
openmpt-win64-1.27.00.06-r6997.7z

Synth1 crashes:
openmpt-win64-1.27.00.07-r6999.7z

Interesting. Starting with r6999, test builds were compiled using VS2015 instead of VS2010. No other VST-related changes happened there... (cc @manx)

@Solus:
We will provide special builds for you once we have decided which way to pursue first.

Technical details:

Yes, compiler changed in that revision.

So, the root cause might be a compiler bug, in which case testing the with disabled optimization around VST plugin handling as well as testing with VS2017 might help.

Another thing that could cause the problem is alignment of the actual float buffers which could be a problem if Synth1 uses SSE2 here (in which case it would be a Synth1 bug). As far as I can tell, these buffers are 4 byte aligned, however, I do not see any way how any possible additional better alignment could change between compiler versions by chance.

However, IMixPlugin contains bool bitfields right after the mix buffer, which frankly rings a ton of alarm bells, given out history with this language feature.

In any case, I cannot really see how the possible problems I have describe could actually only affect Win10 and Synth1.

Could you please try each of

• http://manx.datengang.de/openmpt/bugs/1030/vs2015-disable-opt-v1.7z
• http://manx.datengang.de/openmpt/bugs/1030/vs2015-kill-bitfields-v1.7z
• http://manx.datengang.de/openmpt/bugs/1030/vs2017.7z
  and report back for each one whether it does work or not?

As far as I can tell, these buffers are 4 byte aligned

Just a small clarification: Plugin buffers provided by OpenMPT are already manually aligned to 16 bytes (see PluginMixBuffer.h) since basically forever.

Oh, yes, missed that.

The plugin crashes with all three versions.

For what it's worth, I installed a Win10 x64 VM and can reproduce the issue there, but I have no dev environment set up in that VM yet to further analyze the problem; it's very well possible that we cannot fix this if Synth1 makes any assumptions e.g. about memory allocation that are no longer true with VS2015/2017.

Here's another try: https://sagagames.de/stuff/mptrack.exe
This version removes OpenMPT's "safety net" around the plugin processing code, so now it should actually crash the entire process when using Synth1. You should be able to obtain a memory dump from that crash.

Well, now the plugin doesn't crash anymore. It plays the instrument, but only one note at the time. The behaviour is similar to what the plugin does, when I activate "use plugin bridge".

This is really strange. I can now confirm that Windows 8.1 is also affected.

Looking at the disassembly of the crash location a bit more, it looks like a pointer trunction issue to me. In one specific example, Synth1 tries to read from address 49656AB0 but the real address should be A749656AB0 (only the lower 32 bits are preserved). Windows 8 probably changed the process memory layout, and MSVC10's might be using a different heap layout, hiding the issue at hand.
In other words, there is nothing we can do here, but I have notified the Synth1 developer of this issue. Other 64-bit hosts compiled with a recent MSVC compiler should have the same issue as OpenMPT. It's impossible for us at this stage to return to MSVC10.

Well, now the plugin doesn't crash anymore. It plays the instrument, but only one note at the time. The behaviour is similar to what the plugin does, when I activate "use plugin bridge".

In both cases the program actually crashes but is unable to display its crash message for some reason. So the crash is not gone with the bridge, it's just "less visible".

Other developers have faced the same issue with Synth1: https://github.com/teotigraphix/Framework4Bitwig/issues/3
Maybe now that I sent a mail to Ichiro, he will do something about it. ;)

A possible semi-solution would be to disable ASLR at least for the plugin bridge. I wouldn't feel good about disabling it in the main process.

Yes, as a work-around, we could either disable ASLR completely for the PluginBridge, or tame it done to Windows 7 level as described here:
https://blogs.msdn.microsoft.com/oldnewthing/20150709-00/?p=45181
https://docs.microsoft.com/en-us/cpp/build/reference/highentropyva

Longer term, it might even make sense to have 2 versions of the plugin bridge, 1 with all the normal features enabled and 1 with extremely conservative settings. Another aspect which might require providing multiple bridge versions is high DPI support, although that can be implemented during process startup. ASLR however can not (at least, as far as I know).

Another aspect which might require providing multiple bridge versions is high DPI support, although that can be implemented during process startup

OpenMPT already sets this value at process startup, and it's not possible to set it in the plugin bridge again because it's a child window of OpenMPT - I tried that a while ago, and bridged plugins always inherited OpenMPT's DPI (non-)awareness.

OpenMPT already sets this value at process startup, and it's not possible to set it in the plugin bridge again because it's a child window of OpenMPT - I tried that a while ago, and bridged plugins always inherited OpenMPT's DPI (non-)awareness.

In that case, not making the bridge and plugin windows child windows may be another option.

Anyway, this branch of the discussion is getting off-topic for this issue.

@Solus:
We applied the work-around (disabling High Entropy address space layout randomization) in r8984 . 64bit Synth1 will still not work in OpenMPT, however, it should work when using the Plugin Bridge now.
That version will show up in about an hour at https://builds.openmpt.org/ .

Yes, this works. Thanks again for your ongoing and always enthusiastic work on MPT !