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

[Bug 35084] New: Visual Studio 2010 installer fails to install in 64-bit Windows XP WINEPREFIX (claims "Windows XP x64 Service Pack 2 is required")
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=35084 Bug #: 35084 Summary: Visual Studio 2010 installer fails to install in 64-bit Windows XP WINEPREFIX (claims "Windows XP x64 Service Pack 2 is required") Product: Wine Version: 1.7.7 Platform: x86-64 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. The installer prerequisite log "dd_depcheck_VC_EXP_100.txt" is pretty verbose, no need for Wine trace log: --- snip --- ... [12/08/13,20:06:38] Windows XP x64 Service Pack 2 is required == [12/08/13,20:06:38] This component uses the FileRegVerCheck version check method. It will compare a given version against the version of a regkey on your machine. [12/08/13,20:06:38] Registry key being interrogated: HKLM,System\CurrentControlSet\Control\Windows; Value: CSDVersion; Version: 512. [12/08/13,20:06:38] Version on user's machine: 256 [12/08/13,20:06:38] Version to be installed: 512 [12/08/13,20:06:38] Windows XP x64 Service Pack 2 is required == Component to be installed. --- snip --- Setting CSDVersion to 512 in 64-bit prefix allows the installer go further. Wine uses "Service Pack 3" for 32-bit "Windows XP" setting (=latest). There is no SP3 for the 64-bit version of Windows XP. XP2 is indeed the latest. For consistency it would make sense that Wine uses SP2 for 64-bit XP, indicating highest SP level. $ sha1sum vc_web.exe c2d61a5424aa474a169e59199aa2158a858833f6 vc_web.exe $ du -sh vc_web.exe 3.2M vc_web.exe $ wine --version wine-1.7.8-128-g37460b6 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 10

