When it happens again, it would be interesting to know if

• all samples fail to load, or if smaller samples still load
• do OPL instruments still load?
• does it only happen when extracting samples from a module or also when loading WAV/FLAC/etc. files?

I tried to repeat it, and in case it could be relevant, I had no module open. I browsed like 5-8 different modules in both 32-bit and 64-bit with no sign of the bug.

I can't remember what i really did before triggering it more than a module being open - though I don't dare to guarantee that it won't happen with no module open

It's a bit leaning towards allocation issues, like you first initially thought. Too bad I didn't memory dump the program when it happened, so I could upload it here for wonky-activity inspection :)

I was able to reproduce a similar issue which probably has the same root cause as what you reported. At some point, some sample slots were no longer being replaced with the correct samples but old samples from a previous module were still there instead. It's definitely not a low-memory issues because other, bigger samples were still loading. I'll look into this tonight.

After thinking a bit more about what I just observed, it's clear now what happened in my case, but I don't know if that's the same as what happened to you: In my case, I loaded some MPTM files with external samples, and the external sample association was not cleared. So when loading the next file into the tree view, OpenMPT still tried to load those external samples into the same sample slots. In case the external sample cannot be found, this could explain why the sample data could not be loaded anymore.

Do you have any MPTM modules with (potentially non-existing) external sample associations which could cause the same issue for you?

Ok, nevermind - I repeated step 3-4 for 15 modules and on the 15th module the bug showed up (still with no module open). This is in 64-bit.
Info I managed to collect:

General info of the modules I opened:
Version Created (- Saved) / Module-type
1. 1.28.03.00 / .IT
2. (no version info available) / .MOD
3. 1.27.11.00 / .IT
4. 1.24.04.00 / .IT
5. (no version info available) / .MOD
6. 1.23.05.00 - 1.24.01.. / .IT
7. 1.28.03.00 - 1.28.04.. / .MPTM
8. 1.23.05.00 / .MPTM
9. 1.28.00.33 / .IT
10. Same as previous / .MPTM
11. 1.24.01.00 / .IT
12. 1.28.00.40 / .MPTM
13. 1.28.00.33 / .MPTM
14. Same as previous / .MPTM
15. 1.28.02.00 - 1.28.07.. / .MPTM

Noticed now that up until the last module, I'd loaded two modules created with test-build versions. actually feels like it could be what was causing the bug, but maybe worth a verification.

Let me know if a memory dump would help too, since I have one.

Test builds certainly shouldn't make any difference. But it would still be interesting to know if any of those MPTMs use external samples. If they don't, it would be good to know if it always happens after one specific file from that list has been loaded.

If external samples were involved, the latest build at https://builds.openmpt.org/builds/auto/openmpt/bin.win64/1.29/ should fix this issue. Please test it.

There were external samples yes. I'll try it

I repeated the exact same test, with the exact same modules but also a bunch more to be a bit more sure, and everything seems to work as it should now.

Great to hear, seems like the external samples were indeed the culprit then!