December 2021 - Wine-bugs - list.winehq.org

[Bug 36486] New: Age of Wushu: frequent display of in-game "Don't speed up!" dialog tip disrupts gameplay (Wine fails kernel32.GetTickCount API entry hook check)
by wine-bugs＠winehq.org 05 Dec '21

05 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=36486 Bug ID: 36486 Summary: Age of Wushu: frequent display of in-game "Don't speed up!" dialog tip disrupts gameplay (Wine fails kernel32.GetTickCount API entry hook check) Product: Wine Version: 1.7.19 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, during investigation of bug 36465 I found this goodie, deserving it's own bug of course :) Searching the net reveals similar reports for Windows and MAC: http://www.ageofwushu.com/forums/viewtopic.php?f=29&t=7339 http://www.ageofwushu.com/forums/viewtopic.php?f=30&t=14469 http://portingteam.com/topic/9284-age-of-wushu-dont-speed-up-tip-spam/ This disguised message is in fact the result of a failed API hook check. The vendor obviously doesn't want to go into technical details/reveal this, see the support forums/site for answers to this problem. Enter Wine and get the answers :) One hint is contained in the game log file 'bin/trace.log' With relay thunks emitted (+relay channel): --- snip --- ... [2014-05-18 22:01:13.573] Time Func Pos Begin QueryPerformanceCounter=54 QueryPerformanceFrequency=54 GetTickCount=54 timeGetTime=54 timeSetEvent=54 SetTimer=54 ... --- snip --- without relay thunks: --- snip --- [2014-05-18 22:23:02.818] Time Func Pos Begin QueryPerformanceCounter=8d QueryPerformanceFrequency=8d GetTickCount=55 timeGetTime=55 timeSetEvent=8d SetTimer=55 --- snip --- The hex codes are the first opcode byte of each API entry. The protection code makes a snapshot of certain API entries on startup. The entry bytes are stored for later comparison to detect dynamic hooking (through dll injection for example). --- snip --- ... 0056:Call KERNEL32.GetModuleHandleA(11a8eef0 "kernel32.dll") ret=1134c3b1 0056:Ret KERNEL32.GetModuleHandleA() retval=7b810000 ret=1134c3b1 0056:Call KERNEL32.GetProcAddress(7b810000,11a8eed4 "QueryPerformanceCounter") ret=1134c3c3 0056:Ret KERNEL32.GetProcAddress() retval=7b824afc ret=1134c3c3 0056:Call KERNEL32.GetModuleHandleA(11a8eef0 "kernel32.dll") ret=1134c3d9 0056:Ret KERNEL32.GetModuleHandleA() retval=7b810000 ret=1134c3d9 0056:Call KERNEL32.GetProcAddress(7b810000,11a8eeb4 "QueryPerformanceFrequency") ret=1134c3e5 0056:Ret KERNEL32.GetProcAddress() retval=7b824b14 ret=1134c3e5 0056:Call KERNEL32.GetModuleHandleA(11a8eef0 "kernel32.dll") ret=1134c3fb 0056:Ret KERNEL32.GetModuleHandleA() retval=7b810000 ret=1134c3fb 0056:Call KERNEL32.GetProcAddress(7b810000,11a8eea4 "GetTickCount") ret=1134c407 0056:Ret KERNEL32.GetProcAddress() retval=7b82374c ret=1134c407 0056:Call KERNEL32.GetModuleHandleA(11a8ee98 "WINMM.dll") ret=1134c41d 0056:Ret KERNEL32.GetModuleHandleA() retval=f7220000 ret=1134c41d 0056:Call KERNEL32.GetProcAddress(f7220000,11a8ee88 "timeGetTime") ret=1134c429 0056:Ret KERNEL32.GetProcAddress() retval=7b82374c ret=1134c429 0056:Call KERNEL32.GetModuleHandleA(11a8ee98 "WINMM.dll") ret=1134c43f 0056:Ret KERNEL32.GetModuleHandleA() retval=f7220000 ret=1134c43f 0056:Call KERNEL32.GetProcAddress(f7220000,11a8ee78 "timeSetEvent") ret=1134c44b 0056:Ret KERNEL32.GetProcAddress() retval=f7226d44 ret=1134c44b 0056:Call KERNEL32.GetModuleHandleA(11a8ee68 "USER32.dll") ret=1134c461 0056:Ret KERNEL32.GetModuleHandleA() retval=7eca0000 ret=1134c461 0056:Call KERNEL32.GetProcAddress(7eca0000,11a8ee5c "SetTimer") ret=1134c46d 0056:Ret KERNEL32.GetProcAddress() retval=7ecb0798 ret=1134c46d ... --- snip --- Runtime check of API entries every two seconds: --- snip --- ... 0056:Call KERNEL32.GetModuleHandleA(11a8eef0 "kernel32.dll") ret=1134c4f5 0056:Ret KERNEL32.GetModuleHandleA() retval=7b810000 ret=1134c4f5 0056:Call KERNEL32.GetProcAddress(7b810000,11a8eed4 "QueryPerformanceCounter") ret=1134c505 0056:Ret KERNEL32.GetProcAddress() retval=7b824afc ret=1134c505 0056:Call KERNEL32.GetModuleHandleA(11a8eef0 "kernel32.dll") ret=1134c2fb 0056:Ret KERNEL32.GetModuleHandleA() retval=7b810000 ret=1134c2fb 0056:Call KERNEL32.GetProcAddress(7b810000,11a8eeb4 "QueryPerformanceFrequency") ret=1134c30b 0056:Ret KERNEL32.GetProcAddress() retval=7b824b14 ret=1134c30b 0056:Call KERNEL32.GetModuleHandleA(11a8eef0 "kernel32.dll") ret=1134c2fb 0056:Ret KERNEL32.GetModuleHandleA() retval=7b810000 ret=1134c2fb 0056:Call KERNEL32.GetProcAddress(7b810000,11a8eea4 "GetTickCount") ret=1134c30b 0056:Ret KERNEL32.GetProcAddress() retval=7b82374c ret=1134c30b 0056:Call KERNEL32.GetModuleHandleA(11a8ee98 "WINMM.dll") ret=1134c32b 0056:Ret KERNEL32.GetModuleHandleA() retval=f7220000 ret=1134c32b 0056:Call KERNEL32.GetProcAddress(f7220000,11a8ee88 "timeGetTime") ret=1134c33b 0056:Ret KERNEL32.GetProcAddress() retval=7b82374c ret=1134c33b 0056:Call KERNEL32.GetModuleHandleA(11a8ee98 "WINMM.dll") ret=1134c2fb 0056:Ret KERNEL32.GetModuleHandleA() retval=f7220000 ret=1134c2fb 0056:Call KERNEL32.GetProcAddress(f7220000,11a8ee78 "timeSetEvent") ret=1134c30b 0056:Ret KERNEL32.GetProcAddress() retval=f7226d44 ret=1134c30b 0056:Call KERNEL32.GetModuleHandleA(11a8ee68 "USER32.dll") ret=1134c2fb 0056:Ret KERNEL32.GetModuleHandleA() retval=7eca0000 ret=1134c2fb 0056:Call KERNEL32.GetProcAddress(7eca0000,11a8ee5c "SetTimer") ret=1134c30b 0056:Ret KERNEL32.GetProcAddress() retval=7ecb0798 ret=1134c30b ... --- snip --- Following is the list of API functions and their opcode checks. call/jmp opcode bytes are treated as hook. --- snip --- kernel32.dll!QueryPerformanceCounter -> [0]=0xE8 | [0]=0xE9 | [0]=0xFF | ![0]=<snapshot> kernel32.dll!QueryPerformanceFrequency -> [0]=0xE8 | [0]=0xE9 | [0]=0xFF | ![0]=<snapshot> kernel32.dll!GetTickCount -> [0]=0xE8 | [0]=0xE9 | [0]=0xFF | ![0]=<snapshot> WINMM.dll!timeGetTime -> [0]=0xE8 | [0]=0xE9 | [0]=0xFF | ![0]=<snapshot> | [7]=0xE8 | [7]=0xE9 | [7]=0xFF WINMM.dll!timeSetEvent -> [0]=0xE8 | [0]=0xE9 | [0]=0xFF | ![0]=<snapshot> user32.dll!SetTimer -> [0]=0xE8 | [0]=0xE9 | [0]=0xFF | ![0]=<snapshot> --- snip --- The 'WINMM.dll!timeGetTime' entry point gets a special treatment and this the problem. Wine 'winmm.spec' --- snip --- @ stdcall timeGetTime() kernel32.GetTickCount --- snip --- Forwarded. Dumping the target with Winedbg gives: --- snip --- Wine-dbg>x/10b GetTickCount 0x7b8480d9 GetTickCount: 55 89 e5 53 83 e4 f0 e8 ab 75 --- snip --- Disassembly: --- snip --- 7B8480D9 55 PUSH EBP 7B8480DA 89E5 MOV EBP,ESP 7B8480DC 53 PUSH EBX 7B8480DD 83E4 F0 AND ESP,FFFFFFF0 7B8480E0 E8 AB75FDFF CALL KERNEL32.__x86.get_pc_thunk.bx 7B8480E5 81C3 1B2F0700 ADD EBX,72F1B 7B8480EB E8 72FFFFFF CALL KERNEL32.GetTickCount64 7B8480F0 8B5D FC MOV EBX,DWORD PTR SS:[EBP-4] 7B8480F3 C9 LEAVE 7B8480F4 C3 RETN --- snip --- *eeek* .. 'entry[7]' has indeed value 0xE8 hence the check fails. The PIC code (setup of PIC register) in function prolog causes the harm here. If you avoid the call opcode at 'entry[7]' everything is fine (for example making this entry hotpatchable, inline GetTickCount64, use wrapper). I already tested this. Wine code is no longer (mis)detected as hook and the game runs fine without any "Speedup" spam. $ sha1sum AgeofWushu_download.exe a7101c50ce8deb33008da4ce044fca5e3add721d AgeofWushu_download.exe $ du -sh AgeofWushu_download.exe 1.9M AgeofWushu_download.exe $ wine --version wine-1.7.19 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 4

