https://bugs.winehq.org/show_bug.cgi?id=37983
--- Comment #3 from Sebastian Lackner sebastian@fds-team.de --- Created attachment 50634 --> https://bugs.winehq.org/attachment.cgi?id=50634 Log with WINEDEBUG=+module and winedbg stack trace
The attached log shows that this is indeed a ntdll/loader problem.
* The game loads the native winmm library. * While resolving the forwarded export "system32\winmm.waveOutClose" the builtin dll is loaded. * While fixing up the imports for the native library (load_builtin_callback -> fixup_imports -> import_dll), additional libraries (ole32, msacm32) are loaded as dependencies. * Those dependencies also try to import winmm. Unfortunately they are also affected by the hook, so they don't get the builtin library, but instead the native lib.
This recursive loading situation is not handled properly by the Wine loader. This has the effect that wm->deps[i] is referenced before it was initialized (in the attached log it contained the garbage value 0x640000). To demonstrate this a bit better you can also apply the following patch:
--- snip --- diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c index e1444d2..0405cf5 100644 --- a/dlls/ntdll/loader.c +++ b/dlls/ntdll/loader.c @@ -884,4 +884,7 @@ static NTSTATUS fixup_imports( WINE_MODREF *wm, LPCWSTR load_path ) wm->deps = RtlAllocateHeap( GetProcessHeap(), 0, nb_imports*sizeof(WINE_MODREF *) );
+ for (i = 0; i < nb_imports; i++) + wm->deps[i] = (void *)0xdeadbeef; + /* load the imported modules. They are automatically * added to the modref list of the process. --- snip ---
I am not sure how exactly this issue can be fixed (besides the workaround above), but probably some other people more experienced with the wine loader area can take a look.