There seems to be various people having this issue (excluding f.e. me), so it would be good to know if those cases have something in common. Can you please tell what kind of audio hardware are you using (f.e. Realtek integrated audio)?

My sound device is indeed integrated "Realtek High Definition Audio", however, none of my other audio programs or games that employ DirectSound crash, so I really doubt it is a driver issue. The integrated "Realtek High Definition Audio" is very commonplace on modern systems, so it's quite likely a red herring.

I have been running OpenMPT under WinDBG to hopefully catch the crash in the debugger and generate a crash dump or at least get you a call stack. I assume you will have matching symbols for OpenMPT on your end, but if not, you may want to provide me with a build with matching symbols.

I don't really think it's a red herring because so far it seems to be one thing that's common between crashing installations - it might be just a specific (set of) driver version(s), and it doesn't seem to happen when using ASIO on such soundcards, and also not on f.e. other integrated audio devices.

I have tried debugging instances of OpenMPT that crashed while trying to open the audio device (see the "related" issue for more details), and it seems like the crash always seems to happen in completely unrelated parts of Win32 DLLs. You can try the latest test build (http://sagagames.de/stuff/mptrack.exe), which will create a memory dump automatically if OpenMPT crashes (I have debug symbols for that version).

Okay, I just caught it in WinDBG and got a crash stack for you. This looks like an unhandled exception coming from OLE32 during CoCreateInstance of some audio COM component.

(d38.2294): Unknown exception - code c0000096 (first chance)
(d38.2294): Unknown exception - code c0000096 (!!! second chance !!!)
ole32!`string'+0x9:
76218665 6c ins byte ptr es:[edi],dx es:002b:0458ed10=d8
0:004:x86> !sympath SRV
Symbol search path is: SRV
Expanded Symbol search path is: cacheC:\ProgramData\dbg\sym;SRVhttp://msdl.microsoft.com/download/symbols
0:004:x86> .reload
Reloading current modules
................................................................
.........................................................
0:004:x86> kn

ChildEBP RetAddr

00 0458ed14 76212f59 ole32!`string'+0x9
01 0458f4e4 76219e25 ole32!ICoCreateInstanceEx+0x243
02 0458f544 76219d86 ole32!CComActivator::DoCreateInstance+0xd9
03 0458f568 76219d3f ole32!CoCreateInstanceEx+0x38
04 0458f598 71381aa7 ole32!CoCreateInstance+0x37
05 0458f6ac 7138b20b AUDIOSES!CAudioClientStream::CreateEndpoint+0x2e
06 0458f720 711c9e32 AUDIOSES!CAudioClient::Initialize+0x29e
07 0458f7e4 711c9a1c DSOUND!CEngineRendererConnection::Initialize+0x319
08 0458f80c 711c65f7 DSOUND!CLeapSystem::ConnectRenderer+0xf0
09 0458f848 711c54c3 DSOUND!CLeapRenderDevice::ConnectRenderer+0x121
0a 0458f860 71195a46 DSOUND!CLeapSecondaryRenderWaveBuffer::Connect+0x4d
0b 0458f888 711959b5 DSOUND!CLeapSecondaryRenderWaveBuffer::SetState+0x95
0c 0458f8a4 711c53b8 DSOUND!CDirectSoundSecondaryBuffer::SetBufferState+0x60
0d 0458f8b8 711c5459 DSOUND!CDirectSoundSecondaryBuffer::Play+0x9f
*** ERROR: Module load completed but symbols could not be loaded for C:\Program Files (x86)\OpenMPT\mptrack.exe
0e 0458f8d0 002585db DSOUND!CImpDirectSoundBuffer<CDirectSoundSecondaryBuffer>::Play+0x75
WARNING: Stack unwind information not available. Following frames may be wrong.
0f 0458f904 0020bfb8 mptrack+0xb85db
10 0458f924 7675339a mptrack+0x6bfb8
11 0458f930 773b9ed2 KERNEL32!BaseThreadInitThunk+0xe
12 0458f970 773b9ea5 ntdll_77380000!__RtlUserThreadStart+0x70
13 0458f988 00000000 ntdll_77380000!_RtlUserThreadStart+0x1b

I'v also captured a minidump file using WinDBG. The dump file is too big (157 MB) to attach to the bug, so I have posted it on my personal web server space here: http://c0d3h4x0r.0catch.com/OpenMPT-bug204.mdmp This dump file was created with WinDBG 6.11.0001.404 AMD64.

Dump files usually compress really well to a few dozen MiB, so next time please compress it. :) Anyway, I'll look into this later today, thanks. At least this stack trace already looks more promising than others that I've received.

