I think everytime this happened in the past, it was related to specific VST plugins. Are you using any plugins when this happens?

No. It happens even when I have not loaded any modules. I'm not sure if this is a pattern yet, but it seems to happen pretty consistently if I make any changes in the preferences and then close the program. If I just open the program and then close it, so far the problem does not occur.

Ok, then please grab THIS version of OpenMPT first: http://sagagames.de/stuff/mptrack.exe
Then create a memory dump as described here: https://wiki.openmpt.org/Manual:_Frequently_Asked_Questions#OpenMPT_crashed_but_did_not_create_a_memory_dump
Compress it (it will be huge but 7z should compress it pretty well) and upload it somewhere to have a look at it.
(Clarification: Create the memory dump while OpenMPT is seemingly frozen)

Ok, here it is.
https://content.wuala.com/contents/CarlosOne/Wuala/mptrack_DMP.7z/?dl=1&key=fWux0Ju2OVa7

Well, that's not very helpful - the code is paused in MFC's message loop, i.e. no OpenMPT-specific code.
Can you summarize the steps you took while creating this memory dump?

Oh, I also noticed that one of the threads is referring to dsound.dll. Using DirectSound is a very bad idea, and I can now recall some issues related to DirectSound, so can you please try switching to a WASAPI output device in OpenMPT instead?

After making a change in the preferences and closing OpenMPT, I made sure the process was still in memory and then followed the steps described in the link to the FAQ you posted to create the memory dump. I.E. Using the 64 bit version of Task Manager. And I am using ASIO, not DirectSound so I'm not sure what that's all about.

Nevermind, it seems like dsound.dll may turn up in the thread stack no matter if DirectSound is actually used for playback or not.
What kind of changes did you do to the preferences? Is it enough to just open the settings dialog and press OK? Does the same issue occur when just opening OpenMPT and closing it again?

Indeed, I just checked and pressing "OK" or even "Cancel" after opening the settings dialog seems to be enough. However, just opening and closing OpenMPT is not.

If it might help, I could try creating another memory dump using ProcDump, but I'm just not sure what parameters to use.

You can try creating another dump to see if it would hang in different place, but the tool used to create the dump won't make a difference.
Both manx and me think that it's likely that a bad audio or MIDI driver is the culprit, since OpenMPT will query all available drivers when opening the setings dialog.

I will do some further testing, but there may be a limit as to which drivers I can conveniently disable since I rely on them for audio from my screen reader. Although there are a couple. I already tried disabling the virtual MIDI driver I have been using and it made no difference.

Did you do any further testing or did this issue maybe even disappear altogether?

The issue still exists, but I have not been able to determine which driver might be causing the problem.

You can feel free to close this one though if you like since it seems to be specific to my system.

Since you mentioned that the issue also happened with the previous builds, it might help to localize if the problem always existed (in which case we are unlikely to be able to fix this) or if a specific version introduced this problem.
For this, you can get some old builds from ftp://ftp.untergrund.net/users/sagamusix/openmpt/archive/openmpt/ and locate the first version that caused the problem. It's probably not necessary to test versions older than 1.21 since OpenMPT 1.22 was the first version to contain considerable changes in the audio code. Also besure to select the same driver settings / etc. in OpenMPT to reproduce the issue.

Okay, I will see about testing some older versions.

Hmm, the problem still seems to occur with version 1.21, and even 1.20. Same driver settings.

I fear we can't do anything about it then. ASIO driver, I assume?

Yep ASIO.

And you have no issues with other programs using the same ASIO driver?
I don't really know if there's anything we can do, but I'll let manx have the final say.

Well, I've experienced some annoying behavior from Creative's poor excuse for ASIO implementation occasionally, but not with processes hanging in memory.

Just opening the settings dialog and immediately closing it again should touch neither sound devices nor midi devices. These will only get accessed when navigating to the respective property page. Thus, can you please try to determine if the hang when closing OpenMPT is caused by selecting to MIDI settings page or by selecting to Sound card settings page?
Before making any further suggestion, I just want to make sure the problem is really caused by sound card drivers.

That is interesting, so it is possible that the problem may not be driver related because it occurs when opening the "Setup" dialog even if the "General" tab is selected and no other tabs are accessed. And yes, I did test again just to verify this point.

