DOSBox-X frequently hangs on exit

[logiclrd]

Describe the bug

If I run DOSBox-X and then type EXIT or close the window right away, then it exits. If I run QBX, run some programs, and then type EXIT, then it exits. But, if the window has been open a long time with on-and-off use, then often when I type EXIT or try to close the window, DOSBox-X becomes unresponsive and must be killed with Task Manager or TASKKILL or what have you. I have tried to deliberately trigger it but haven't been able to find out what the threshold is.

Steps to reproduce the behaviour

1. Run DOSBox-X.
2. Use it to run QuickBASIC.
3. Keep it open for a long time, periodically do more stuff with it.
4. ???
5. Try to close the window (either with the window X button or by entering EXIT).

If the bug triggers, DOSBox-X becomes unresponsive and can only be killed externally.

Expected behavior

DOSBox-X exits.

What operating system(s) this bug have occurred on?

Windows 10 22H2

What version(s) of DOSBox-X have this bug?

2026.01.02

Used configuration

Output log

Additional information

No response

Have you checked that no similar bug report(s) exist?

• I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

[logiclrd]

I have an instance in this state right now. I've attached a debugger and can obtain stack traces, though the DOSBox-X distribution doesn't include the dosbox-x.pdb file.

In this current process which hung when I tried to EXIT, the main thread has the following stack trace:

ntdll.dll!NtWaitForAlertByThreadId()
ntdll.dll!RtlpWaitOnAddressWithTimeout()
ntdll.dll!RtlpWaitOnAddress()
ntdll.dll!RtlpWaitOnCriticalSection()
ntdll.dll!RtlpEnterCriticalSectionContended()
ntdll.dll!RtlEnterCriticalSection()
wdmaud.drv!CWasapiRenderer::GetCursors(__int64 *,unsigned __int64 *,__int64 *,unsigned __int64 *)
wdmaud.drv!CMicrosoftGSWavetableSynth::GetTimeNow(__int64 *)
wdmaud.drv!CMicrosoftGSWavetableSynth::SendMIDIEvent(struct MIDI_TIMESTAMP *,unsigned int,struct MIDI_TIMESTAMP *)
wdmaud.drv!CMIDISynthTask::MODMReset(unsigned __int64,unsigned __int64,unsigned __int64)
wdmaud.drv!SwModMessage()
wdmaud.drv!modMessage()
winmmbase.dll!midiMessage()
winmmbase.dll!midiOutReset()
midimap.dll!modMessage()
winmmbase.dll!midiMessage()
winmmbase.dll!midiOutReset()
dosbox-x.exe!00007ff7aa5bb387()
dosbox-x.exe!00007ff7aa5bd279()
dosbox-x.exe!00007ff7aa5bd36a()
dosbox-x.exe!00007ff7aa789057()
dosbox-x.exe!00007ff7aac4ba6b()
dosbox-x.exe!00007ff7aac4b7f5()
dosbox-x.exe!00007ff7aab88142()
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()

There are 18 threads in all, and 3 of them have their entrypoint within dosbox-x.exe.

I cannot reproduce this on-demand, but if I create an instance and keep it open for days, using it here and there, at some point it gets into the state where this happens.

I will leave the debugger attached to the hung process for now, in case there's anything to be gleaned from it. (Let me know what to check for/try if so.) If you want me to try to reproduce it with output logging enabled, I can do that but it will almost certainly be days, at a minimum, before it recurs.