wine-bugs May 2019

wine-bugs@winehq.org

1 participants
7690 discussions

[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@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@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 31358] New: Bobcad v25 hangs on startup
by wine-bugs＠winehq.org 04 Dec '21

04 Dec '21

http://bugs.winehq.org/show_bug.cgi?id=31358 Bug #: 31358 Summary: Bobcad v25 hangs on startup Product: Wine Version: 1.5.9 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Classification: Unclassified Tried installing free trial 13f91536f3a429ccb65b45b7bf72adb927c7d294 BobCAD_V25_Demo_32bit.exe from http://www.bobcad.com/products/cad Seemed to install fine, and put up a UI, but the main window of the UI was never drawn, and the UI was nonresponsive. -- 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 7

[Bug 24664] New: The letter 'R' is not visible in Shapes On A Plane
by wine-bugs＠winehq.org 04 Dec '21

04 Dec '21

http://bugs.winehq.org/show_bug.cgi?id=24664 Summary: The letter 'R' is not visible in Shapes On A Plane Product: Wine Version: 1.3.4 Platform: x86 URL: https://www.digipen.edu/?id=1170&proj=433 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: andrew.millington(a)gmail.com Nearly all the letter 'R' are not visible in text such as the options screen. -- 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 12

[Bug 40111] New: mpr:mpr regression
by wine-bugs＠winehq.org 04 Dec '21

04 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=40111 Bug ID: 40111 Summary: mpr:mpr regression Product: Wine Version: 1.9.3 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Since the commit below, all Windows XP machines (even non-VMs) except the TestBot have a couple of systematic failures. It's not clear why the TestBot VM does not get a failure. It could be because it's the only one to be a Pro version, or because of a subtle network configuration difference. Failure: mpr.c:283: Test failed: Unexpected return: 53 mpr.c:303: Test failed: Unexpected return: 53 mpr:mpr results on test.winehq.org: https://test.winehq.org/data/tests/mpr:mpr.html commit d2ce22ba239d6ea4955e58784cf3e912920bb93b Author: Pierre Schweitzer <pierre(a)reactos.org> Date: Sun Jan 31 22:17:27 2016 +0100 mpr/tests: Add tests for WNetUseConnectionA(). Signed-off-by: Pierre Schweitzer <pierre(a)reactos.org> 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.

2 8

[Bug 20987] New: msi tests can't be run in parallel
by wine-bugs＠winehq.org 04 Dec '21

04 Dec '21

http://bugs.winehq.org/show_bug.cgi?id=20987 Summary: msi tests can't be run in parallel Product: Wine Version: 1.1.34 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: testcases AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com We spend an awful lot of time waiting for tests to finish. It'd be awesome if "make -j 100 test" worked. As a first step, let's make the msi tests work in parallel. "make -j100" in the msi directory explodes at the moment because many of the tests use the same filenames. -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs May 2019