Really interesting. So either the general settings page does something weird (from a read through the code, I did not find anything suspicious yet, though) or something is causing all property pages to get initialized when opening the dialog.
In any case, I just added a "Save now" button in the "Advanced" settings in r5365 (will appear at the usual place with the usual 30min to 60min delay). This should at least give you the possibility to change settings and actually save them. Does not fix the real problem of course.
Could you then try setting [Components]BlockASIO = 1 in the advanced settings, save it, and restart OpenMPT and see if the hang goes away? You will not be able to use ASIO in the case it is blocked, of course.

Did you mean r5365 or r5364? The version I just downloaded says r5364 in the "About" dialog, but the "Save now" button is still in the "Advanced" tab. In either case, I changed "BlockASIO" to 1 as you indicated and unfortunately the hang still occurs. I did verify that the change was actually saved. Although that "Save now" button is still useful in the mean time. Does it save all changes made in the "Setup" dialog or only those specifically made in the "Advanced" tab?

r5365 or r5364 did not matter, r5365 just saves some more settings (not relevant to the particular problem at hand).
"Save now" will save at least all settings shown in the advanced tab. In practice it will save almost everything that a normal OpenMPT closing would also save. There may be some very few settings missing which have not yet been converted to the newer settings framework internally and get only updated only at weird times during program execution. I do not know of any such setting right now, but there may be some (which should get fixed eventually).

So, we ruled out any ASIO driver being the cause for the hang. You may try blocking the other soundcard driver types (BlockPortAudio and BlockDirectSound, please block both of these at the same time as PortAudio includes support for DirectSound internally). You may even try BlockWaveOut (however that would be by far the least likely soundcard driver type to cause problems).
If all that does not help either, we at least have ruled out that the problem is caused by any soundcard driver. Which would at least be another data point.

Okay, using r5365 I blocked DirectSound/PortAudio at the same time and then WaveOut for the sake of completeness. The process still hangs in memory.

For the sake of completeness, can you maybe check a few more old versions? Maybe start by checking the first release of every major release (i.e. first 1.18 release, then first 1.19 release, etc).
(Oh, and in case it's not obvious, it would be best to either use the portable mode in the installer or backup your existing mptrack.ini so that your existing configuration won't break.)

No worries, I always backup anything important.

I tested with versions 1.17.02.36, 1.18.00.00 rc0, and 1.19.01.00. The problem occurs with all of these versions. How strange. I wonder for how long this may have been taking place without me even realizing it? I obviously don't check Task Manager after closing every application. Just out of curiosity, I even took a few minutes to test on my old machine and the problem does not occur on that system. Clearly something in my current setup is making a difference, but I've shut down just about every application I can think of so I'm not sure. I've had my current system for a bit over a year now.

Hm, very weird. Does it also happen if you just open the settings dialog but hit cancel instead of OK?

One of the few remaining ideas I have would be that it could be related to your screen-reading software. If it's possible, you could try disabling it for OpenMPT, open the settings dialog, close it and see if the process remains alive then as well. Otherwise, since the settings dialog shouldn't really interact with anything if you just open the first page of it, I cannot quite imagine how anything else specific to your system could cause this.

The same happens whether I select OK, Cancel, or Escape to close the dialog. Well surprise surprise, when my screen reader is not running, the problem does not occur. Sigh, I had actually considered this possibility, but not seriously since the problem does not occur on my old machine which is of course running the same screen reader.

Now that's an interesting turn! I don't really know why your screen reader would barf at OpenMPT like this (and not other programs!), since all the settings dialog consists of is really just a default property sheet filled with some dialogs. Just out of curiosity, can you maybe open a module, open the find&replace dialog, close OpenMPT and see if it hangs as well? There is really nothing special about the settings dialog, except that it uses a property sheet, which the find&replace dialog uses as well (I think they are the only two dialogs which use it). If both of them cause the freeze, your screen reader software might have some trouble with property sheets. Are there maybe any updates available for the screen reader?

Thanks to both of you for hanging in there even though it turned out not to be OpenMPT.

The process does not hang if I open the find/replace dialog.

So, I guess I'll close this then since it appears to not be OpenMPT's fault and only happens with a specific version of a specific screen reader. I'd suggest you notify the developers of the screen reader about this problem, since I don't think we can do anything about this issue here.