[Bug 32558] New: Visual Studio 2010 (10.0) Express Edition web installer crashes due to winhttp reporting available chunk size > 32 KiB (heap corruption)
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=32558 Bug #: 32558 Summary: Visual Studio 2010 (10.0) Express Edition web installer crashes due to winhttp reporting available chunk size > 32 KiB (heap corruption) Product: Wine Version: 1.5.20 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, I noticed strange crashes with the web installer of Visual Studio 2010 (10.0) Express Edition. Sometimes the installer would just bail out silently during download. Prerequisite: 'winetricks -q dotnet20 dotnet40' Unfortunately +relay or even repeated installer runs succeed most of the time so it's not easily to reproduce/track down (also depends on client connection to server). Also running the inner installer under debugger changes symptoms. Fortunately I managed get a crash with +relay at one time (using inner installer). --- snip --- $ WINEDEBUG=+tid,+seh,+loaddll,+winhttp,+relay wine ./setup.exe /web /CreatedTemp /NoExclude /InstalledFrom . >>log.txt 2>&1 ... 002a:trace:loaddll:load_native_dll Loaded L"Z:\\home\\focht\\Downloads\\test\\dlmgr.dll" at 0x364c0000: native ... 0030:Call oleaut32.SysAllocString(00c00840 L"dlmgr: Starting download attempt 1 of 3 for http://go.microsoft.com/fwlink/?LinkId=165067&clcid=0x409 using Http") ret=3593f268 0030:Ret oleaut32.SysAllocString() retval=01560ec4 ret=3593f268 ... 0030:Call ntdll.RtlAllocateHeap(00453000,00000008,00008000) ret=364e1884 0030:Ret ntdll.RtlAllocateHeap() retval=0045bdc8 ret=364e1884 ... 0042:Call KERNEL32.CreateFileW(0186f540 L"C:\\users\\focht\\Temp\\30319.01\\1033\\VC_EXP\\wcu\\watson\\dw20shared.msi",00000002,00000000,00000000,00000002,00000080,00000000) ret=364db8ff 0042:Ret KERNEL32.CreateFileW() retval=000001e8 ret=364db8ff ... 0042:Call winhttp.WinHttpQueryHeaders(00000003,00000005,00000000,0b56e850,0b56e840,00000000) ret=364d77ed 0042:trace:winhttp:WinHttpQueryHeaders 0x3, 0x00000005, (null), 0xb56e850, 0xb56e840, (nil) 0042:trace:winhttp:addref_object 0x1718bc0 -> refcount = 3 0042:trace:winhttp:grab_object handle 0x3 -> 0x1718bc0 0042:trace:winhttp:query_headers attribute L"Content-Length" 0042:trace:winhttp:get_header_index L"Content-Length" 0042:trace:winhttp:get_header_index returning 12 0042:trace:winhttp:query_headers returning string: L"1850368" 0042:trace:winhttp:release_object object 0x1718bc0 refcount = 2 0042:Ret winhttp.WinHttpQueryHeaders() retval=00000001 ret=364d77ed 0042:Call winhttp.WinHttpQueryDataAvailable(00000003,00000000) ret=364d77a6 0042:trace:winhttp:WinHttpQueryDataAvailable 0x3, (nil) 0042:trace:winhttp:addref_object 0x1718bc0 -> refcount = 3 0042:trace:winhttp:grab_object handle 0x3 -> 0x1718bc0 0042:Call ntdll.RtlAllocateHeap(00110000,00000000,0000000c) ret=7e2dc554 0042:Ret ntdll.RtlAllocateHeap() retval=0186fa68 ret=7e2dc554 0042:trace:winhttp:addref_object 0x1718bc0 -> refcount = 4 0042:Call KERNEL32.QueueUserWorkItem(7e2dc7e9,0186fa68,00000010) ret=7e2dc85b 0042:Ret KERNEL32.QueueUserWorkItem() retval=00000001 ret=7e2dc85b 0042:trace:winhttp:release_object object 0x1718bc0 refcount = 3 0042:Ret winhttp.WinHttpQueryDataAvailable() retval=00000001 ret=364d77a6 --- snip --- Download for first component is 1850368 bytes in total. The installer allocates a 32 KiB buffer and begins async download using winhttp. The "good" sequence reads like this: --- snip --- ... 0044:Call winhttp.WinHttpReadData(00000003,0045bdc8,00001554,00000000) ret=364d7787 0042:Call ntdll.RtlFreeHeap(00110000,00000000,01718950) ret=7e2dc63a 0044:trace:winhttp:WinHttpReadData 0x3, 0x45bdc8, 5460, (nil) 0042:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e2dc63a 0044:trace:winhttp:addref_object 0x1718bc0 -> refcount = 3 0044:trace:winhttp:grab_object handle 0x3 -> 0x1718bc0 0044:Call ntdll.RtlAllocateHeap(00110000,00000000,00000014) ret=7e2dc554 0044:Ret ntdll.RtlAllocateHeap() retval=01718cb0 ret=7e2dc554 0044:trace:winhttp:addref_object 0x1718bc0 -> refcount = 4 0044:Call KERNEL32.QueueUserWorkItem(7e2dc7e9,01718cb0,00000010) ret=7e2dc85b 0042:trace:winhttp:query_headers attribute L"Transfer-Encoding" 0042:trace:winhttp:get_header_index L"Transfer-Encoding" 0042:trace:winhttp:get_header_index returning -1 0042:trace:winhttp:read_data *** async=1, to_read=5460, num_bytes: 5460, ret=1, callback=0x364da8e0, buffer=0x45bdc8 0042:trace:winhttp:read_data *** buf heap magic=0x455355, size=0x8000 0042:trace:winhttp:send_callback 0x1718bc0, 0x00080000, 0x45bdc8, 5460 0042:Call KERNEL32.WriteFile(000001e8,0045bdc8,00001554,0b56e814,00000000) ret=364db83b 0042:Ret KERNEL32.WriteFile() retval=00000001 ret=364db83b ... 0044:Ret KERNEL32.QueueUserWorkItem() retval=00000001 ret=7e2dc85b ... 0044:trace:winhttp:release_object object 0x1718bc0 refcount = 3 0042:Ret KERNEL32.GetLastError() retval=00002f76 ret=364dfd2f 0044:Ret winhttp.WinHttpReadData() retval=00000001 ret=364d7787 --- snip --- "trace:winhttp:read_data ***" trace message was added by me for diagnosis immediately before the send callback (also heap magic and size dump because +heap is not usable here). At one point we get this interesting sequence: --- snip --- ... 000d:Call winhttp.WinHttpQueryDataAvailable(00000003,00000000) ret=364d77a6 000d:trace:winhttp:WinHttpQueryDataAvailable 0x3, (nil) 000d:trace:winhttp:addref_object 0x1718bc0 -> refcount = 3 000d:trace:winhttp:grab_object handle 0x3 -> 0x1718bc0 000d:Call ntdll.RtlAllocateHeap(00110000,00000000,0000000c) ret=7e2dc554 000d:Ret ntdll.RtlAllocateHeap() retval=01718cb0 ret=7e2dc554 000d:trace:winhttp:addref_object 0x1718bc0 -> refcount = 4 000d:Call KERNEL32.QueueUserWorkItem(7e2dc7e9,01718cb0,00000010) ret=7e2dc85b 000d:Ret KERNEL32.QueueUserWorkItem() retval=00000001 ret=7e2dc85b 0042:trace:winhttp:query_data 73440 bytes available 000d:trace:winhttp:release_object object 0x1718bc0 refcount = 3 0042:trace:winhttp:send_callback 0x1718bc0, 0x00040000, 0xb56e90c, 4 000d:Ret winhttp.WinHttpQueryDataAvailable() retval=00000001 ret=364d77a6 ... 0042:Call winhttp.WinHttpReadData(00000003,0045bdc8,00011ee0,00000000) ret=364d7787 000d:Call ntdll.RtlFreeHeap(00110000,00000000,01870290) ret=7e2dc63a 0042:trace:winhttp:WinHttpReadData 0x3, 0x45bdc8, 73440, (nil) 000d:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e2dc63a 0042:trace:winhttp:addref_object 0x1718bc0 -> refcount = 3 0042:trace:winhttp:grab_object handle 0x3 -> 0x1718bc0 0042:Call ntdll.RtlAllocateHeap(00110000,00000000,00000014) ret=7e2dc554 0042:Ret ntdll.RtlAllocateHeap() retval=01870290 ret=7e2dc554 0042:trace:winhttp:addref_object 0x1718bc0 -> refcount = 4 0042:Call KERNEL32.QueueUserWorkItem(7e2dc7e9,01870290,00000010) ret=7e2dc85b 0042:Ret KERNEL32.QueueUserWorkItem() retval=00000001 ret=7e2dc85b 0044:trace:winhttp:query_headers attribute L"Transfer-Encoding" 0042:trace:winhttp:release_object object 0x1718bc0 refcount = 3 0044:trace:winhttp:get_header_index L"Transfer-Encoding" 0042:Ret winhttp.WinHttpReadData() retval=00000001 ret=364d7787 0044:trace:winhttp:get_header_index returning -1 0042:trace:winhttp:release_object object 0x1718bc0 refcount = 2 0042:Call ntdll.RtlFreeHeap(00110000,00000000,01718cb0) ret=7e2dc63a 0042:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e2dc63a 0044:trace:winhttp:read_data *** async=1, to_read=73440, num_bytes: 73440, ret=1, callback=0x364da8e0, buffer=0x45bdc8 0044:trace:winhttp:read_data *** buf heap magic=0x455355, size=0x8000 0044:trace:winhttp:send_callback 0x1718bc0, 0x00080000, 0x45bdc8, 73440 ... --- snip --- 73440 bytes available reported and WinHttpReadData() is called from installer with the _same_ original buffer (0x45bdc8) which was allocated with 32 KiB (0x8000 bytes) - no realloc in between! This obviously leads to a heap overwrite and some time later to crashes. --- snip --- ... 000d:trace:winhttp:read_data *** async=1, to_read=5760, num_bytes: 5760, ret=1, callback=0x364da8e0, buffer=0x45bdc8 000d:trace:winhttp:read_data *** buf heap magic=0x455355, size=0x8000 000d:trace:winhttp:send_callback 0x1718bc0, 0x00080000, 0x45bdc8, 5760 000d:Call KERNEL32.WriteFile(000001e8,0045bdc8,00001680,0b76e814,00000000) ret=364db83b 000d:Ret KERNEL32.WriteFile() retval=00000001 ret=364db83b 000d:Call ntdll.RtlAllocateHeap(00110000,00000000,00000080) ret=364ee12c 000d:Ret ntdll.RtlAllocateHeap() retval=0186fc18 ret=364ee12c 000d:Call KERNEL32.GetLastError() ret=364dfd2f 000d:Ret KERNEL32.GetLastError() retval=00002f76 ret=364dfd2f 000d:Call KERNEL32.GetLastError() ret=364dfd2f 000d:Ret KERNEL32.GetLastError() retval=00002f76 ret=364dfd2f 000d:trace:seh:raise_exception code=c0000005 flags=0 addr=0x364e4b6f ip=364e4b6f tid=000d 000d:trace:seh:raise_exception info[0]=00000000 000d:trace:seh:raise_exception info[1]=98211559 000d:trace:seh:raise_exception eax=982114ad ebx=00000002 ecx=0b76e30c edx=00000000 esi=0b76e53a edi=0b76e53a 000d:trace:seh:raise_exception ebp=0b76e740 esp=0b76e2bc cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010202 --- snip --- I added a small code snippet to automatically report/truncate available chunk size to 32 KiB if larger. --- snip --- ... fixme:winhttp:query_data truncating data avail from 50400 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 89632 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 71264 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 91776 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 116608 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 93920 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 69792 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 96064 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 67616 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 59328 to 32768 bytes! ... --- snip --- With that change in place the web installer runs rock stable, sometimes reaching download speeds of 2-3 MiB/s using winhttp (not maxing out my connection - that might be server-side bandwidth issue). I've not found any useful info on MSDN about a 32 KiB limit on winhttp chunk size. Maybe the MS guys who wrote the installer made some assumption about some underlying native winsock implementation limitation on Windows. It might be interesting to see what max. chunk size native winhttp reports to clients. 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 7