[Bug 34403] New: AVP Classic WinRT/ARM port needs xinput1_4.dll
by wine-bugs＠winehq.org 05 Dec '21

05 Dec '21

http://bugs.winehq.org/show_bug.cgi?id=34403 Bug #: 34403 Summary: AVP Classic WinRT/ARM port needs xinput1_4.dll Product: Wine Version: 1.7.1 Platform: arm OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello folks, as the summary says... --- snip --- linaro(a)linaro-ubuntu-desktop:~/wine-apps/avpclassic$ ll total 10744 drwxr-xr-x 2 linaro linaro 4096 Aug 31 15:05 ./ drwxrwxr-x 51 linaro linaro 4096 Aug 31 15:05 ../ -rw-rw-r-- 1 linaro linaro 37736 Jul 25 2012 D3D11ProxyDriver.dll -rw-rw-r-- 1 linaro linaro 2840416 Aug 20 2012 D3DCompiler_Test.dll -rw-rw-r-- 1 linaro linaro 1287248 Aug 21 08:05 MyAvP.exe -rw-r--r-- 1 linaro linaro 2675765 Aug 31 15:05 avp_classic_arm.7z -rw-rw-r-- 1 linaro linaro 333672 Jul 25 2012 d3dref9.dll -rw-rw-r-- 1 linaro linaro 1742184 Jul 25 2012 d3dx9d.dll -rw-rw-r-- 1 linaro linaro 71760 Aug 21 08:05 libbinkdec.dll -rw-rw-r-- 1 linaro linaro 19536 Aug 21 08:05 libogg.dll -rw-rw-r-- 1 linaro linaro 39504 Aug 21 08:05 libsmackerdec.dll -rw-rw-r-- 1 linaro linaro 163920 Aug 21 08:05 libtheora.dll -rw-rw-r-- 1 linaro linaro 1611856 Aug 21 08:05 libvorbis.dll -rw-rw-r-- 1 linaro linaro 32848 Aug 21 08:05 libvorbisfile.dll -rw-rw-r-- 1 linaro linaro 105316 Nov 10 2001 non-gold_english.txt ... linaro(a)linaro-ubuntu-desktop:~/wine-apps/avpclassic$ wine ./MyAvP.exe err:module:import_dll Library XINPUT1_4.dll (which is needed by L"Z:\\home\\linaro\\wine-apps\\avpclassic\\MyAvP.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"Z:\\home\\linaro\\wine-apps\\avpclassic\\MyAvP.exe" failed, status c0000135 --- snip --- More info on XInput versions here: http://msdn.microsoft.com/en-us/library/windows/desktop/hh405051%28v=vs.85%… --- quote --- XInput 1.4 ships today as a system component in Windows 8 as XINPUT1_4.DLL. It is available “inbox” and does not require redistribution with an application. The Windows Software Development Kit (SDK) contains the header and import library for statically linking against XINPUT1_4.DLL. To download the Windows 8 SDK, see Downloads for developing desktop apps. XInput 1.4 has these primary advantages over other versions of XInput: * This is the only version that can be used in C++/DirectX Windows Store apps. * The new XInputGetAudioDeviceIds function provides an audio device ID string that you can use to open an XAudio2 mastering voice or audio device for a headset attached to an Xbox 360 common controller. The XInputGetDSoundAudioDeviceGuids function is not available in this version. * Provides improved device capabilities reporting including XINPUT_CAPS_WIRELESS, XINPUT_CAPS_FFB_SUPPORTED, XINPUT_CAPS_PMD_SUPPORTED, and XINPUT_CAPS_NO_NAVIGATION flags and more accurate reporting of XINPUT_CAPS_VOICE_SUPPORTED. These flags are combined in the Flags member of the XINPUT_CAPABILITIES structure. The XInputGetCapabilities function returns XINPUT_CAPABILITIES. --- quote --- Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 6

