wine dll loader

[Vyacheslav Napadovsky]

Hello.

I'm developing .dll plugin for thirdparty software. In Windows 8.0 all
works fine (my plugin loads and unloads correctly),
but in wine, I got
DLL_PROCESS_ATTACH, then 7 DLL_THREAD_ATTACH at plugin loading stage and
only 1 DLL_THREAD_DETACH at plugin unloading,
i.e my plugin remains active (because no DLL_PROCESS_DETACH came in).

Maybe that's because I spawn new thread (CreateThread) at
DLL_PROCESS_ATTACH.

Please, suggest ways to debug this issue.

Regards,
Vyacheslav Napadovsky

[Dmitry Timoshkov]

Hi Vyacheslav,

Vyacheslav Napadovsky  wrote:
> I'm developing .dll plugin for thirdparty software. In Windows 8.0 all
> works fine (my plugin loads and unloads correctly),
> but in wine, I got
> DLL_PROCESS_ATTACH, then 7 DLL_THREAD_ATTACH at plugin loading stage and
> only 1 DLL_THREAD_DETACH at plugin unloading,
> i.e my plugin remains active (because no DLL_PROCESS_DETACH came in).
>
> Maybe that's because I spawn new thread (CreateThread) at
> DLL_PROCESS_ATTACH.
>
> Please, suggest ways to debug this issue.

Is it possible to provide a maximally stripped down/simplified source
that replicates the problem? Feel free to open a bug report and attach
everything you think appropriate there. Also please specify Wine version
you are working with.

[Vyacheslav Napadovsky]

2016-03-01 18:28 GMT+03:00 Dmitry Timoshkov :
> Is it possible to provide a maximally stripped down/simplified source
> that replicates the problem? Feel free to open a bug report and attach
> everything you think appropriate there. Also please specify Wine version
> you are working with.

I asked for the way to debug it myself.
I know I should start monitoring the .dll module reference counter, but I
don't
know how to do that within Wine.

The plugin is too complex itself as well as third-party software that uses
it.
I'll try to minimize the issue example anyway.

The issue might be because Wine somehow adds additional reference for my
plugin
while Windows 8.0 does not. I spawn the background thread (CreateThread) at
DLL_PROCESS_ATTACH event. The background thread runs all time plugin
loaded (I terminate it at DLL_PROCESS_DETACH event). Thus I do not
explicitly
increment dll module counter when I spawn the thread, maybe that's the
reason
Wine loader works different.

[Vincent Povirk]

> I know I should start monitoring the .dll module reference counter, but I
> don't
> know how to do that within Wine.

Try running with the environment variable WINEDEBUG=loader. If you
need more context, you can also try WINEDEBUG=relay,tid,loader.

[Vyacheslav Napadovsky]

Thank you, Vincent for advice.

After some investigation I've come to conclusion that
std::this_thread::sleep_for may cause .dll unloading if I'm using
Windows native msvcr120.dll.
And I have to use native msvcr120.dll because some functions that my
thirdparty libraries requires are missing.
Can you please advice further steps to fix this issue (because I think
some other apps may be affected by it)?
// for my app I'm already figured out architecture (init/deinit)
redesign outside DllMain.

With Windows' native msvcr120.dll

Wine-dbg>bt 0x3a
Backtrace:
=>0 0xf77b3440 __kernel_vsyscall+0x10() in [vdso].so (0x00000000)
  1 0xf74d0de7 syscall+0x26() in libc.so.6 (0x00000000)
  2 0x7bc3dbc6 RtlpWaitForCriticalSection+0x1c5() in ntdll (0x02e1e338)
  3 0x7bc3e72b RtlEnterCriticalSection+0x5a() in ntdll (0x02e1e378)
  4 0x7bc58087 LdrUnloadDll+0x56() in ntdll (0x02e1e3d8)
  5 0x7b85c079 FreeLibrary+0x38() in kernel32 (0x02e1e408)
  6 0x02ad1808 in msvcr120 (+0x51807) (0x02e1e458)
  7 0x028dc855 std::this_thread::sleep_for<__int64,std::ratio<1,1000>
> +0x54(_Rel_time=0x2e1e4a8) [c:\program files (x86)\microsoft visual

studio 12.0\vc\include\thread:162] in srv-mod (0x02e1e498)
  8 0x0292e4c1 spdlog::details::async_log_helper<dllthread>::sleep_or_yield+0xa0(now=0x2e1e4d0,
last_op_time=0x2e1e9ac)
[c:\users\vyacheslav\projects\server\thirdparty\spdlog\include\spdlog\details\async_log_helper.h:357]
in srv-mod (0x02e1e4b0)
  9 0x0292cc82 spdlog::details::async_log_helper<dllthread>::process_next_msg+0x121(last_pop=0x2e1e9ac,
last_flush=0x2e1e9a4)
[c:\users\vyacheslav\projects\server\thirdparty\spdlog\include\spdlog\details\async_log_helper.h:310]
in srv-mod (0x02e1e978)
  10 0x0292f3cf
spdlog::details::async_log_helper<dllthread>::worker_loop+0x7e()
[c:\users\vyacheslav\projects\server\thirdparty\spdlog\include\spdlog\details\async_log_helper.h:260]
in srv-mod (0x02e1e9fc)
  11 0x0292fef8 dllthread::threadstart+0x27(param=0x1b72908)