[Bug 38528] New: The installer of Visual Studio 2013 (12.0) does not work reliable
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=38528 Bug ID: 38528 Summary: The installer of Visual Studio 2013 (12.0) does not work reliable Product: Wine Version: 1.7.42 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: Stefan.Leichter(a)camLine.com Distribution: Debian The installer of Visual Studio 2013 does not work reliable for me. My feeling is that the load / resource consumption of the system is the factor that makes the difference. When the load on the system increases the chances for a successful install are better. If the installer does not work, i start the Eclipse IDE, than it works most of the time. Steps for the installation: 0. rm -rf ~/.wine 1. winetricks -q corefonts dotnet45 2. set version to Windows 8.1 via winecfg 3. wine reg add 'HKLM\Software\Microsoft\Internet Explorer' /v 'svcVersion' /t REG_SZ /d '10.0.9200.16384' 4. wine winexpress_full.exe -- 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 46465] New: vs2015 " Call from 0x7b43e2f3 to unimplemented function msvcp140.dll._Equivalent, aborting"
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=46465 Bug ID: 46465 Summary: vs2015 "Call from 0x7b43e2f3 to unimplemented function msvcp140.dll._Equivalent, aborting" Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcp Assignee: wine-bugs(a)winehq.org Reporter: htl10(a)users.sourceforge.net Distribution: --- trying to run visual studio 2015 community edition gives: Call from 0x7b43e2f3 to unimplemented function msvcp140.dll._Equivalent, aborting Internal Compiler Error in C:\Program Files\Microsoft Visual Studio 14.0\VC\b in\cl.exe. You will be prompted to send an error report to Microsoft later. -- 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 14

