I cannot reproduce the bug, but it definitely sounds like something is broken in the plugin, not OpenMPT (it wouldn't be the first time with Tobybear plugins). It sounds like the plugin does not provide enough memory to process VST events, but that is only a wild guess. For that to confirm you can try if the same appears if you remove all notes from the patterns. Also, the dumps are of no use since they don't match my current binary (did you compile OpenMPT yourself?), so no debug information can be accessed.

It's strange, I didn't compiled myself, I've downloaded from http://sagagames.de/stuff/mptrack.exe
If useful, this is the exe I have used: http://dl.dropbox.com/u/35217013/mptrack/bugtracker/318/mptrack.7z

I forgot that I applied some changes to my executable in the meantime, so it was not compatible anymore. Please try again with OpenMPT 1.20.04.06 and create new dump files for that.

This dump is for r1442 https://dl.dropbox.com/u/35217013/mptrack/bugtracker/318/318_mptrack4.7z

This dump was created while playing the example module. This is because after 8 or 10 error dialogs, OpenMPT just puff off (short time to create dump). It's also created with the same Sysinternals Process Explorer.

I'm now trying to get more helpful dumps while I install VS.

You can try with this too: https://dl.dropbox.com/u/35217013/mptrack/bugtracker/318/318_dumps_2.7z

None of these dumps are helpful, since they have not been collected when the plugin crashed. There's no information to collect when the module plays, because obviously everything is fine at that point.
Still, since the crash happens in the plugin, I doubt that it's OpenMPT's fault, and I'm sure the problem can be reproduced in similar ways when using a different host. My best guess would be that the plugin is not prepared properly for receiving MIDI events. Can you check and see if the problem persists if you apply the effect as a global effect instead of applying it to specific instruments?

I have compiled OpenmPT in debug mode, and finally got results. This bug also happen when plugin is used as master and applied to instruments.
Own-build of r1444 as debug.

mptrack.exe, mptrack.pdb and Soundtouch DLL: https://dl.dropbox.com/u/35217013/mptrack/bugtracker/318/DebugEXE.7z

1st Dump: https://dl.dropbox.com/u/35217013/mptrack/bugtracker/318/mptrack_vs.dmp.7z

2nd Dump: https://dl.dropbox.com/u/35217013/mptrack/bugtracker/318/mptrack_vs-2.7z

The rest of the Debug build files: https://dl.dropbox.com/u/35217013/mptrack/bugtracker/318/318_DebugFiles.7z

Another tested module: https://dl.dropbox.com/u/35217013/mptrack/bugtracker/318/DCKillerAsMaster.mptm

Notice that the dumps were generated as different sessions, meaning that in the first test I got this two bugs but I didn't created a second dump in the first try. Then as I want to get bug again, I've runned again until get this exception dialog, and saved as the second dump. Hope this will useful now.

I can still not reproduce the problem on my own, but mptrack_vs-2.dmp shows that this is most definitely a problem with the plugin. Are you sure that you are running the latest version of the plugin? If you are, you should contact the plugin author and tell him that DCKiller most likely doesn't process the effProcessEvents opcode correctly - it possibly doesn't respect the number of events that have been passed.

Another thing you could try is assigning the plugin to the instruments again, and setting set MIDI channel to "1" - if the plugin crashes as soon as a note is being played, my suspicion will be confirmed.

I'll close this is as it's most likely a plugin issue. If you find out more and can show that it's definitely an issue with OpenMPT, feel free to re-open.