[Bug 34943] New: Visual C++ 2010 Express web installer exits silently during download of prerequisites
by wine-bugs＠winehq.org 05 Dec '21

05 Dec '21

http://bugs.winehq.org/show_bug.cgi?id=34943 Bug #: 34943 Summary: Visual C++ 2010 Express web installer exits silently during download of prerequisites Product: Wine Version: 1.7.6 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: winhttp AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello folks, might be a regression ... I remember the download of prerequisites was pretty stable some time ago (after months of instabilities). Writes past the end of buffer. --- snip --- Unhandled exception: page fault on write access to 0x00473000 in 32-bit code (0xf74a6bc8). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:f74a6bc8 ESP:043be934 EBP:043be978 EFLAGS:00010202( R- -- I - - - ) EAX:02550d80 EBX:f74d7b30 ECX:00000f58 EDX:00472fa0 ESI:00017000 EDI:00000080 Stack dump: 0x043be934: 003d0f00 7e3e6000 7e3cb069 00472f98 0x043be944: 02550d7c 00001000 7e3cbd95 02550cb0 0x043be954: 00040000 02507e88 043be980 7bcd0000 0x043be964: 043be9f0 00017000 00001000 7bcd0000 0x043be974: 00000000 043be9b8 7e3cbfda 02550cb0 0x043be984: 0045bf98 0002bcc0 00000000 00000001 000c: sel=0067 base=00000000 limit=00000000 16-bit --x Backtrace: =>0 0xf74a6bc8 __memcpy_ssse3_rep+0x568() in libc.so.6 (0x043be978) 1 0x7e3cb069 read_data+0xba(request=0x2550cb0, buffer=0x45bf98, size=0x2bcc0, read=0x0(nil), async=0x1) [/home/focht/projects/wine/wine-git/dlls/winhttp/request.c:2119] in winhttp (0x043be978) 2 0x7e3cbfda task_read_data+0x3f(task=0x2508508) [/home/focht/projects/wine/wine-git/dlls/winhttp/request.c:2460] in winhttp (0x043be9b8) 3 0x7e3c50fa task_thread+0x1f(param=0x2508508) [/home/focht/projects/wine/wine-git/dlls/winhttp/request.c:184] in winhttp (0x043be9e8) 4 0x7bc8efae worker_thread_proc+0x14a(param=<couldn't compute location>) [/home/focht/projects/wine/wine-git/dlls/ntdll/threadpool.c:114] in ntdll (0x043bea48) 5 0x7bc85c04 call_thread_func_wrapper+0xb() in ntdll (0x043bea68) 6 0x7bc85c4d call_thread_func+0x3e(entry=0x7bc8ee63, arg=0x0(nil), frame=0x43beb68) [/home/focht/projects/wine/wine-git/dlls/ntdll/signal_i386.c:2602] in ntdll (0x043beb48) 7 0x7bc85be2 call_thread_entry_point+0x11() in ntdll (0x043beb68) 8 0x7bc8ca58 start_thread+0x165(info=0x81fdcfb8) [/home/focht/projects/wine/wine-git/dlls/ntdll/thread.c:417] in ntdll (0x043bf3a8) 9 0xf75229da start_thread+0xc9() in libpthread.so.0 (0x043bf468) 10 0xf7454bfe __clone+0x5d() in libc.so.6 (0x00000000) ... Wine-dbg>frame 1 2120 remove_data( request, count ); Wine-dbg>info locals 0x7e3cb068 read_data+0xba: (043be978) request_t* request=0x2550cb0 (parameter [EBP+8]) void* buffer=0x45bf98 (parameter [EBP+12]) DWORD size=0x2bcc0 (parameter [EBP+16]) DWORD* read=0x0(nil) (parameter [EBP+20]) BOOL async=0x1 (parameter [EBP+24]) int count=0x1000 (local [EBP-12]) int bytes_read=0x17000 (local [EBP-16]) --- snip --- Source of crash: http://source.winehq.org/git/wine.git/blob/e894c897d52c3e5852498164e246b473… --- snip --- 2105 static BOOL read_data( request_t *request, void *buffer, DWORD size, DWORD *read, BOOL async ) 2106 { 2107 int count, bytes_read = 0; 2108 2109 if (end_of_read_data( request )) goto done; 2110 2111 while (size) 2112 { 2113 if (!(count = get_available_data( request ))) 2114 { 2115 if (!refill_buffer( request, async )) goto done; 2116 if (!(count = get_available_data( request ))) goto done; 2117 } 2118 count = min( count, size ); 2119 memcpy( (char *)buffer + bytes_read, request->read_buf + request->read_pos, count ); 2120 remove_data( request, count ); 2121 if (request->read_chunked) request->read_chunked_size -= count; 2122 size -= count; 2123 bytes_read += count; 2124 request->content_read += count; 2125 if (end_of_read_data( request )) goto done; 2126 } 2127 if (request->read_chunked && !request->read_chunked_size) refill_buffer( request, async ); ... --- snip --- $ sha1sum vc_web.exe c2d61a5424aa474a169e59199aa2158a858833f6 vc_web.exe $ du -sh vc_web.exe 3.2M vc_web.exe $ wine --version wine-1.7.6-273-ga4d8627 Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 11