[Bug 40220] New: Visual Studio Community 2015 install stuck at splash screen
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=40220 Bug ID: 40220 Summary: Visual Studio Community 2015 install stuck at splash screen Product: Wine Version: 1.9.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: staal1978(a)gmail.com Distribution: --- In a clean 32-bit WINEPREFIX, I installed dotnet452 / corefonts (appdb indicate that dotnet4 is needed) I mounted the offline install media (vs2015.com_enu.iso) with fuseiso and ran vs_community.exe The installer starts until the grey splash screen saying Visual Studio Community 2015 but never goes further than that. Console output is an endless string of : "fixme:thread:__syscall_NtQueryInformationThread info class 16 not supported yet" -- 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 37272] New: CheatEngine 6.4 fails after remote process 'breakin', reporting 'Debugger Crash:Access violation (Last location:41)'
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=37272 Bug ID: 37272 Summary: CheatEngine 6.4 fails after remote process 'breakin', reporting 'Debugger Crash:Access violation (Last location:41)' Product: Wine Version: 1.7.26 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: dbghelp Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, as the summary says. The app works well in general - except when breaking into remote process for debugging (to single step). The app is pretty verbose about its doings, using 'OutputDebugString' API. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Cheat Engine 6.4 ... $ WINEDEBUG=+tid,+seh,+loaddll,+process,+debugstr wine ./Cheat\ Engine.exe >>log.txt 2>&1 ... 0023:warn:debugstr:OutputDebugStringA "setThreadContext(28, 110, 07E9710C). dr0=0 dr1=0 dr2=0 dr3=0 dr7=400" ... 002b:warn:debugstr:OutputDebugStringA "HandleExceptionDebugEvent:80000004" ... 002b:warn:debugstr:OutputDebugStringA "EXCEPTION_SINGLE_STEP. Dr6=00004000" ... 002b:warn:debugstr:OutputDebugStringA "Handling as a single step event" ... 002b:warn:debugstr:OutputDebugStringA "HandleBreak()" ... 0023:trace:seh:raise_exception code=c0000005 flags=0 addr=0x410464 ip=00410464 tid=0023 0023:trace:seh:raise_exception info[0]=00000001 0023:trace:seh:raise_exception info[1]=d000db06 0023:trace:seh:raise_exception eax=0000000b ebx=044bbc78 ecx=d000dafe edx=001c9071 esi=044bbc74 edi=001c9071 0023:trace:seh:raise_exception ebp=01b8ea5c esp=01b8e9f0 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210282 0023:trace:seh:call_stack_handlers calling handler at 0x7bc9de17 code=c0000005 flags=0 0023:trace:seh:call_stack_handlers handler at 0x7bc9de17 returned 0 ... --- snip --- The CheatEngine debugger was attached to 'notepad' process. --- snip --- Wine-dbg>info process pid threads executable (all id:s are in hex) 00000027 1 'notepad.exe' 00000022 3 'cheatengine-i386.exe' 00000020 1 'explorer.exe' 0000000e 5 'services.exe' 00000019 3 \_ 'plugplay.exe' 00000012 4 \_ 'winedevice.exe' Wine-dbg>info thread process tid prio (all id:s are in hex) ... 00000022 cheatengine-i386.exe 0000002b 0 00000024 0 00000023 0 00000027 notepad.exe 00000028 0 --- snip --- Running the debugger under a debugger yields the following: --- snip --- Unhandled exception: page fault on write access to 0xd000db06 in 32-bit code (0x00410464). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:00410464 ESP:01b8e9f0 EBP:01b8ea5c EFLAGS:00210282( R- -- I S - - - ) EAX:0000000b EBX:040341a8 ECX:d000dafe EDX:001c9071 ESI:040341a4 EDI:001c9071 Stack dump: 0x01b8e9f0: 000000b0 0000000b 040341a4 000000b0 0x01b8ea00: 0423c2e8 0423c2ec 004105ee 0000004c 0x01b8ea10: 0423c2e8 00410bdd 0000001c 0423c2e8 0x01b8ea20: 00000414 0040fa88 006426a9 0423c2e8 0x01b8ea30: 0410a7f8 00000414 006429b7 0423c2e8 0x01b8ea40: 0410a7f8 006427ad 001b2ba8 00000000 000c: sel=0067 base=00000000 limit=00000000 16-bit --x Backtrace: =>0 0x00410464 in cheatengine-i386 (+0x10464) (0x01b8ea5c) 1 0x007011b4 in cheatengine-i386 (+0x3011b3) (0x01b8ea70) 2 0x0050bc97 in cheatengine-i386 (+0x10bc96) (0x01b8f368) 3 0x0050c155 in cheatengine-i386 (+0x10c154) (0x01b8f6a0) 4 0x0044b868 in cheatengine-i386 (+0x4b867) (0x01b8f6b8) 5 0x00452019 in cheatengine-i386 (+0x52018) (0x01b8f728) 6 0x004fd312 in cheatengine-i386 (+0xfd311) (0x01b8f7ac) 7 0x005013c1 in cheatengine-i386 (+0x1013c0) (0x01b8f824) 8 0x0058ef28 in cheatengine-i386 (+0x18ef27) (0x01b8f898) 9 0x006e7668 in cheatengine-i386 (+0x2e7667) (0x01b8faa8) 10 0x7eb8fb5e WINPROC_wrapper+0x19() in user32 (0x01b8fad8) ... 0x00410464: movl $0x0,0x8(%ecx) --- snip --- The app is open source: https://code.google.com/p/cheat-engine --- snip --- $ svn checkout http://cheat-engine.googlecode.com/svn/trunk/ cheat-engine-read-only --- snip --- 'Last location:41' part of error message gives a hint: htps://code.google.com/p/cheat-engine/source/browse/trunk/Cheat%20Engine/de… --- snip --- procedure TDebugThreadHandler.VisualizeBreak; begin TDebuggerthread(debuggerthread).execlocation:=41; if processhandler.SystemArchitecture=archx86 then MemoryBrowser.lastdebugcontext:=context^ else MemoryBrowser.lastdebugcontextarm:=armcontext; WaitingToContinue:=not lua_onBreakpoint(context); if WaitingToContinue then //no lua script or it returned 0 MemoryBrowser.UpdateDebugContext(self.Handle, self.ThreadId); end; --- snip --- The crashes happens during update of stacktrace listview, after a couple of 'dbghelp.StackWalk64' calls. 'TMemoryBrowser.UpdateDebugContext' -> 'TfrmStacktrace.stacktrace' https://code.google.com/p/cheat-engine/source/browse/trunk/Cheat%20Engine/f… The crash address is an indirect reference from ECX = 0xd000dafe (+8) .. a value which corresponds to Wine's 'frame->KdHelp.KiCallUserMode' magic value. The stack frame data structure passed to 'StackWalk64' is allocated from internal Delphi heap and initialized. --- snip --- procedure TfrmStacktrace.stacktrace(threadhandle:thandle;context:_context); var stackframe: PStackframe64; cxt:_context; wow64ctx: CONTEXT32; a,b,c,d: dword; sa,sb,sc,sd:string; machinetype: dword; cp: pointer; found: boolean; begin ... getmem(stackframe,sizeof(tstackframe)); zeromemory(stackframe,sizeof(tstackframe)); stackframe^.AddrPC.Offset:=context.{$ifdef cpu64}rip{$else}eip{$endif}; stackframe^.AddrPC.mode:=AddrModeFlat; stackframe^.AddrStack.Offset:=context.{$ifdef cpu64}rsp{$else}esp{$endif}; stackframe^.AddrStack.Mode:=addrmodeflat; stackframe^.AddrFrame.Offset:=context.{$ifdef cpu64}rbp{$else}ebp{$endif}; stackframe^.AddrFrame.Mode:=addrmodeflat; ... --- snip --- The corresponding disassembly, annotated: --- snip --- 0050BBD1 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8] 0050BBD4 BA A4000000 MOV EDX,0A4 ; sizeof(tstackframe) 0050BBD9 E8 323EF0FF CALL cheateng.0040FA10 ; getmem() 0050BBDE 68 A4000000 PUSH 0A4 ; sizeof(tstackframe) 0050BBE3 FF75 F8 PUSH DWORD PTR SS:[EBP-8] 0050BBE6 E8 C5121600 CALL cheateng.0066CEB0 ; zeromemory() 0050BBEB 8B4D F8 MOV ECX,DWORD PTR SS:[EBP-8] 0050BBEE 8B95 38F8FFFF MOV EDX,DWORD PTR SS:[EBP-7C8] 0050BBF4 B8 00000000 MOV EAX,0 0050BBF9 8911 MOV DWORD PTR DS:[ECX],EDX ; stackframe^.AddrPC.. 0050BBFB 8941 04 MOV DWORD PTR DS:[ECX+4],EAX --- snip --- 0xA4 is a bit too small for 'STACKFRAME64' structure. MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/ms680646%28v=vs.85%… My guess is that Delphi/Pascal's definition of 'tstackframe' doesn't include the 'KDHELP64' part which is reserved for kernel debuggers. The problem is that Wine writes magic values into an area that should be left untouched since we're dealing with usermode debugging. That corrupts the internal heap. Source: http://source.winehq.org/git/wine.git/blob/61a9eef9a1c0a72e6571742dbb830f7b… --- snip --- ... 242 /* we don't handle KdHelp */ 243 frame->KdHelp.Thread = 0xC000FADE; 244 frame->KdHelp.ThCallbackStack = 0x10; 245 frame->KdHelp.ThCallbackBStore = 0; 246 frame->KdHelp.NextCallback = 0; 247 frame->KdHelp.FramePointer = 0; 248 frame->KdHelp.KiCallUserMode = 0xD000DAFE; 249 frame->KdHelp.KeUserCallbackDispatcher = 0xE000F000; 250 frame->KdHelp.SystemRangeStart = 0xC0000000; 251 frame->KdHelp.Reserved[0] /* KiUserExceptionDispatcher */ = 0xE0005000; ... --- snip --- The code that writes the magic values was added 8 years ago: http://source.winehq.org/git/wine.git/commitdiff/558130a696a1e6c11a84f3d1f1… Not sure what the intention was since usermode debuggers can't deal with these things anyway. With that part fixed, CheatEngine can debug remote processes after attaching. $ sha1sum CheatEngine64.exe 8cb06bca312ed2bfa02c7f9344f2717d02ecd931 CheatEngine64.exe $ du -sh CheatEngine64.exe 8.7M CheatEngine64.exe $ wine --version wine-1.7.26-44-gb10b391 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 31322] New: Remote Tools for Visual Studio 2012 RC for Windows on ARM (WoA) crashes because TPIDRURW (user TLS register) TEB value is not preserved by kernel
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=31322 Bug #: 31322 Summary: Remote Tools for Visual Studio 2012 RC for Windows on ARM (WoA) crashes because TPIDRURW (user TLS register) TEB value is not preserved by kernel Product: Wine Version: 1.5.9 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, split off from bug 31308 (see there for details). TPIDRURW (user TLS register) TEB value is not preserved by kernel (currently either reset to zero or left with same values across context switches). 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 15