Hmm... VS2010 says "You cannot debug a 64-bit dump of a 32-bit process, you must collect a 32-bit dump of a 32-bit process". I'm not entirely sure how you managed to a create a 64-bit dump of OpenMPT, but maybe you'll have to use the 32-Bit version of WinDbg?

Also, it seems like the dump was created with OpenMPT 1.19.04.00, not OpenMPT 1.20 - I don't have debug symbols for OpenMPT 1.19 anymore.

Visual Studio sucks as a debugger, use WinDBG, CDB, or NTSD instead. Just use the AMD64 build of WinDBG that I cited earlier to open the dumpfile, and issue the following commands in the debugger once the dump is loaded up:

.load wow64exts
.sympath SRV*
.reload
kn

Yes, the minidump was created for OpenMPT 1.19.04.00. Suggestion for the future: with each official release, publish a .ZIP file containing all the matching PDBs for that build, just like you publish all the matching source for each build. (If you're using VS "solution/project", you can set your "release" build to also generate .PDB files).

Is your "latest test build" linked above (http://sagagames.de/stuff/mptrack.exe) the "1.20" version for which you do have matching symbols? If so, I will install it and see if I can repro again.

<blockquote>Visual Studio sucks as a debugger</blockquote>
It has the advantage that it's the IDE that is being used for developing OpenMPT, so I have direct access to everything I need and what I'm accustomed to.

<blockquote>Suggestion for the future: with each official release, publish a .ZIP file containing all the matching PDBs for that build, just like you publish all the matching source for each build. (If you're using VS "solution/project", you can set your "release" build to also generate .PDB files).</blockquote>
The exe I linked above (which is the latest test build for the current 1.20 branch) is indeed generated with .pdb files, but I only ever keep the .pdb files for the latest test build (I don't usually pursue bug reports that don't affect the latest test version, so if someone reports a bug they should first try the latest test version anyway).

Using your 1.20 test build, the behavior of this repro has changed. Now OpenMPT doesn't crash, it just "does nothing" when I come back to the computer and hit any of the various "play" buttons. Audio playback does not start, pattern view does not start scrolling, etc. Would you like me to break into the process when it is in this state and generate a dump?

I don't have much time for looking into the problem at the moment, but please feel free to create a new dump, using the latest "stuff" version from above (it has been updated in the meantime).

I think I realized why this latest issue was happening. My primary windows audio device is a USB audio interface (not the intergrated Realtek audio), and it went to sleep after a certain period of inactivity. After power-cycling it, then OpenMPT played again as expected. I still have not been able to repro the original crash using your test build, so for now I'd be okay with a "Not Repro" resolution.

I did a very small modification to the DSound code after I was able to catch one of those crashes "Live" - Can you please try if this build makes any difference to the crash behaviour? http://sagagames.de/stuff/mptrack.exe

To get some more clues what's going wrong, I've added some message boxes now, so if a weird message saying "WTF! ..." pops up, please tell me - I need to know the exact message.

Please check if this still happens with the latest version of OpenMPT: http://sagagames.de/stuff/mptrack.exe

I'll close this for now as there is a big chance that this has actually been fixed. If the bug reoccours, please let me know!