[c:\users\vyacheslav\projects\server\common\eserver\dllthread-win32.cpp:82]
in srv-mod (0x02e1ea08)
  12 0x7bc83c40 call_thread_func_wrapper+0xb() in ntdll (0x02e1ea18)
  13 0x7bc86e9d call_thread_func+0x7c() in ntdll (0x02e1eae8)
  14 0x7bc83c1e RtlRaiseException+0x21() in ntdll (0x02e1eb08)
  15 0x7bc8efb8 in ntdll (+0x7efb7) (0x02e1f358)
  16 0xf759ff70 start_thread+0xcf() in libpthread.so.0 (0x02e1f428)

With Wine's internal msvcr120.dll

wine: Call from 0x7b83d0c2 to unimplemented function
msvcr120.dll.?_Id@_CurrentScheduler@details@Concurrency@@SAIXZ,
aborting
Unhandled exception: unimplemented function
msvcr120.dll.?_Id@_CurrentScheduler@details@Concurrency@@SAIXZ called
in 32-bit code (0x7b83d0c2).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:7b83d0c2 ESP:02e4e3e4 EBP:02e4e458 EFLAGS:00000283(   - --  I S - - -C)
 EAX:7b827c1d EBX:7b8c1000 ECX:00000008 EDX:02e4e40c
 ESI:00000002 EDI:02e4e9ac
Stack dump:
0x02e4e3e4:  02e4e47c 00000008 7bc993c4 80000100
0x02e4e3f4:  00000001 00000000 7b83d0c2 00000002
0x02e4e404:  f6c40a80 f6c42bd7 0005efff 02a90000
0x02e4e414:  00000000 02a94b70 f6b8f000 02e4e488
0x02e4e424:  00000000 02e4e458 7b87f923 02e4e448
0x02e4e434:  00000000 02e4e460 f6c76000 02a94b78
Backtrace:
=>0 0x7b83d0c2 in kernel32 (+0x2d0c2) (0x02e4e458)
  1 0xf6c405d8 in msvcr120 (+0x705d7) (0x02e4e48c)
  2 0xf6bd467d in msvcr120 (+0x467c) (0x02e4e4b0)
  3 0x0293e45f spdlog::details::async_log_helper<dllthread>::sleep_or_yield+0x3e(now=0x2e4e4d0,
last_op_time=0x2e4e9ac)
[c:\users\vyacheslav\projects\server\thirdparty\spdlog\include\spdlog\details\async_log_helper.h:350]
in srv-mod (0x02e4e4b0)
  4 0x0293cc82 spdlog::details::async_log_helper<dllthread>::process_next_msg+0x121(last_pop=0x2e4e9ac,
last_flush=0x2e4e9a4)
[c:\users\vyacheslav\projects\server\thirdparty\spdlog\include\spdlog\details\async_log_helper.h:310]
in srv-mod (0x02e4e978)
  5 0x0293f3cf spdlog::details::async_log_helper<dllthread>::worker_loop+0x7e()
[c:\users\vyacheslav\projects\server\thirdparty\spdlog\include\spdlog\details\async_log_helper.h:260]
in srv-mod (0x02e4e9fc)
  6 0x0293fef8 dllthread::threadstart+0x27(param=0x2a94b48)
[c:\users\vyacheslav\projects\server\common\eserver\dllthread-win32.cpp:82]
in srv-mod (0x02e4ea08)
  7 0x7bc83c40 call_thread_func_wrapper+0xb() in ntdll (0x02e4ea18)
  8 0x7bc86e9d call_thread_func+0x7c() in ntdll (0x02e4eae8)
  9 0x7bc83c1e RtlRaiseException+0x21() in ntdll (0x02e4eb08)
  10 0x7bc8efb8 in ntdll (+0x7efb7) (0x02e4f358)
  11 0xf75daf70 start_thread+0xcf() in libpthread.so.0 (0x02e4f428)

Wine version:

vyacheslav@vyacheslav-box:~$ apt-cache policy winehq-devel
winehq-devel:
  Установлен: 1.9.4~ubuntu14.04.1
  Кандидат:   1.9.4~ubuntu14.04.1
  Таблица версий:
 *** 1.9.4~ubuntu14.04.1 0
        500 http://ppa.launchpad.net/wine/wine-builds/ubuntu/
trusty/main amd64 Packages
        100 /var/lib/dpkg/status

[Vyacheslav Napadovsky]

Minor addition: here's spdlog [1] version I use and dllthread [2]. I
modified spdlog a little [3], so now it uses dllthread class instead
std::thread.

[1] https://github.com/gabime/spdlog/commit/e91e1b80f9c4332bcef8388ff48ee705128e...
[2] https://github.com/slavanap/dllthread
[3] https://github.com/slavanap/spdlog/commits/myfixes

[Vyacheslav Napadovsky]

Looks like, there's no point in using Windows native msvc?120.dll with
Wine. These libs behave unexpectedly. Moreover, Concurrency
functionality not fully implemented in Wine msvcp120.dll version.

I solved my problem with recompilation with MinGW. Moreover, I lost
much time because of __MINGW_USE_VC2005_COMPAT does not defined by
default in MinGW (this causes MinGW_sizeof(time_t) !=
MSVC_sizeof(time_t) (4 != 8).