May 2020 - Wine-bugs - list.winehq.org

[Bug 49011] New: Royal Quest crashes wineserver
by WineHQ Bugzilla 08 May '20

08 May '20

https://bugs.winehq.org/show_bug.cgi?id=49011 Bug ID: 49011 Summary: Royal Quest crashes wineserver Product: Wine Version: 5.7 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)winehq.org Reporter: spoon0042(a)hotmail.com Distribution: --- Click "PLAY" in the launcher, click "Log In" -> boom. (Usually anyway, I think a couple times I was able to pick a character then got the crash after clicking "Enter".) Requested run of gdb gave this: Reading symbols from /opt/wine-devel/bin/wineserver...Reading symbols from /usr/lib/debug/.build-id/95/97696b2e8b609fa120eaaaf5340792be83679b.debug...done. done. [New LWP 15901] Core was generated by `/opt/wine-devel/bin/wineserver'. Program terminated with signal SIGSEGV, Segmentation fault. #0 req_get_thread_context (req=0x5618cb954488, reply=0x7ffc8c5c7b20) at thread.c:1851 1851 thread.c: No such file or directory. (gdb) backtrace #0 req_get_thread_context (req=0x5618cb954488, reply=0x7ffc8c5c7b20) at thread.c:1851 #1 0x00005618c9521ec3 in call_req_handler (thread=<optimized out>) at request.c:310 #2 0x00005618c9528630 in thread_poll_event (fd=<optimized out>, event=1) at thread.c:368 #3 0x00005618c9502ef6 in main_loop_epoll () at fd.c:476 #4 0x00005618c950316e in main_loop () at fd.c:937 #5 0x00005618c94f39e6 in main () And regression test yielded this: c4dab9b76eb7397f6e5325ff4bdf792cf500e571 is the first bad commit commit c4dab9b76eb7397f6e5325ff4bdf792cf500e571 Author: Jacek Caban <jacek(a)codeweavers.com> Date: Wed Apr 22 14:33:23 2020 +0200 server: Block by waiting on context handle in get_thread_context. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=48052 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45546 Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> :040000 040000 23489508911b463430ec94f084243ab7b6b47a49 376d2675fd4f00819efed8efdbc00d0c80580eb9 M dlls :040000 040000 0fe4c763311f30a02a6341d5e9ec9529d5efa701 35da9ef4fc5f1a4c732d0f1b748387e938787293 M include :040000 040000 40c59f9f5407f93d2223a2d546a47bd6864f2ae2 8c7414aad06eeeee9148960c93dcad26cc7cc00f M server -- 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 29

[Bug 47690] New: When DirectWrite rendering is enabled in Notepad++ there are still no ligatures.
by wine-bugs＠winehq.org 08 May '20

08 May '20

https://bugs.winehq.org/show_bug.cgi?id=47690 Bug ID: 47690 Summary: When DirectWrite rendering is enabled in Notepad++ there are still no ligatures. Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: kolan_n(a)mail.ru Distribution: --- [Notepad++](https://github.com/notepad-plus-plus/notepad-plus-plus) is an application based on Scintilla. Scintilla is a library for creating textareas. [DirectWrite](https://docs.microsoft.com/en-us/windows/win32/directwrite/dir… is an API for text rendering with subpixel antialiasing which can be hardware-accelerated using Direct2D. [SCI_SETTECHNOLOGY](https://www.scintilla.org/ScintillaDox.html#SCI_SETTECHN… is a enum value identifying a call to Scintilla (in fact it is done using Windows messages). When it is set to values > 0 (SC_TECHNOLOGY_DIRECTWRITE, SC_TECHNOLOGY_DIRECTWRITERETAIN, or SC_TECHNOLOGY_DIRECTWRITEDC), Scintilla uses DirectDraw accelerated via Direct2D for rendering instead of an own surrogate. A byproduct of enebling DirectWrite rendering is ligatures support on fonts having them, like Fira Code. In fact it is the main reason to enable DirectWrite in NPP. In Windows >7 everything works fine. In Wine there are no ligatures (and some other issues). -- 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 45774] New: Black screen (Ragnarok Online kRO)
by wine-bugs＠winehq.org 08 May '20

08 May '20