[Bug 38955] New: Visual Studio Code installer crashes on startup (parsing of overly long string-format security descriptor causes stack corruption)
by wine-bugs＠winehq.org 05 Dec '21

05 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=38955 Bug ID: 38955 Summary: Visual Studio Code installer crashes on startup (parsing of overly long string-format security descriptor causes stack corruption) Product: Wine Version: 1.7.47 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: advapi32 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, the installer passes an overly long string-format security descriptor which is greater than MAX_PATH. --- snip --- $ WINEDEBUG=+tid,+seh,+relay wine ./VSCodeSetup.exe >>log.txt 2>&1 ... 0044:Call advapi32.ConvertStringSecurityDescriptorToSecurityDescriptorW(004237d0 L"D:PAI(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;CIIO;GA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;;0x1301bf;;;SY)(A;OICIIO;GA;;;SY)(A;;0x1301bf;;;BA)(A;OICIIO;GA;;;BA)(A;;0x1200a9;;;BU)(A;OICIIO;GXGR;;;BU)(A;OICIIO;GA;;;CO)(A;;0x1200a9;;;AC)(A"...,00000001,0033d5a0,00000000) ret=004022d7 0044:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7ea9690c ip=7ea9690c tid=0044 0044:trace:seh:raise_exception info[0]=00000001 0044:trace:seh:raise_exception info[1]=00d1d326 0044:trace:seh:raise_exception eax=004f0049 ebx=0033d540 ecx=0033d480 edx=0033d294 esi=0033d584 edi=0033d550 0044:trace:seh:raise_exception ebp=0033d4c8 esp=0033d260 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 ... Unhandled exception: page fault on write access to 0x003b0041 in 32-bit code (0x7ea99089). ... Backtrace: =>0 0x7ea99089 ParseStringSidToSid+0x3a4(StringSid="PAI(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;CIIO;GA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;;0x1301bf;;;SY)(A;OICIIO;GA;;;SY)(A;;0x1301bf;;;BA)(A;OICIIO;GA;;;BA)(A;;0x1200a9;;;BU)(A;OICIIO;GXGR;;;BU)(A;OICIIO;GA;;;CO)(A;;0x1200a9;;;AC)(A;OICIIO;GXGR;;;AC)?????", pSid=0x3b0041, cBytes=0x33d28c) [/home/focht/projects/wine/wine.repo/src/dlls/advapi32/security.c:5587] in advapi32 (0x0033d258) 1 0x7ea969c7 ParseStringSecurityDescriptorToSecurityDescriptor+0x197(StringSecurityDescriptor="", SecurityDescriptor=0x610030, cBytes=0x3b0039) [/home/focht/projects/wine/wine.repo/src/dlls/advapi32/security.c:4577] in advapi32 (0x0033d4c8) 2 0x00310078 (0x0030003b) 0x7ea99089 ParseStringSidToSid+0x3a4 [/home/focht/projects/wine/wine.repo/src/dlls/advapi32/security.c:5587] in advapi32: movb $0x1,0x0(%eax) 5587 pisid->Revision = SDDL_REVISION; Modules: Module Address Debug info Name (66 modules) PE 400000- 3e07000 Deferred vscodesetup ELF 7b800000-7ba71000 Deferred kernel32<elf> \-PE 7b820000-7ba71000 \ kernel32 ... Threads: process tid prio (all id:s are in hex) ... 00000043 (D) Z:\home\focht\Downloads\VSCodeSetup.exe 00000044 0 <== --- snip --- Source: https://source.winehq.org/git/wine.git/blob/3e55f1d2cc673d55ee342ff168a335b… --- snip --- 4508 static BOOL ParseStringSecurityDescriptorToSecurityDescriptor( 4509 LPCWSTR StringSecurityDescriptor, 4510 SECURITY_DESCRIPTOR_RELATIVE* SecurityDescriptor, 4511 LPDWORD cBytes) 4512 { 4513 BOOL bret = FALSE; 4514 WCHAR toktype; 4515 WCHAR tok[MAX_PATH]; 4516 LPCWSTR lptoken; 4517 LPBYTE lpNext = NULL; 4518 DWORD len; 4519 4520 *cBytes = sizeof(SECURITY_DESCRIPTOR); 4521 4522 if (SecurityDescriptor) 4523 lpNext = (LPBYTE)(SecurityDescriptor + 1); ... --- snip --- $ sha1sum VSCodeSetup.exe c971e8805aa21ef6483e04434cb819e524e682f0 VSCodeSetup.exe $ du -sh VSCodeSetup.exe 59M VSCodeSetup.exe $ wine --version wine-1.7.47-162-g0f9a0aa Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 5

