Screenshot of error from Visual Studio 2022 (vs2022win10.sln): https://onedrive.live.com/?cid=00BD6492FE45944E&id=BD6492FE45944E%21613240&parId=BD6492FE45944E%21116&o=OneUp

Based on the screenshot, one thing you could try is adding #include "AudioCriticalSection.h" (minus the HTML garbage Mantis is inserting there) on line 29 of Snd_fx.cpp and then add CriticalSection cs; on line 1244 (before if(retval.targetReached || target.mode == GetLengthTarget::NoTarget)).

I have tested the behavior in an attempt to identify the crash location as you had requested. However, it appears to be variable. Upon opening the module that I sent you the link to for testing, the crash occurred while navigating to pattern 718. However, after force-terminating the software, reopening it, reopening the module, and performing the same steps, the crash occurred upon attempting to navigate to pattern 78. I added the lines that you suggested and the crash is still present. So far, since adding the lines I have tested the behavior through the debugger twice. The exception that I took the screenshot of the first time was thrown in the first debugging session (while attempting to navigate from pattern 1,166 to pattern 1,230 [?] [It might have been while navigating from pattern 1,230 to pattern 1,294.]). However, the second session went further into the module and threw a different exception (while attempting to navigate from pattern 1,934 to pattern 1,998). Screenshot of the second exception: https://onedrive.live.com/?cid=00BD6492FE45944E&id=BD6492FE45944E%21613243&parId=BD6492FE45944E%21116&o=OneUp

Right, the second line has to be placed before line 1242 instead.

That appears to have fixed the issue. I did observe, however, that, sometimes, upon pressing Enter to navigate to the next target, the navigation fails to execute and it remains on the current pattern (example: While attempting to navigate from pattern 654 to pattern 718, the module remains on pattern 654 while the Go To… dialog closes as expected. Sadly, because that behavior does not throw any exceptions in the code, troubleshooting it might be much more difficult. That might be caused by pressing Enter too quickly and not allowing OpenMPT to properly calculate the time stamp, causing it to “not know where to go.” Because it “does not know where to go,” it does not move. From what I can see of it, however, the main issue of this thread appears to have been resolved by moving the lines that you mentioned up. I have not seen OpenMPT crash yet since that. I observed only the oddity of failed navigation. To try to reproduce the bizarre navigation behavior, you can try opening the Go To dialog (via keyboard shortcut), quickly press Tab 2 times, type a number in and press Enter. This has occurred with 2 tested modules so far, one of which being the one linked to in this thread (Has Paul Burkey Played Any of the Commander Keen Games Before¿). I know that this behavior should probably be treated as a separate thread. But:

1. Some people greatly frown upon “double posting.”
2. I figure that, since it is also related to the Go To dialog, I would at least mention it. A problem cannot even have an attempt at being corrected (even if the attempt is unsuccessful) if it is not known.

r17094 fixes the crash in a slightly different way.

I did observe, however, that, sometimes, upon pressing Enter to navigate to the next target, the navigation fails to execute and it remains on the current pattern

I see no possibility how that could happen (and it definitely would not caused by this change), but you could add some debug logs in CPatternGotoDialog::OnOK to figure out if the dialog really jumps to the location you just typed in, and if you find a way to reproduce that, open a new issue (posting two unrelated things in the same issue is more akin to double-posting than creating separate issues for separate bugs).