https://bugs.winehq.org/show_bug.cgi?id=45774 Bug ID: 45774 Summary: Black screen (Ragnarok Online kRO) Product: Wine Version: 3.13 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: vectorfish(a)gmail.com Distribution: --- Since Wine 3.13, you get black screen in Ragnarok Online from the very beginning. I went through regression test and it turned out that the issue started with commit 6ccb94392a8ef4bca701ae2a560f4ea1da677edd ("server: Clip visible region to the surface rectangle instead of the desktop."). -- 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 17233] New: Zanzarah game opens a black fullscreen window and then crashes
by wine-bugs＠winehq.org 08 May '20

08 May '20

http://bugs.winehq.org/show_bug.cgi?id=17233 Summary: Zanzarah game opens a black fullscreen window and then crashes Product: Wine Version: 1.1.14 Platform: PC-x86-64 URL: http://www.download.com/Zanzarah-demo/3000-7492_4- 10246951.html OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-ddraw AssignedTo: wine-bugs(a)winehq.org ReportedBy: gryffus(a)hkfree.org Game opens a black fullscreen window and then crashes. I am using an nvidia card. -- 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 42

[Bug 48927] New: Heap buffer underflow in TiffFrameDecode_ReadTile when decoding 1x1 4bpp RGBA image
by WineHQ Bugzilla 08 May '20

08 May '20

https://bugs.winehq.org/show_bug.cgi?id=48927 Bug ID: 48927 Summary: Heap buffer underflow in TiffFrameDecode_ReadTile when decoding 1x1 4bpp RGBA image Product: Wine-staging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: thomas.faber(a)reactos.org CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 66887 --> https://bugs.winehq.org/attachment.cgi?id=66887 Debugger info from ReactOS ReactOS bug for reference: https://jira.reactos.org/browse/CORE-16796 Apologies for not reproducing this on Wine; the bug & fix are pretty simple though. The gdiplus:image test tries to decode a 1x1 TIFF image, and TiffFrameDecode_ReadTile assumes that the cached_tile is large enough for an even number of output pixels (i.e. a full number of input bytes). The issue appears to be with this Staging patch: https://github.com/wine-staging/wine-staging/blob/master/patches/windowscod… The attachment has a backtrace and relevant variables. The line numbers may not match but the underflow got caught at: dst[0] = (b & 0x20) ? 0xff : 0; /* B */ -- 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 12

[Bug 49087] New: Blindwrite 7.0 'ezplay.sys' needs ntoskrnl.exe.RtlCopyMemoryNonTemporal
by WineHQ Bugzilla 08 May '20

08 May '20