[Bug 38908] New: PlanetSide 2 v5.2.4.x launcher process exit causes wineserver crash
by wine-bugs＠winehq.org 05 Dec '21

05 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=38908 Bug ID: 38908 Summary: PlanetSide 2 v5.2.4.x launcher process exit causes wineserver crash Product: Wine Version: 1.7.47 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, found this by chance ... --- snip --- (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x000000000042733a in grab_object (ptr=0x0) at /home/focht/projects/wine/wine.repo/src/server/object.c:298 298 assert( obj->refcount < INT_MAX ); (gdb) bt #0 0x000000000042733a in grab_object (ptr=0x0) at /home/focht/projects/wine/wine.repo/src/server/object.c:298 #1 0x0000000000410da7 in add_irp_to_queue (file=0x2a8e9a0, irp=0x2a948f0) at /home/focht/projects/wine/wine.repo/src/server/device.c:347 #2 0x0000000000411189 in device_file_close_handle (obj=0x2a8e9a0, process=0x29e5a20, handle=104) at /home/focht/projects/wine/wine.repo/src/server/device.c:429 #3 0x000000000041c6fc in handle_table_destroy (obj=0x29e5ba0) at /home/focht/projects/wine/wine.repo/src/server/handle.c:175 #4 0x000000000042748a in release_object (ptr=0x29e5ba0) at /home/focht/projects/wine/wine.repo/src/server/object.c:313 #5 0x000000000041c7c7 in close_process_handles (process=0x29e5a20) at /home/focht/projects/wine/wine.repo/src/server/handle.c:194 #6 0x000000000042a132 in process_killed (process=0x29e5a20) at /home/focht/projects/wine/wine.repo/src/server/process.c:817 #7 0x000000000042a510 in remove_process_thread (process=0x29e5a20, thread=0x2a0c9e0) at /home/focht/projects/wine/wine.repo/src/server/process.c:883 #8 0x000000000044af03 in kill_thread (thread=0x2a0c9e0, violent_death=0) at /home/focht/projects/wine/wine.repo/src/server/thread.c:1107 #9 0x0000000000448836 in thread_poll_event (fd=0x2a0cc10, event=16) at /home/focht/projects/wine/wine.repo/src/server/thread.c:266 #10 0x0000000000415130 in fd_poll_event (fd=0x2a0cc10, event=16) at /home/focht/projects/wine/wine.repo/src/server/fd.c:446 #11 0x000000000041550a in main_loop_epoll () at /home/focht/projects/wine/wine.repo/src/server/fd.c:541 #12 0x0000000000415b1c in main_loop () at /home/focht/projects/wine/wine.repo/src/server/fd.c:886 #13 0x0000000000420fa5 in main (argc=1, argv=0x7ffdb89b57c8) at /home/focht/projects/wine/wine.repo/src/server/main.c:148 (gdb) frame 1 #1 0x0000000000410da7 in add_irp_to_queue (file=0x2a8e9a0, irp=0x2a948f0) at /home/focht/projects/wine/wine.repo/src/server/device.c:347 347 irp->thread = (struct thread *)grab_object( current ); (gdb) p *file $1 = {obj = {refcount = 2, handle_count = 1, ops = 0x4741e0 <device_file_ops>, wait_queue = {next = 0x2a8e9b0, prev = 0x2a8e9b0}, name = 0x0, sd = 0x0, obj_list = {next = 0x2a8eb30, prev = 0x2a8ea50}}, device = 0x29b18b0, fd = 0x2a8ea20, user_ptr = 1121136, entry = {next = 0x29b1918, prev = 0x29b1918}, requests = {next = 0x2a8ea08, prev = 0x2a8ea08}} (gdb) p *irp $2 = {obj = {refcount = 2, handle_count = 0, ops = 0x474060 <irp_call_ops>, wait_queue = {next = 0x2a94900, prev = 0x2a94900}, name = 0x0, sd = 0x0, obj_list = {next = 0x2a8f8d0, prev = 0x699580 <object_list>}}, dev_entry = {next = 0x5555555555555555, prev = 0x5555555555555555}, mgr_entry = { next = 0x5555555555555555, prev = 0x5555555555555555}, file = 0x2a8e9a0, thread = 0x5555555555555555, user_arg = 6148914691236517205, async = 0x0, status = 259, params = {major = 2, create = {major = 2, access = 13, sharing = 1121136, options = 0, device = 43932192}, close = {major = 2, __pad = 13, file = 1121136}, read = {major = 2, key = 13, file = 1121136, pos = 43932192}, write = {major = 2, key = 13, file = 1121136, pos = 43932192}, flush = { major = 2, __pad = 13, file = 1121136}, ioctl = {major = 2, code = 13, file = 1121136}}, result = 0, in_size = 0, in_data = 0x0, out_size = 0, out_data = 0x0} $ (gdb) frame 2 #2 0x0000000000411189 in device_file_close_handle (obj=0x2a8e9a0, process=0x29e5a20, handle=104) at /home/focht/projects/wine/wine.repo/src/server/device.c:429 429 add_irp_to_queue( file, irp ); (gdb) p *obj $5 = {refcount = 2, handle_count = 1, ops = 0x4741e0 <device_file_ops>, wait_queue = {next = 0x2a8e9b0, prev = 0x2a8e9b0}, name = 0x0, sd = 0x0, obj_list = { next = 0x2a8eb30, prev = 0x2a8ea50}} (gdb) p *process $4 = {obj = {refcount = 57, handle_count = 0, ops = 0x477080 <process_ops>, wait_queue = {next = 0x29e5a30, prev = 0x29e5a30}, name = 0x0, sd = 0x0, obj_list = {next = 0x2a07fe0, prev = 0x29fb160}}, entry = {next = 0x2a13e90, prev = 0x6995a0 <process_list>}, parent = 0x0, thread_list = { next = 0x29e5a78, prev = 0x29e5a78}, debugger = 0x0, handles = 0x0, msg_fd = 0x29fb130, id = 8, group_id = 8, sigkill_timeout = 0x0, cpu = CPU_x86, unix_pid = 1166, exit_code = 0, running_threads = 0, start_time = 130812070795368620, end_time = 130812071183535560, affinity = 15, priority = 2, suspend = 0, is_system = 0, debug_children = 0, is_terminating = 1, job = 0x0, job_entry = {next = 0x5555555555555555, prev = 0x5555555555555555}, locks = { next = 0x29e5b00, prev = 0x29e5b00}, classes = {next = 0x2a94200, prev = 0x2a8e770}, console = 0x2a10100, startup_state = STARTUP_DONE, startup_info = 0x0, idle_event = 0x2a6e170, winstation = 0, desktop = 0, token = 0x2a08770, dlls = {next = 0x2a6e5b0, prev = 0x2a94850}, peb = 2147348480, ldt_copy = 4151760128, trace_data = 0, rawinput_devices = {next = 0x29e5b78, prev = 0x29e5b78}, rawinput_mouse = 0x0, rawinput_kbd = 0x0} --- snip --- $ wine --version wine-1.7.47 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 8

[Bug 36731] New: Runes of Magic 'ClientUpdater.exe' crashes after a number of update cycles (mshtml environment setup contains stack buffer overflow)
by wine-bugs＠winehq.org 05 Dec '21

05 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=36731 Bug ID: 36731 Summary: Runes of Magic 'ClientUpdater.exe' crashes after a number of update cycles (mshtml environment setup contains stack buffer overflow) Product: Wine Version: 1.7.20 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: mshtml Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, found during investigation of 'Runes of Magic' client updater. There is a crash after a number of update cycles. Unfortunately it's not easily traceable as it requires large downloads and many client restarts (= hours) to reach the crash point. I started the updater with a few debug channels (= reduced noise) which still allowed me to do post-mortem analysis. The launcher restarts itself after each update cycle. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Runes of Magic $ WINEDEBUG=+tid,+seh,+loaddll,+process,+mshtml wine ./launcher.exe ... <hours, multiple updater restarts> ... 004f:trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\mshtml.dll" at 0x7c090000: builtin 004f:trace:mshtml:DllGetClassObject (CLSID_HTMLDocument {00000001-0000-0000-c000-000000000046} 0x3392a8) 004f:trace:mshtml:ClassFactory_AddRef (0x1c2c80) ref = 1 004f:trace:mshtml:HTMLDocument_Create ((nil) IID_IUnknown 0x1c19d4) 004f:trace:mshtml:load_gecko () 004f:trace:mshtml:check_version "Wine Gecko 2.24" 004f:trace:mshtml:load_xul (L"C:\\windows\\system32\\gecko\\2.24\\wine_gecko\\\\xul.dll") 004f:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7c130001 ip=7c130001 tid=004f 004f:trace:seh:raise_exception info[0]=00000001 004f:trace:seh:raise_exception info[1]=8d43ade4 004f:trace:seh:raise_exception eax=00000001 ebx=006b0063 ecx=003389a0 edx=7bcda204 esi=00339330 edi=001c2de8 004f:trace:seh:raise_exception ebp=005c0070 esp=00338c00 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010212 004f:trace:seh:call_stack_handlers calling handler at 0x4a97b0 code=c0000005 flags=0 004f:trace:seh:call_stack_handlers handler at 0x4a97b0 returned 1 004f:trace:seh:call_stack_handlers calling handler at 0x7bc9ecf7 code=c0000005 flags=0 wine: Unhandled page fault on write access to 0x8d43ade4 at address 0x7c130001 (thread 004f), starting debugger... --- snip --- I looked at the crash site and noticed it being in the middle of opcode sequence. --- snip --- 7C130000 45 INC EBP 7C130001 0889 4424108D OR BYTE PTR DS:[ECX+8D102444],CL 7C130007 8313 B5 ADC DWORD PTR DS:[EBX],-4B 7C13000A FA CLI --- snip --- Decoded with proper opcode start addresses: --- snip --- 7C12FFFF 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8] 7C130002 894424 10 MOV DWORD PTR SS:[ESP+10],EAX 7C130006 8D83 13B5FAFF LEA EAX,[EBX+FFFAB513] --- snip --- Partial stack dump with 'esp' = 0x00338c00 from exception context: --- snip --- ... 00338BA8 C0000005 00338BAC 00000000 00338BB0 00000000 00338BB4 7C130001 00338BB8 00000002 00338BBC 00000001 00338BC0 8D43ADE4 äC 00338BC4 00650074 t e 00338BC8 0033006D m 3 00338BCC 005C0032 2 \ 00338BD0 00650067 g e 00338BD4 006B0063 c k 00338BD8 005C006F o \ 00338BDC 002E0032 2 . 00338BE0 00340032 2 4 00338BE4 0077005C \ w 00338BE8 006E0069 i n 00338BEC 00000005 00338BF0 00650067 g e 00338BF4 006B0063 c k 00338BF8 005C006F o \ 00338BFC 7C130000 00338C00 00338F74 ; UNICODE "C:\windows\system32\gecko\2.24\wine_gecko\" 00338C04 7C1FF480 00338C08 7C19E234 ; ASCII "load_xul" 00338C0C 7C19CF48 ; ASCII "(%s)" 00338C10 7BCEC8C1 ; ASCII "L"C:\\windows\\system32\\gecko\\2.24\\wine_gecko\\\\xul.dll"" 00338C14 7C19D4E8 ; ASCII "Wine Gecko 2.24" 00338C18 7C19E250 ; ASCII "check_version" 00338C1C 7C19D4C0 ; ASCII "%s" 00338C20 7BCEC8AF ; ASCII ""Wine Gecko 2.24"" ... --- snip --- Yes, looks pretty much like a stack buffer overflow. A string buffer overwrote 'ebp', 'ebx' values (register save on stack for '__x86_get_pc_thunk_bx') and parts of the return address. The NULL terminator cancelled out the lower 16 bits of the return address. The culprit: 'load_xul' -> 'set_environment' Source: http://source.winehq.org/git/wine.git/blob/0be56d27d2d4b22367313fa4c6f1e658… --- snip --- 439 static void set_environment(LPCWSTR gre_path) 440 { 441 WCHAR path_env[MAX_PATH], buf[20]; 442 int len, debug_level = 0; 443 444 static const WCHAR pathW[] = {'P','A','T','H',0}; 445 static const WCHAR warnW[] = {'w','a','r','n',0}; 446 static const WCHAR xpcom_debug_breakW[] = 447 {'X','P','C','O','M','_','D','E','B','U','G','_','B','R','E','A','K',0}; 448 static const WCHAR nspr_log_modulesW[] = 449 {'N','S','P','R','_','L','O','G','_','M','O','D','U','L','E','S',0}; 450 static const WCHAR debug_formatW[] = {'a','l','l',':','%','d',0}; 451 452 /* We have to modify PATH as XPCOM loads other DLLs from this directory. */ 453 GetEnvironmentVariableW(pathW, path_env, sizeof(path_env)/sizeof(WCHAR)); 454 len = strlenW(path_env); 455 path_env[len++] = ';'; 456 strcpyW(path_env+len, gre_path); 457 SetEnvironmentVariableW(pathW, path_env); 458 459 SetEnvironmentVariableW(xpcom_debug_breakW, warnW); 460 461 if(TRACE_ON(gecko)) 462 debug_level = 5; 463 else if(WARN_ON(gecko)) 464 debug_level = 3; 465 else if(ERR_ON(gecko)) 466 debug_level = 2; 467 468 sprintfW(buf, debug_formatW, debug_level); 469 SetEnvironmentVariableW(nspr_log_modulesW, buf); 470 } --- snip --- 'path_env' must have overflowed ... but how? I used a JIT debugger to examine the process environment block at the time of the crash since 'GetEnvironmentVariableW' reads from 'NtCurrentTeb()->Peb->ProcessParameters->Environment'. --- snip ---- Address UNICODE dump ... 00231EC0 m32\cmd.exe.PATH 00231EE0 =C:\windows\syst 00231F00 em32;C:\windows; 00231F20 C:\windows\syste 00231F40 m32\wbem;C:\wind 00231F60 ows\system32\gec 00231F80 ko\2.24\wine_gec 00231FA0 ko\;C:\windows\s 00231FC0 ystem32\gecko\2. 00231FE0 24\wine_gecko\;C 00232000 :\windows\system 00232020 32\gecko\2.24\wi 00232040 ne_gecko\;C:\win 00232060 dows\system32\ge 00232080 cko\2.24\wine_ge 002320A0 cko\;C:\windows\ 002320C0 system32\gecko\2 002320E0 .24\wine_gecko\. 00232100 TEMP=C:\users\fo 00232120 cht\Temp.TMP=C:\ 00232140 users\focht\Temp 00232160 .windir=C:\windo 00232180 ws.ALLUSERSPROFI 002321A0 LE=C:\users\Publ 002321C0 ic.APPDATA=C:\us ... --- snip --- At the time 'gre_path' path was appended, the string from 'PATH' environment variable had already grown near 'MAX_PATH' (260 characters) buffer limit. 'PATH' is of course not limited to 'MAX_PATH' since it contains a list of paths. A better option would be to query with 'GetEnvironmentVariableW( value, NULL, 0)' first and allocate the needed buffer from heap, including length for 'gre_path'. Even with these things corrected there is still a general problem: at one point it will overflow/being blocked from appending to 'PATH'. Each newly created updater process inherits the process environment from parent (client updater restarts itself each time). A more sophisticated thing to do would be to search for existing value and not append if already present. Wine Mono 'mscoree' component has a similar potential stack buffer overflow: http://source.winehq.org/git/wine.git/blob/8cdcf470016f0655dfc8810f9d4d2f2d… Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 6

[Bug 49999] New: It should be possible to submit results for all versions of the current stable branch
by WineHQ Bugzilla 05 Dec '21

05 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=49999 Bug ID: 49999 Summary: It should be possible to submit results for all versions of the current stable branch Product: WineHQ Apps Database Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: appdb-unknown Assignee: wine-bugs(a)winehq.org Reporter: elk_aide(a)startmail.com Distribution: --- Lots of Linux Distributions and FreeBSD only ship the stable releases of wine in their repositories. They often stick to the first minor release (In Debian and FreeBSD this currently is 5.0 for example). I think it should be possible to submit tests with the distribution's own most recent wine package, as that probably is the main way wine is aquired. Therefore the AppDB list should include the "outdated" minor releases of the current stable branch for selection aswell. This is currently not the case (only 5.0.2 is available for selection currently). Cheers! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 47867] New: comctl32:animate: create_animate() fails in Japanese on Windows 10 1809
by WineHQ Bugzilla 05 Dec '21

05 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=47867 Bug ID: 47867 Summary: comctl32:animate: create_animate() fails in Japanese on Windows 10 1809 Product: Wine Version: 4.17 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com comctl32:animate has the following failures on the new w1064v1809_ja VM (Windows 10 1809 + Japanese locale): animate.c:106: Test failed: GetUpdateRect: There should be a region that needs to be updated animate.c:106: Test failed: GetUpdateRect: There should be a region that needs to be updated Interestingly this does not fail on the fg-win7u64-1spie9-ja VM so this is specific to the Japanese + Windows 10 combination. The test was introduced in this commit: commit bc357819296594aca300fdf30bb0cda46e9f0be0 Author: Bruno Jesus <00cpxxx(a)gmail.com> AuthorDate: Fri Mar 18 14:29:48 2016 +0530 Commit: Alexandre Julliard <julliard(a)winehq.org> CommitDate: Tue Mar 22 00:36:30 2016 +0900 comctl32/tests: Add initial tests for the animation control. Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 52164] New: mfplat:mfplat gets stuck in test_MFCreateDXSurfaceBuffer() on cw-gtx560 (Nvidia)
by WineHQ Bugzilla 05 Dec '21

