https://bugs.winehq.org/show_bug.cgi?id=53014
--- Comment #2 from jswinebz@kanargh.org.uk --- Created attachment 72494 --> https://bugs.winehq.org/attachment.cgi?id=72494 Fix UNICODE_STRING handling in NtUserGetIconInfo
Well, the module filename truncation is due to NtUserGetIconInfo messing up its string handling. Firstly, UNICODE_STRING *definitely* counts in bytes, always, never characters. Secondly, when calculating the length of the returned res_name, it stores the value in the module name's buffer, overwriting the module name length it just calculated above. Since resource names tend to be shortish strings, this will usually have the effect of truncating the returned path.
That gets us into the correct path within CopyImage to do COPYFROMRESOURCE properly, but doesn't solve the deadlock.
Turning on +module too, at the point of the crash we get:
05fc:trace:cursor:CopyImage hnd=000000000006016C, type=1, desiredx=16, desiredy=16, flags=4000 [...] 05fc:trace:cursor:CURSORICON_Load 0000000000400000, L"Z_BAT_1", 16x16, depth 32, fCursor 0, flags 0x4000 05fc:trace:module:FindResourceExW 0000000000400000 #000e L"Z_BAT_1" 0000 05fc:trace:module:LoadResource 0000000000400000 00000000026B7AE0 05fc:trace:cursor:CURSORICON_FindBestIcon entry 0: 32 x 32, 4 bpp 05fc:trace:cursor:CURSORICON_FindBestIcon entry 1: 16 x 16, 4 bpp 05fc:trace:cursor:CURSORICON_FindBestIcon entry 2: 16 x 16, 8 bpp 05fc:trace:module:FindResourceExW 0000000000400000 #0003 #0023 0000 05fc:trace:module:LoadResource 0000000000400000 00000000026B5F90 07dc:trace:module:LdrShutdownThread () 07dc:trace:module:MODULE_InitDLL (00000000043E0000 L"libegl.dll",THREAD_DETACH,0000000000000000) - CALL 07dc:trace:module:MODULE_InitDLL (00000000043E0000,THREAD_DETACH,0000000000000000) - RETURN 1 [...] 05fc:trace:module:LdrGetDllFullName module 0000000000400000, name 0000000002EEE1D0. [...] 07dc:trace:module:MODULE_InitDLL (00000003AFD00000 L"imm32.dll",THREAD_DETACH,0000000000000000) - CALL 07dc:trace:module:MODULE_InitDLL (00000003AFD00000,THREAD_DETACH,0000000000000000) - RETURN 1 07dc:trace:module:MODULE_InitDLL (000000023D820000 L"user32.dll",THREAD_DETACH,0000000000000000) - CALL 05fc:err:sync:RtlpWaitForCriticalSection section 0000000170067640 "dlls/ntdll/loader.c: loader_section" wait timed out in thread 05fc, blocked by 07dc, retrying (60 sec) 07e0:err:sync:RtlpWaitForCriticalSection section 0000000170067640 "dlls/ntdll/loader.c: loader_section" wait timed out in thread 07e0, blocked by 07dc, retrying (60 sec) 05fc:trace:module:FindResourceExW 0000000000400000 #0006 #0ffd 0000 05fc:trace:module:LoadResource 0000000000400000 00000000026B6330 05fc:trace:module:FindResourceExW 000000007B600000 #0006 #0101 0809 05fc:trace:module:LoadResource 000000007B600000 000000007B65DD10 [...] 05fc:trace:module:FindResourceExW 000000023D820000 #0005 L"MSGBOX" 0009 05fc:trace:module:LoadResource 000000023D820000 000000023D8DD020 05fc:err:system:user_check_not_lock BUG: holding USER lock m Files\The Bat!\thebat64.exe: dlls/win32u/sysparams.c:385: user_check_not_lock: Assertion `0' failed. [...thread 5fc crashing due to deadlock detection...]
So a different thread has apparently exited, and so we called user32's DllMain for THREAD_DETACH, but DllMain never returned. This thread exit happened while we were in the middle of executing CURSORICON_Load - presumably this takes a lock for either user32 or NtUser which DllMain also needs to proceed. But calling DllMain takes the loader_section lock, which CURSORICON_Load will also require when it calls LdrGetDllFullName to fill in its own cursoricon_object structure...
Deadlock!
(Since the DllMain locking behaviour is prehistoric, this must be a change in the way user32 handles THREAD_DETACH between 6.21 and 7.5...)