Incorrect Versions

[Wodd]

For some reason, I am finding that, upon compiling the source code, OpenMPT simply will not pay Bookworm's music. Perhaps I have some incorrect-version software. I have:
Visual Studio Community 2015 (version 14.0.25123.00 Update 2)
Microsoft .NET Framework (version 4.6.01038)
TortoiseSVN (version 1.9, revision 26833)
The Windows 10 SDK
<FileList
  DisplayName = "Windows 8.1"
  PlatformIdentity = "Windows, Version=8.1"     
  TargetFramework = ".NETCore,version=v4.5.1;.NETFramework,version=v4.5.1"
  MinVSVersion = "12.0"
  MinOSVersion = "6.3.0"
  MaxOSVersionTested = "6.3.0"
  UnsupportedDowntarget = "Windows, version=8.0">

  <File Reference = "Windows">
    <ToolboxItems VSCategory = "Toolbox.Default"/>
  </File>
</FileList>
I don't know how to get version information for the Windows SDK, so I am posting the contents of SDKManifest.xml.
VST SDK (version 3.6.5)
ASIO SDK (version 2.3)
Note to Saga Musix: You had suggested that my modifications to the code were the issue; but even a fresh, unmodified batch of code, OpenMPT will not play Bookworm's music. But, because it works in your test build, I am wondering if I have some bad software versions. Perhaps OpenMPT's code is incompatible with the Windows 10 SDK and I need the Windows 8.1 SDK or earlier. I would like to utilize the new features that you have implemented (especially the long-awaited position jump extension), but I don't want to give up playing Bookworm's music. When the code breaks, it displays line 445 of MixerLoops.cpp.

[Saga Musix]

I have no problems compiling and running OpenMPT using the latest VS2015 toolchain. All I can recommend for now is checking out the source code into a completely new directory and recompile it from scratch - sometimes incremental linking can have weird results. If the problem still occurs, create a full memory dump when OpenMPT crashes from within Visual Studio (using the Debug menu), and then upload your mptrack.exe, mptrack.pdb, mptrack.ini and the crash dump together so I can look at it.

but I don't want to give up playing Bookworm's music.

You could just use the official builds like everyone else.

[Wodd]

I have no problems compiling and running OpenMPT using the latest VS2015 toolchain.

Ah

All I can recommend for now is checking out the source code into a completely new directory and recompile it from scratch - sometimes incremental linking can have weird results.

I did that, but the problem does persist.

If the problem still occurs, create a full memory dump when OpenMPT crashes from within Visual Studio (using the Debug menu), and then upload your mptrack.exe, mptrack.pdb, mptrack.ini and the crash dump together so I can look at it.

Download mptrack_testing.zip.

[Saga Musix]

Can you try the same with a debug rather than release build and if you can catch the same crash? If so, please upload the same set of files for the debug build again.
Edit: And a 32-bit version would be more suitable for debugging if possible.

[Wodd]

I did test a 64-bit debug build and the behavior occurred, although I didn't keep the files because I didn't know that you would want them. I have not tested 32-bit builds. I am currently away from my computer. But, I will upload the 64-bit debug files and test the 32-bit builds.

[Saga Musix]

bookworm.mo3 plays just fine with your build on my end as well, by the way. The crash, as far as I could decipher it from the 64-bit dump, didn't really make much sense, so hopefully a debug build gives more insight.
Can you describe in more detail how / when the crash happened? Right after starting playback, only after a few seconds, etc...

[Wodd]

I have uploaded x64 debug and Win32 (both debug and release) builds to my Public OneDrive page. Following the link in the previous post should work for you. I have not overclocked my computer. Bookworm's music plays problem-free in the 32-bit builds, so I don't have dump files for those. But, I included those builds in case you could compare something and do diagnostics that way.

[Saga Musix]

Thanks, that's a lot more useful than the release build. Please check if applying the attached patch (or updating to r6391) solves the problem in the 64-bit builds.

[Wodd]

I am glad that the debug build helped you. Updating the code to revision 6391 did resolve the issue. Thank you for your help.