[Bug 31308] New: Remote Tools for Visual Studio 2012 RC for Windows on ARM (WoA) crashes due to invalid user TLS register value access
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=31308 Bug #: 31308 Summary: Remote Tools for Visual Studio 2012 RC for Windows on ARM (WoA) crashes due to invalid user TLS register value access Product: Wine Version: 1.5.9 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, for André, some toy to play with ;-) "Remote Tools for Visual Studio 2012 RC" for Windows on ARM (WoA) can be downloaded here: http://www.microsoft.com/visualstudio/11/en-us/downloads#remote-tools It crashes on my quad Cortex-A9 based i.mx6 Sabre with Ubuntu Linux 12.04 --- snip --- Unhandled exception: page fault on read access to 0xc2083992 in 32-bit code (0x00419d44). Register dump: Thumb User Mode Pc:419d44 Sp:4134f720 Lr:418ed1 Cpsr:200f0030(--C-) r0:0208 r1:0001 r2:4134f7c8 r3:0208 r4:c208398a r5:4134f7c8 r6:0000 r7:4134f728 r8:dddd r9:04e4 r10:0100 Fp:4134f758 Ip:4134f518 Stack dump: 0x4134f720: 00000000 00000000 4134f7c8 00000100 0x4134f730: 00000001 8161b1cd 4134f748 00000100 0x4134f740: 4134f7c8 00000001 4134fd38 00446530 0x4134f750: 000004e4 4006e000 4134f790 00418f91 0x4134f760: 4134fac8 000004e4 00000000 00000000 0x4134f770: 00446998 00446308 42164138 40a72801 Backtrace: =>0 0x00419d44 in rtools_setup_arm (+0x19d44) (0x4134f758) 1 0x00418ed1 in rtools_setup_arm (+0x18ed0) (0x4134f758) 0x00419d44: ldr r4, [r4, #8] Modules: Module Address Debug info Name (77 modules) ELF 8000- 12000 Deferred <wine-loader> PE 400000- 454000 Export rtools_setup_arm ELF 40031000-4003f000 Deferred libsm.so.6 ... System information: Wine build: wine-1.5.9-186-g1f6febe Platform: arm Host system: Linux Host version: 3.2.0-1000-linaro-lt-mx6 --- snip --- WINEDEBUG=+tid,+seh,+relay doesn't reveal much, might be app init/startup code: --- snip --- $ wine ./rtools_setup_arm.exe ... 0024:Call KERNEL32.GetLastError() ret=00416973 0024:Ret KERNEL32.GetLastError() retval=00000000 ret=00416973 0024:Call KERNEL32.MultiByteToWideChar(000004e4,00000001,4130f7c8 " \x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94"...,00000100,00000000,00000000) ret=00418e95 0024:Ret KERNEL32.MultiByteToWideChar() retval=00000100 ret=00418e95 0024:trace:seh:raise_exception info[0]=00000000 0024:trace:seh:raise_exception info[1]=c2083992 0024:trace:seh:raise_exception Pc:419d44 Sp:4130f720 Lr:418ed1 Cpsr:200f0030 r0:0208 r1:0001 r2:0100 r3:0208 0024:trace:seh:raise_exception r4:c208398a r5:4130f7c8 r6:0000 r7:4130f728 r8:dddd r9:04e4 r10:0100 Fp:4130f758 Ip:4130f518 0024:trace:seh:call_stack_handlers calling handler at 0x403e3900 code=c0000005 flags=0 0024:Call KERNEL32.UnhandledExceptionFilter(4130f574) ret=403e3964 wine: Unhandled page fault on read access to 0xc2083992 at address 0x419d44 (thread 0024), starting debugger... 0024:trace:seh:start_debugger Starting debugger "winedbg --auto 35 68" ... --- snip --- Winedbg's builtin disassembler isn't really helpful, it's missing various thumb(2) opcodes. Fortunately there is a free IDA 6.2 demo version for Linux which also supports ARM family for download: http://www.hex-rays.com/products/ida/support/download_demo.shtml This is an invaluable tool which can be used to improve winedbg's disassembler and investigate other problems on ARM. The code in question: --- snip --- ... .text:00419D40 MRC p15, 0, R4,c13,c0, 2 .text:00419D44 LDR R4, [R4,#8] ... --- snip --- ARM info center CP15 c13 register summary: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/CIHFGF… Another resource: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/CACEAI… Opcode_2=3 register "TPIDRURO" is actually ARM HW TLS register, used by libc (__get_tls()). Opcode_2=2 register "TPIDRURW" is "Software Thread ID, User, R/W" Not sure if this is a "free for use" register or if any user space threading library code actually manages this register. One would have to search eglibc sources for ARM and any userspace libraries mapped into process address space, not part of Wine. The values don't seem very random but they point to invalid (not mapped) memory locations. I couldn't find any MCR opcodes in application code, so it's probably written elsewhere. This linux kernel patch has a bit of information: http://www.kernelhub.org/?p=2&msg=57979 It got committed to Linux 3.3.5: http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.3.5 (search for TPIDRURW). I'm running 3.2.0 so it's obviously not cleared by kernel side on context switch. Anyway, I fear this will be most likely upstream if the kernel deliberately clears it on every context switch (starting with 3.3.5). $ du -sh rtools_setup_arm.exe 16M rtools_setup_arm.exe $ sha1sum rtools_setup_arm.exe 6f75e6dad60b64e1f074884829b63ca00bcdb531 rtools_setup_arm.exe 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 22