05 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=52164 Bug ID: 52164 Summary: mfplat:mfplat gets stuck in test_MFCreateDXSurfaceBuffer() on cw-gtx560 (Nvidia) Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com mfplat:mfplat gets stuck on cw-gtx560 (Nvidia): 07b4:mfplat: 6 tests executed (0 marked as todo, 0 failures), 0 skipped. 1760:mfplat: 8 tests executed (0 marked as todo, 0 failures), 0 skipped. 1ab4:mfplat: 8 tests executed (0 marked as todo, 0 failures), 0 skipped. 0668:mfplat: 8 tests executed (0 marked as todo, 0 failures), 0 skipped. mfplat:mfplat:1ae8 done (258) in 120s (258 == WAIT_TIMEOUT) https://test.winehq.org/data/patterns.html#mfplat:mfplat Running with WINETEST_REPORT_SUCCESS shows that the freeze happens in test_MFCreateDXSurfaceBuffer(), specifically in the first IMFMediaBuffer_Unlock() call. hr = IMFMediaBuffer_Lock(buffer, &data, NULL, &length); ok(hr == S_OK, "Unexpected hr %#x.\n", hr); ok(length == max_length, "Unexpected length.\n"); // <--- last trace /* Unlock twice. */ hr = IMFMediaBuffer_Unlock(buffer); ok(hr == S_OK, "Unexpected hr %#x.\n", hr); // <--- never seen This is specific to cw-gtx560, the TestBot's only Nvidia test configuration. It also only happens on Windows 10, from 1709 to 21H1: the test succeeds on cw-gtx560 when running Windows 8.1 despite the fact that it still runs test_MFCreateDXSurfaceBuffer() (the skip trace is not present in the win81 WineTest report). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 51899] New: 16-bit Collins Dictionary has black background.
by WineHQ Bugzilla 04 Dec '21

04 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=51899 Bug ID: 51899 Summary: 16-bit Collins Dictionary has black background. Product: Wine Version: 6.19 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: zzhang(a)codeweavers.com Distribution: --- This is a split from bug 51802. Bisect points to 6f095cea53787f03a159f0464b9881ace3724e6b is the first bad commit commit 6f095cea53787f03a159f0464b9881ace3724e6b Author: Jacek Caban <jacek(a)codeweavers.com> Date: Tue Aug 3 12:56:49 2021 +0200 gdi32: Use NtGdiPatBlt for PatBlt implementation. Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> Signed-off-by: Huw Davies <huw(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 35