https://bugs.winehq.org/show_bug.cgi?id=49087 Bug ID: 49087 Summary: Blindwrite 7.0 'ezplay.sys' needs ntoskrnl.exe.RtlCopyMemoryNonTemporal Product: Wine Version: 5.7 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, to track this patch from Zeb: https://www.winehq.org/pipermail/wine-devel/2020-May/165679.html Download: https://web.archive.org/web/20131210151026/http://download2.vso-software.fr… --- snip --- $ WINEDEBUG=+seh,+relay,+ntoskrnl,+module,+virtual wineboot >> log.txt 2>&1 ... 00b8:trace:ntoskrnl:load_driver loading driver L"C:\\windows\\System32\\Drivers\\ezplay.sys" 00b8:Call KERNEL32.LoadLibraryW(007fe230 L"C:\\windows\\System32\\Drivers\\ezplay.sys") ret=00236878 ... 00b8:warn:module:import_dll No implementation for NTOSKRNL.exe.RtlCopyMemoryNonTemporal imported from L"C:\\windows\\System32\\Drivers\\ezplay.sys", setting to 0xe30000 ... 00b8:Ret KERNEL32.LoadLibraryW() retval=00e10000 ret=00236878 ... --- snip --- --- snip --- $ winedump -j import .wine/drive_c/windows/system32/drivers/ezplay.sys Contents of .wine/drive_c/windows/system32/drivers/ezplay.sys: 118400 bytes Import Table size: 0000003c offset 0001c1ec NTOSKRNL.exe Hint/Name Table: 0001C240 TimeDateStamp: 00000000 (Thu Jan 1 01:00:00 1970) ForwarderChain: 00000000 First thunk RVA: 00009B98 Thunk Ordn Name 00009b98 250 PoSetPowerState 00009ba0 323 ZwClose 00009ba8 344 ZwSetValueKey 00009bb0 291 RtlInitUnicodeString 00009bb8 115 IoOpenDeviceRegistryKey 00009bc0 117 IoRegisterDeviceInterface 00009bc8 270 RtlCopyMemoryNonTemporal 00009bd0 86 IoDeleteDevice 00009bd8 88 IoDetachDevice 00009be0 68 IoAttachDeviceToDeviceStack 00009be8 108 IoInitializeRemoveLockEx 00009bf0 76 IoCreateDevice 00009bf8 156 IofCompleteRequest 00009c00 198 KeSetEvent 00009c08 128 IoSetDeviceInterfaceState 00009c10 155 IofCallDriver 00009c18 271 RtlCopyUnicodeString 00009c20 204 KeWaitForSingleObject 00009c28 286 RtlFreeUnicodeString 00009c30 136 IoUnregisterPlugPlayNotification 00009c38 243 ObfDereferenceObject 00009c40 268 RtlCompareUnicodeString 00009c48 72 IoBuildSynchronousFsdRequest 00009c50 70 IoBuildDeviceIoControlRequest 00009c58 100 IoGetDeviceObjectPointer 00009c60 118 IoRegisterPlugPlayNotification 00009c68 122 IoReleaseRemoveLockEx 00009c70 95 IoFreeWorkItem 00009c78 116 IoQueueWorkItem 00009c80 66 IoAllocateWorkItem 00009c88 60 IoAcquireRemoveLockEx 00009c90 121 IoReleaseRemoveLockAndWaitEx 00009c98 245 PoCallDriver 00009ca0 252 PoStartNextPowerIrp 00009ca8 248 PoRequestPowerIrp 00009cb0 135 IoStopTimer 00009cb8 267 RtlCompareMemory 00009cc0 22 ExFreePool 00009cc8 171 KeInitializeEvent 00009cd0 165 KeDelayExecutionThread 00009cd8 220 MmMapLockedPagesSpecifyCache 00009ce0 347 __C_specific_handler 00009ce8 134 IoStartTimer 00009cf0 109 IoInitializeTimer 00009cf8 162 KeBugCheckEx 00009d00 14 ExAllocatePoolWithTag offset 0001c200 HAL.DLL Hint/Name Table: 0001C228 TimeDateStamp: 00000000 (Thu Jan 1 01:00:00 1970) ForwarderChain: 00000000 First thunk RVA: 00009B80 Thunk Ordn Name 00009b80 2 KeStallExecutionProcessor 00009b88 1 KeQueryPerformanceCounter Done dumping .wine/drive_c/windows/system32/drivers/ezplay.sys --- snip --- $ sha1sum Blindwrite7_setup.exe 8b357a5613b5f348e0105d9dbb84ef42550016ee Blindwrite7_setup.exe $ du -sh Blindwrite7_setup.exe 14M Blindwrite7_setup.exe $ wine --version wine-5.7-177-gad1fad8a94 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.

1 3

[Bug 40311] New: Processing of 'DeviceIoControl' calls doesn't corresponds to specification
by wine-bugs＠winehq.org 08 May '20

08 May '20

https://bugs.winehq.org/show_bug.cgi?id=40311 Bug ID: 40311 Summary: Processing of 'DeviceIoControl' calls doesn't corresponds to specification Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs(a)winehq.org Reporter: ugnenko(a)mail.ru Distribution: --- As described in specification 'Buffer Descriptions for I/O Control Codes' for 'METHOD_IN_DIRECT' or 'METHOD_OUT_DIRECT' transfer types the data buffer, to which points the pointer passed as 'lpOutputBuffer' argument into 'DeviceIoControl', must be accessible from driver. In other words, when in control code is specified 'METHOD_IN_DIRECT' tranfer type, the 'lpOutputBuffer' buffer may be used as the additional buffer of data that driver may transfer to device. This feature is used in software and drivers for Hantek Oscilloscopes. The pointer 'lpOutputBuffer' and argument 'nOutBufferSize', which are passed to 'DeviceIoControl' function, must are used as corresponding values for fields 'StartVa', 'ByteOffset' and 'ByteCount' in 'irp->MdlAddress' structure. But Wine allocates new output buffer that are passed to 'IoBuildDeviceIoControlRequest' (see function 'dispatch_ioctl' in source file 'dlls/ntoskrnl.exe/ntoskrnl.c'). Thus data stored in output buffer aren't available for driver. Specification: https://msdn.microsoft.com/en-us/library/windows/hardware/ff540663(v=vs.85)… -- 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 40894] New: Warcraft 3: Crash on starting the game
by wine-bugs＠winehq.org 08 May '20

08 May '20

