The VU meters on the general tab only show activity for that particular module. Please confirm that the module to which the general tab in the screenshot was actually playing, or if you were playing a different module.

any module

{2223E2DC-2E79-4C04-A506-CD8BB4A19B83}.png (41,249 bytes)   

{2223E2DC-2E79-4C04-A506-CD8BB4A19B83}.png (41,249 bytes)   

{035C2819-AD23-4DCC-9D0D-7246EBEF75B1}.png (48,601 bytes)   

{035C2819-AD23-4DCC-9D0D-7246EBEF75B1}.png (48,601 bytes)   

Unable to reproduce then.

OpenMPT has debug memory dumps, correct? Maybe try one getting one of those and attaching it, along with the module you were playing while producing the memory dump. Make sure to also provide the exact build number of OpenMPT that was used to produce the dumps, as it will make it easier to find the correct debug symbols to use for the diagnosis.

Memory dumps are an operating system feature, not an OpenMPT feature. And no, they are not going to help. The only thing that may potentially help with identifying what's going on is a clearear textual description of reproduction steps, and maybe disabling all those operating system modifications that Vad1m appears to be very eager to apply, it could very well be related to one of those. Also any information on whether it worked on a previous version, and if it still works when going back to that same version.

The only non-standard OS configuration I can glean from those screenshots are a dedicated directory for a soundfont library, and maybe use of a different typeface (which isn’t even much of a modification). Windows Server really does have a Datacenter SKU.

That said, some internal components of Windows Server do work differently from desktop Windows builds. which has been known to cause issues with other software. I’ve seen nobody else running OpenMPT on Windows Server before. If that were the entire issue, I would not be surprised.

Please, you don't need to analyze this for me. You don't know Vad1m's history of bug reports.