[Bug 37915] New: IsWow64Process fix(es) required: 32bit UPlay games do not launch in a 64Bit prefix when Wine is set to Vista/Win7
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=37915 Bug ID: 37915 Summary: IsWow64Process fix(es) required: 32bit UPlay games do not launch in a 64Bit prefix when Wine is set to Vista/Win7 Product: Wine Version: 1.7.34 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: abolte(a)systemsaviour.com Distribution: --- While the recent commit http://source.winehq.org/git/wine.git/commitdiff/bfd088dbc6b4f397d9adfbc11a… now allows Uplay to launch 64-bit games in a 64-bit prefix when Windows 7 is selected (and probably Vista and 8), it doesn't help with launching 32-bit games. Since #33776 was closed without covering this situation, I'm opening this bug to cover that use-case here. Attachment 50492 from #33776 (https://bugs.winehq.org/attachment.cgi?id=50492&action=diff) solves this for me, but seems to be a work in progress based on what the author has said there. This issue is also perhaps not specific to Uplay, although I don't know of any other application affected by the bugs in the existing implementation at this time (hence the title). -- 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 39101] New: Visual Studio Compiler creates invalid interface from a typelib
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=39101 Bug ID: 39101 Summary: Visual Studio Compiler creates invalid interface from a typelib Product: Wine Version: 1.7.49 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: oleaut32 Assignee: wine-bugs(a)winehq.org Reporter: leslie_alistair(a)hotmail.com Distribution: --- Created attachment 52094 --> https://bugs.winehq.org/attachment.cgi?id=52094 Sample Project winetricks vc2008express Open the Attached project and compile. StdAfx.h has line. #import "../typelibs/Debug/typelibs.tlb" which causes the compiler to get generate typelibs.tlh and typelibs.tli files. These files represent the interfaces that are defined in the TLB. Under WINE, the file created (runme\Debug\typelibs.tlh), contains a line, like below, for every function in the base interfaces(s). virtual HRESULT _VtblGapPlaceholder1( ) { return E_NOTIMPL; } whereas on windows these lines aren't there. These extra lines cause the V Table to be incorrect and programs crash when any of the interface functions are called. -- 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