https://bugs.winehq.org/show_bug.cgi?id=40894 Bug ID: 40894 Summary: Warcraft 3: Crash on starting the game Product: Wine Version: 1.9.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sworddragon2(a)aol.com Distribution: --- Created attachment 54985 --> https://bugs.winehq.org/attachment.cgi?id=54985 Terminal output A few days before I was still able to start Warcraft 3 (not sure if it was with Wine 1.9.12 or already Wine 1.9.13) and now after using a clean profile Warcraft 3 crashes on starting it. In the attachments is the terminal output. -- 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 18

[Bug 49043] New: iLok License Manager daemon 'LDSvc.exe' crashes on startup (PACE copy protection spuriously fails to get/set thread context of newly created threads)
by WineHQ Bugzilla 08 May '20

08 May '20

https://bugs.winehq.org/show_bug.cgi?id=49043 Bug ID: 49043 Summary: iLok License Manager daemon 'LDSvc.exe' crashes on startup (PACE copy protection spuriously fails to get/set thread context of newly created threads) Product: Wine Version: 5.7 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, an interesting problem while looking at bug 49010 ("ilok license manager: doesn't connect to the activation server as in 4.0.2"). NOTE: It's not the only problem but I think it's worth mentioning separately and there is actually a patchset that aims to mitigate the issue. Also these patches do not refer to any bug id. The license manager is an auto-start service. Part of PACE copy-protection hence obviously using anti-debug/hacking trickery. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files (x86)/iLok License Manager $ WINEDEBUG=+seh,+relay,+loaddll,+process,+ntdll,+server,+virtual wine ./iLok\ License\ Manager.exe >>log.txt 2>&1 ... 003c:Call KERNEL32.CreateProcessW(00000000,008ab690 L"C:\\Program Files (x86)\\Common Files\\PACE\\Services\\LicenseServices\\LDSvc.exe -u https://activation.paceap.com/InitiateActivation",00000000,00000000,100000000,00000400,008aa020,00000000,0022f5a0,0022f570) ret=14000683a ... 0068:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\kernelbase.dll" at 0x7b000000: PE builtin 0068:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\kernel32.dll" at 0x7b420000: builtin 0068:trace:loaddll:load_native_dll Loaded L"C:\\Program Files (x86)\\Common Files\\PACE\\Services\\LicenseServices\\LDSvc.exe" at 0x400000: native 0068:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\ucrtbase.dll" at 0x7e720000: builtin 0068:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\version.dll" at 0x330000: PE builtin 0068:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\sechost.dll" at 0x350000: PE builtin 0068:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\advapi32.dll" at 0x7e680000: builtin 0068:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\rpcrt4.dll" at 0x5430000: PE builtin 0068:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\setupapi.dll" at 0x5340000: PE builtin 0068:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\gdi32.dll" at 0x7e540000: builtin 0068:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\user32.dll" at 0x7e830000: builtin 0068:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\ole32.dll" at 0x5580000: PE builtin 0068:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\msacm32.dll" at 0x370000: PE builtin 0068:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\WINMM.dll" at 0x10000000: PE builtin 0068:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\MSVCP140.dll" at 0x58e0000: PE builtin ... 003c:trace:process:RtlCreateUserProcess L"\\??\\C:\\Program Files (x86)\\Common Files\\PACE\\Services\\LicenseServices\\LDSvc.exe" pid 0064 tid 0068 handles 0xe8/0xec ... 0068:Starting process L"C:\\Program Files (x86)\\Common Files\\PACE\\Services\\LicenseServices\\LDSvc.exe" (entryproc=0x449060) ... 0068:Call advapi32.StartServiceCtrlDispatcherA(0032fdac) ret=004482e8 ... 007c:Call advapi32.RegisterServiceCtrlHandlerA(029090e4 "PACELicenseDServices",004474d0) ret=00447605 ... 007c:Call KERNEL32.CreateRemoteThread(ffffffff,00000000,00000000,00447580,00000000,00000004,00000000) ret=004486d6 ... 007c:Ret KERNEL32.CreateRemoteThread() retval=000000a0 ret=004486d6 ... 0080:Call ucrtbase._beginthreadex(00000000,00000000,004969c0,06527148,00000004,06527168) ret=00496955 ... 0080:Ret ucrtbase._beginthreadex() retval=0000018c ret=00496955 0080:Call KERNEL32.ResumeThread(0000018c) ret=0049699a ... 0080:Ret KERNEL32.ResumeThread() retval=00000001 ret=0049699a ... 00b8: *fd* 24 <- 179 00b8: init_thread( unix_pid=26107, unix_tid=26127, debug_level=1, teb=7ffc4000, entry=004969c0, reply_fd=24, wait_fd=26, cpu=x86 ) 00b8: *fd* 26 <- 180 00b8: init_thread() = 0 { pid=0064, tid=00b8, server_start=1d61d46752028e8 (-2.0593510), info_size=0, version=602, all_cpus=00000003, suspend=1 } 00b8: select( flags=2, cookie=06e1e5a4, timeout=0, size=0, prev_apc=0000, result={}, data={}, context={cpu=x86,eip=7bcb24a4,esp=06e1fff0,ebp=00000000,eflags=00000202,cs=0023,ss=002b,ds=002b,es=002b,fs=0063,gs=006b,eax=004969c0,ebx=065231e0,ecx=00000000,edx=00000000,esi=00000000,edi=00000000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,fp.ctrl=0000027f,fp.status=00000000,fp.tag=00000000,fp.err_off=00000000,fp.err_sel=00000000,fp.data_off=00000000,fp.data_sel=00000000,fp.cr0npx=00000000,fp.reg0=0,fp.reg1=0,fp.reg2=0,fp.reg3=0,fp.reg4=0,fp.reg5=0,fp.reg6=0,fp.reg7=0,extended={0000027f,...,00000000}} ) 00b8: select() = TIMEOUT { call={APC_NONE}, apc_handle=0000, context={} } 00b8:Call PE DLL (proc=0x7e769d80,module=0x7e720000 L"ucrtbase.dll",reason=THREAD_ATTACH,res=(nil)) ... L"WININET.dll",reason=THREAD_ATTACH,res=(nil)) retval=1 00b8:Call PE DLL (proc=0x160050e3,module=0x16000000 L"dnssd.dll",reason=THREAD_ATTACH,res=(nil)) ... 00b8:Call KERNEL32.WaitForMultipleObjects(00000002,06e1fd90,00000000,fffffffe) ret=00495e84 00b8:Call kernelbase.WaitForMultipleObjects(00000002,06e1fd90,00000000,fffffffe) ret=7bc9f8e4 00b8:Call ntdll.NtWaitForMultipleObjects(00000002,06e1fb7c,00000001,00000000,06e1fb00) ret=7b040eda 00b8: select( flags=2, cookie=06e1f194, timeout=+4294967.2939836, size=12, prev_apc=0000, result={}, data={WAIT,handles={0124,00dc}}, context={} ) 00b8: select() = PENDING { call={APC_NONE}, apc_handle=0000, context={} } 00b8: *wakeup* signaled=0 00b8:Ret ntdll.NtWaitForMultipleObjects() retval=00000000 ret=7b040eda 00b8:Ret kernelbase.WaitForMultipleObjects() retval=00000000 ret=7bc9f8e4 00b8:Ret KERNEL32.WaitForMultipleObjects() retval=00000000 ret=00495e84 00b8:Call KERNEL32.WaitForSingleObject(00000128,00000000) ret=00592a19 00b8:Call kernelbase.WaitForSingleObject(00000128,00000000) ret=7bc9f8e4 00b8:Call ntdll.NtWaitForMultipleObjects(00000001,06e1fc3c,00000001,00000000,06e1fbc0) ret=7b040eda 00b8: select( flags=2, cookie=06e1f254, timeout=0, size=8, prev_apc=0000, result={}, data={WAIT,handles={0128}}, context={} ) 00b8: select() = 0 { call={APC_NONE}, apc_handle=0000, context={} } 00b8:Ret ntdll.NtWaitForMultipleObjects() retval=00000000 ret=7b040eda 00b8:Ret kernelbase.WaitForSingleObject() retval=00000000 ret=7bc9f8e4 00b8:Ret KERNEL32.WaitForSingleObject() retval=00000000 ret=00592a19 00b8:trace:process:NtQueryInformationProcess (0xffffffff,0x00000022,0x7ffc7ac0,0x00000004,(nil)) 00b8:trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) ip=00000000 tid=00b8 00b8:trace:seh:raise_exception info[0]=00000008 00b8:trace:seh:raise_exception info[1]=00000000 00b8:trace:seh:raise_exception eax=06e1fdec ebx=065231e0 ecx=00002592 edx=4a108e6a esi=00000000 edi=012933bb 00b8:trace:seh:raise_exception ebp=06e1fdec esp=06e1fbd0 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 00b8:trace:seh:call_vectored_handlers calling handler at 0x448700 code=c0000005 flags=0 00b8:trace:seh:call_vectored_handlers handler at 0x448700 returned 0 00b8:trace:seh:call_stack_handlers calling handler at (nil) code=c0000005 flags=0 00b8:trace:process:NtQueryInformationProcess (0xffffffff,0x00000022,0x7ffc7ac0,0x00000004,(nil)) 00b8:trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) ip=00000000 tid=00b8 00b8:trace:seh:raise_exception info[0]=00000008 00b8:trace:seh:raise_exception info[1]=00000000 00b8:trace:seh:raise_exception eax=06e1f86c ebx=06e1fb78 ecx=00000000 edx=7bcb2550 esi=06e1f8ac edi=06e1fde0 00b8:trace:seh:raise_exception ebp=06e1f808 esp=06e1f7dc cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010216 00b8:trace:seh:call_vectored_handlers calling handler at 0x448700 code=c0000005 flags=0 00b8:trace:seh:call_vectored_handlers handler at 0x448700 returned 0 00b8:trace:seh:call_stack_handlers calling handler at 0x7bcb2550 code=c0000005 flags=0 00b8:trace:seh:call_stack_handlers handler at 0x7bcb2550 returned 2 00b8:trace:seh:call_stack_handlers calling handler at (nil) code=c0000005 flags=10 ... 00b8:err:seh:setup_exception_record stack overflow 1600 bytes in thread 00b8 eip f7c3f5ed esp 06d20cf0 stack 0x6d20000-0x6d21000-0x6e20000 00b8: *killed* exit_code=0 --- snip --- The root cause can be seen much earlier. NOTE: I made the output linear / "atomic" for easier reading. In reality various consecutive calls were interleaved from many other threads started in parallel. --- snip --- ... 0080:Call ucrtbase._beginthreadex(00000000,00000000,004969c0,065231e0,00000004,06523200) ret=00496955 0080:Call KERNEL32.CreateRemoteThread(ffffffff,00000000,00000000,004969c0,065231e0,00000004,06523200) ret=004486d6 0080:Call kernelbase.CreateRemoteThread(ffffffff,00000000,00000000,004969c0,065231e0,00000004,06523200) ret=7bc9f8e4 0080:Call ntdll.RtlCreateUserThread(ffffffff,00000000,00000001,00000000,00000000,00000000,004969c0,065231e0,06bfec30,06bfec24) ret=7b0434a6 0080: *fd* 16 <- 177 0080: new_thread( process=ffffffff, access=001fffff, suspend=1, request_fd=16, objattr={} ) 0080: new_thread() = 0 { tid=00b8, handle=00e0 } 0080:trace:virtual:map_view got mem in reserved area 0x7ffc4000-0x7ffc8000 0080:trace:virtual:VIRTUAL_DumpView View: 0x7ffc4000 - 0x7ffc7fff (valloc) 0080:trace:virtual:VIRTUAL_DumpView 0x7ffc4000 - 0x7ffc7fff c-rw- 0080:trace:virtual:map_view got mem in reserved area 0x6d20000-0x6e24000 0080:trace:virtual:VIRTUAL_DumpView View: 0x6d20000 - 0x6e23fff (valloc) 0080:trace:virtual:VIRTUAL_DumpView 0x6d20000 - 0x6d20fff c---- 0080:trace:virtual:VIRTUAL_DumpView 0x6d21000 - 0x6d21fff cgrw- 0080:trace:virtual:VIRTUAL_DumpView 0x6d22000 - 0x6e23fff c-rw- 0080:Ret ntdll.RtlCreateUserThread() retval=00000000 ret=7b0434a6 0080:Ret kernelbase.CreateRemoteThread() retval=000000e0 ret=7bc9f8e4 0080:Ret KERNEL32.CreateRemoteThread() retval=000000e0 ret=004486d6 0080:Call KERNEL32.GetThreadContext(000000e0,06bfea38) ret=00448963 0080:Call kernelbase.GetThreadContext(000000e0,06bfea38) ret=7bc9f8e4 0080: get_thread_context( handle=00e0, flags=00000010 ) 0080: get_thread_context() = ACCESS_DENIED { self=0, handle=0000, context={} } ... 00b8: init_thread( unix_pid=26107, unix_tid=26127, debug_level=1, teb=7ffc4000, entry=004969c0, reply_fd=24, wait_fd=26, cpu=x86 ) 00b8: *fd* 26 <- 180 ... 0080:Call ntdll.RtlNtStatusToDosError(c0000022) ret=7b04371d 0080:Ret ntdll.RtlNtStatusToDosError() retval=00000005 ret=7b04371d 0080:Ret kernelbase.GetThreadContext() retval=00000000 ret=7bc9f8e4 0080:Ret KERNEL32.GetThreadContext() retval=00000000 ret=00448963 ... 00b8: init_thread() = 0 { pid=0064, tid=00b8, server_start=1d61d46752028e8 (-2.0593510), info_size=0, version=602, all_cpus=00000003, suspend=1 } ... 0080:Ret ucrtbase._beginthreadex() retval=000000e0 ret=00496955 0080:Call KERNEL32.ResumeThread(000000e0) ret=0049699a 0080:Call kernelbase.ResumeThread(000000e0) ret=7bc9f8e4 0080:Call ntdll.NtResumeThread(000000e0,06bfed74) ret=7b043b01 0080: resume_thread( handle=00e0 ) 0080: resume_thread() = 0 { count=1 } 0080:Ret ntdll.NtResumeThread() retval=00000000 ret=7b043b01 0080:Ret kernelbase.ResumeThread() retval=00000001 ret=7bc9f8e4 0080:Ret KERNEL32.ResumeThread() retval=00000001 ret=0049699a --- snip --- Every newly created (suspended) thread gets the hardware debug breakpoint registers "consumed" with predefined values (handler) as part of the protection scheme. If it fails to do so, the goes haywire at some later point. The "good" case: --- snip --- ... 0080:Call ucrtbase._beginthreadex(00000000,00000000,004969c0,06523b30,00000004,06523b50) ret=00496955 0080:Call KERNEL32.CreateRemoteThread(ffffffff,00000000,00000000,004969c0,06523b30,00000004,06523b50) ret=004486d6 0080:Call kernelbase.CreateRemoteThread(ffffffff,00000000,00000000,004969c0,06523b30,00000004,06523b50) ret=7bc9f8e4 0080:Call ntdll.RtlCreateUserThread(ffffffff,00000000,00000001,00000000,00000000,00000000,004969c0,06523b30,06bfec30,06bfec24) ret=7b0434a6 0080: *fd* 28 <- 184 0080: new_thread( process=ffffffff, access=001fffff, suspend=1, request_fd=28, objattr={} ) 0080: new_thread() = 0 { tid=00c0, handle=00f4 } 0080:trace:virtual:map_view got mem in reserved area 0x7ffbc000-0x7ffc0000 0080:trace:virtual:VIRTUAL_DumpView View: 0x7ffbc000 - 0x7ffbffff (valloc) 0080:trace:virtual:VIRTUAL_DumpView 0x7ffbc000 - 0x7ffbffff c-rw- 0080:trace:virtual:map_view got mem in reserved area 0x6f40000-0x7044000 0080:trace:virtual:VIRTUAL_DumpView View: 0x6f40000 - 0x7043fff (valloc) 0080:trace:virtual:VIRTUAL_DumpView 0x6f40000 - 0x6f40fff c---- 0080:trace:virtual:VIRTUAL_DumpView 0x6f41000 - 0x6f41fff cgrw- 0080:trace:virtual:VIRTUAL_DumpView 0x6f42000 - 0x7043fff c-rw- 0080:Ret ntdll.RtlCreateUserThread() retval=00000000 ret=7b0434a6 0080:Ret kernelbase.CreateRemoteThread() retval=000000f4 ret=7bc9f8e4 0080:Ret KERNEL32.CreateRemoteThread() retval=000000f4 ret=004486d6 0080:Call KERNEL32.GetThreadContext(000000f4,06bfea38) ret=00448963 0080:Call kernelbase.GetThreadContext(000000f4,06bfea38) ret=7bc9f8e4 ... 00c0: *fd* 32 <- 185 00c0: *fd* 34 <- 186 00c0: init_thread( unix_pid=26107, unix_tid=26129, debug_level=1, teb=7ffbc000, entry=004969c0, reply_fd=32, wait_fd=34, cpu=x86 ) 00c0: init_thread() = 0 { pid=0064, tid=00c0, server_start=1d61d46752028e8 (-2.0605960), info_size=0, version=602, all_cpus=00000003, suspend=1 } ... 0080: get_thread_context( handle=00f4, flags=00000010 ) ... 00c0: *sent signal* signal=10 00c0: *signal* signal=19 ... 0080: get_thread_context() = PENDING { self=0, handle=00f8, context={} } 0080: select( flags=2, cookie=06bfd9a4, timeout=+0.0999631, size=8, prev_apc=0000, result={}, data={WAIT_ALL,handles={00f8}}, context={} ) 0080: select() = 0 { call={APC_NONE}, apc_handle=0000, context={} } 0080: get_thread_context( handle=00f8, flags=00000010 ) 0080: get_thread_context() = 0 { self=0, handle=0000, context={cpu=x86,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000} } 0080:trace:seh:__regs_NtGetContextThread 0xf4: dr0=00000000 dr1=00000000 dr2=00000000 dr3=00000000 dr6=00000000 dr7=00000000 0080:Ret kernelbase.GetThreadContext() retval=00000001 ret=7bc9f8e4 0080:Ret KERNEL32.GetThreadContext() retval=00000001 ret=00448963 0080:Call KERNEL32.GetThreadId(000000f4) ret=00448980 0080:Call kernelbase.GetThreadId(000000f4) ret=7bc9f8e4 0080:Call ntdll.NtQueryInformationThread(000000f4,00000000,06bfe988,0000001c,00000000) ret=7b04380a 0080: get_thread_info( handle=00f4, tid_in=0000 ) 0080: get_thread_info() = 0 { pid=0064, tid=00c0, teb=7ffbc000, entry_point=004969c0, affinity=000000ff, exit_code=259, priority=0, last=0, suspend_count=1, desc_len=0, desc=L"" } 0080:Ret ntdll.NtQueryInformationThread() retval=00000000 ret=7b04380a 0080:Ret kernelbase.GetThreadId() retval=000000c0 ret=7bc9f8e4 0080:Ret KERNEL32.GetThreadId() retval=000000c0 ret=00448980 0080:Call KERNEL32.SetThreadContext(000000f4,06bfea38) ret=00448a2b 0080:Call kernelbase.SetThreadContext(000000f4,06bfea38) ret=7bc9f8e4 0080:Call ntdll.NtSetContextThread(000000f4,06bfea38) ret=7b043b40 0080: set_thread_context( handle=00f4, context={cpu=x86,dr0=004490a2,dr1=004490a2,dr2=004490a2,dr3=004490a2,dr6=00000000,dr7=00000055} ) 0080: set_thread_context() = 0 { self=0 } 0080:Ret ntdll.NtSetContextThread() retval=00000000 ret=7b043b40 0080:Ret kernelbase.SetThreadContext() retval=00000001 ret=7bc9f8e4 0080:Ret KERNEL32.SetThreadContext() retval=00000001 ret=00448a2b 0080:Ret ucrtbase._beginthreadex() retval=000000f4 ret=00496955 0080:Call KERNEL32.ResumeThread(000000f4) ret=0049699a 0080:Call kernelbase.ResumeThread(000000f4) ret=7bc9f8e4 0080:Call ntdll.NtResumeThread(000000f4,06bfed74) ret=7b043b01 0080: resume_thread( handle=00f4 ) 0080: resume_thread() = 0 { count=1 } 0080:Ret ntdll.NtResumeThread() retval=00000000 ret=7b043b01 0080:Ret kernelbase.ResumeThread() retval=00000001 ret=7bc9f8e4 0080:Ret KERNEL32.ResumeThread() retval=00000001 ret=0049699a --- snip --- * https://www.winehq.org/pipermail/wine-devel/2020-April/165465.html * https://www.winehq.org/pipermail/wine-devel/2020-April/165466.html $ sha1sum LicenseSupportInstallerWin64.zip b22693fe4c29a60068c1f4c024232f9dc263b12b LicenseSupportInstallerWin64.zip $ du -sh LicenseSupportInstallerWin64.zip 282M LicenseSupportInstallerWin64.zip $ wine-5.7-58-g28ec279518 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.

1 3

[Bug 46377] New: The Bat!: weird behaviour of program icon on the KDE taskbar
by wine-bugs＠winehq.org 08 May '20

08 May '20

https://bugs.winehq.org/show_bug.cgi?id=46377 Bug ID: 46377 Summary: The Bat!: weird behaviour of program icon on the KDE taskbar Product: Wine Version: 4.0-rc3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mywine(a)schiermeier-it.de Distribution: --- Created attachment 63123 --> https://bugs.winehq.org/attachment.cgi?id=63123 Weird icon changes The program icon shown on the taskbar changes during the program is active und also when it closes. Also the label on taskbar is changing. This is Debian buster with Plasma (KDE) desktop. -- 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