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

[Bug 49511] New: Kontakt (Native Instruments) runtime is broken (regression)
by WineHQ Bugzilla 08 Jan '21

08 Jan '21

https://bugs.winehq.org/show_bug.cgi?id=49511 Bug ID: 49511 Summary: Kontakt (Native Instruments) runtime is broken (regression) Product: Wine Version: 5.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: pianoist(a)ya.ru Distribution: --- Created attachment 67637 --> https://bugs.winehq.org/attachment.cgi?id=67637 error example After migrating from the 5.01 to 5.10 (Ubuntu 19.10 to 20.20) Native instruments KONTAKT stopped load instruments, producing very strange list of errors like one attached. Such errors are not typical for KONTAKT and appear only when processing envelopes or LFO (internal structures, managed by GUI). After installing wine-stable 5.01 the problem disappeared -- 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 50437] New: wineserver crashes when running SteelSeries Engine client
by WineHQ Bugzilla 08 Jan '21

08 Jan '21

https://bugs.winehq.org/show_bug.cgi?id=50437 Bug ID: 50437 Summary: wineserver crashes when running SteelSeries Engine client Product: Wine Version: 5.20 Hardware: x86-64 URL: https://web.archive.org/web/20210101175629/https://eng ine.steelseriescdn.com/SteelSeriesEngine3.17.3Setup.ex e OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)winehq.org Reporter: z.figura12(a)gmail.com Regression SHA1: 0bbd3f66178abdc6ea15d30d2eb3b033367f8407 Distribution: --- The crash is due to heap corruption. It can usually be triggered by running the client through `wine start "SteelSeries Engine 3 Launcher.lnk"`; it either crashes almost immediately or after trying to close the main window. Needs `winetricks -q corefonts` (bug 32342). -- 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 2

[Bug 50454] New: Icons have non-transparent background in HxD
by WineHQ Bugzilla 08 Jan '21

08 Jan '21

https://bugs.winehq.org/show_bug.cgi?id=50454 Bug ID: 50454 Summary: Icons have non-transparent background in HxD Product: Wine Version: 6.0-rc5 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: gabrielopcode(a)gmail.com Distribution: --- Created attachment 69068 --> https://bugs.winehq.org/attachment.cgi?id=69068 Icons with pink background Since 61b9209221d28d5d02379791ac1316c1fc2ca3b7, adding 32bpp images to an image list doesn't mask out the background via mask anymore, even though the mask is processed properly. Icons in HxD, for example, have pink background instead of transparent. (see attachment) Prior to that patch, the alpha itself was modified for the background, which was also wrong as tests show. I've sent a patch to wine-devel that masks out the background while preserving the alpha channel. -- 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 50453] New: CDB (Part of Debugging Tools for Windows) fails resume debugging after entry point break (continue debug event: 'DBG_EXCEPTION_HANDLED' is an alias for 'DBG_CONTINUE')
by WineHQ Bugzilla 08 Jan '21

08 Jan '21

https://bugs.winehq.org/show_bug.cgi?id=50453 Bug ID: 50453 Summary: CDB (Part of Debugging Tools for Windows) fails resume debugging after entry point break (continue debug event: 'DBG_EXCEPTION_HANDLED' is an alias for 'DBG_CONTINUE') Product: Wine Version: 6.0-rc5 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, as it says. Found while trying to debug .NET executable with SOS Debugging Extension for windbg/cdb. --- snip --- ... 00d8: queue_exception_event( first=1, code=80000003, flags=00000000, record=00000000, address=7bc46838, len=24, params={00000000,00000000,00000000} ) 00d8: *sent signal* signal=10 00d8: queue_exception_event() = 0 { handle=003c } ... 0024:Ret KERNEL32.WaitForDebugEvent() retval=00000001 ret=022f28c5 0024:Call KERNEL32.SuspendThread(0000007c) ret=022f1d59 0024:Call ntdll.NtSuspendThread(0000007c,0031e0d4) ret=7b04c5a3 0024: suspend_thread( handle=007c ) 0024: suspend_thread() = 0 { count=0 } 0024:Ret ntdll.NtSuspendThread() retval=00000000 ret=7b04c5a3 0024:Ret KERNEL32.SuspendThread() retval=00000000 ret=022f1d59 0024:Call KERNEL32.GetThreadContext(0000007c,007f3aa0) ret=022f2009 0024: get_thread_context( handle=007c, flags=0000003f ) 00d8: *signal* signal=19 0024: get_thread_context() = 0 { self=0, handle=0000, context={cpu=x86,eip=7bc46839,esp=0031ef68,ebp=0031efcc,eflags=00000246,cs=0023,ss=002b,ds=002b,es=002b,fs=0063,gs=006b,eax=ffffffff,ebx=7bc6d2c0,ecx=0031ef7c,edx=0031efc4,esi=0031ef6c,edi=7ffc2000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,fp.ctrl=ffff027f,fp.status=ffff0020,fp.tag=ffffffff,fp.err_off=f7ccf321,fp.err_sel=00000023,fp.data_off=0031e800,fp.data_sel=ffff002b,fp.cr0npx=00000020,fp.reg0=0,fp.reg1=0,fp.reg2=0,fp.reg3=0,fp.reg4=0,fp.reg5=0,fp.reg6=0,fp.reg7=1.16561e+12,extended={0020027f,...,00000000}} } ... 0024:Call KERNEL32.ReadProcessMemory(00000078,7bc46838,0031eaaf,00000001,0031e9f8) ret=022f1432 0024:Call ntdll.NtReadVirtualMemory(00000078,7bc46838,0031eaaf,00000001,0031e9f8) ret=7b0294ec 0024: read_process_memory( handle=0078, addr=7bc46838 ) 00d8: *signal* signal=19 0024: read_process_memory() = 0 { data={cc} } 0024:Ret ntdll.NtReadVirtualMemory() retval=00000000 ret=7b0294ec 0024:Ret KERNEL32.ReadProcessMemory() retval=00000001 ret=022f1432 ... 0024:Call KERNEL32.SetThreadContext(0000007c,007f3aa0) ret=022f2095 0024:Call ntdll.NtSetContextThread(0000007c,007f3aa0) ret=7b04be93 0024: set_thread_context( handle=007c, context={cpu=x86,eip=7bc46839,esp=0031ef68,ebp=0031efcc,eflags=00000246,cs=0023,ss=002b,ds=002b,es=002b,fs=0063,gs=006b,eax=ffffffff,ebx=7bc6d2c0,ecx=0031ef7c,edx=0031efc4,esi=0031ef6c,edi=7ffc2000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,fp.ctrl=ffff027f,fp.status=ffff0020,fp.tag=ffffffff,fp.err_off=f7ccf321,fp.err_sel=00000023,fp.data_off=0031e800,fp.data_sel=ffff002b,fp.cr0npx=00000020,fp.reg0=0,fp.reg1=0,fp.reg2=0,fp.reg3=0,fp.reg4=0,fp.reg5=0,fp.reg6=0,fp.reg7=1.16561e+12,extended={0020027f,...,00000000}} ) 0024: set_thread_context() = 0 { self=0 } 0024:Ret ntdll.NtSetContextThread() retval=00000000 ret=7b04be93 0024:Ret KERNEL32.SetThreadContext() retval=00000001 ret=022f2095 ... 0024:Call KERNEL32.ResumeThread(0000007c) ret=022f1de9 0024:Call ntdll.NtResumeThread(0000007c,0031e614) ret=7b04be53 0024: resume_thread( handle=007c ) 0024: resume_thread() = 0 { count=1 } 0024:Ret ntdll.NtResumeThread() retval=00000000 ret=7b04be53 0024:Ret KERNEL32.ResumeThread() retval=00000001 ret=022f1de9 ... 0024:Call KERNEL32.ContinueDebugEvent(000000d4,000000d8,00010001) ret=022f2b24 0024: continue_debug_event( pid=00d4, tid=00d8, status=65537 ) 0024: continue_debug_event() = INVALID_PARAMETER 0024:Call ntdll.RtlNtStatusToDosError(c000000d) ret=7b00f5ff 0024:Ret ntdll.RtlNtStatusToDosError() retval=00000057 ret=7b00f5ff 0024:Ret KERNEL32.ContinueDebugEvent() retval=00000000 ret=022f2b24 0024:Call KERNEL32.GetLastError() ret=022f2b2e 0024:Ret KERNEL32.GetLastError() retval=00000057 ret=022f2b2e ... 0024:Call KERNEL32.WideCharToMultiByte(00000000,00000000,02338080 L"Win32 error 0n87",ffffffff,00000000,00000000,00000000,00000000) ret=020f669a ... 0024:Call KERNEL32.WideCharToMultiByte(00000000,00000000,020285d8 L"This usually indicates that the debuggee has been\nkilled out from underneath the debugger.\nYou can use .tlist to see if the debuggee still exists.\n",ffffffff,00000000,00000000,00000000,00000000) ret=020f669a --- snip --- Microsoft docs: https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-con… It's not listed there but common knowledge that 'DBG_EXCEPTION_HANDLED' is an alias for 'DBG_CONTINUE' in 32-bit environment. Also mentioned here: https://source.winehq.org/git/wine.git/commitdiff/fe36b7baca253f1e95cc790b8… ("ntdll: Made DBG_EXCEPTION_HANDLED a synonym of DBG_CONTINUE for exception handlers."), in 2005 --- snip --- $ grep -Hrni DBG_EXCEPTION_HANDLED include/ntstatus.h:1694:#define DBG_EXCEPTION_HANDLED ((NTSTATUS) 0x00010001) include/winerror.h:640:#define ERROR_DBG_EXCEPTION_HANDLED 766 include/winnt.h:652:#define DBG_EXCEPTION_HANDLED ((DWORD) 0x00010001) dlls/ntdll/error.c:196: ERROR_DBG_EXCEPTION_HANDLED, /* 00010001 (DBG_EXCEPTION_HANDLED) */ dlls/ntdll/tests/error.c:543: cmp2(DBG_EXCEPTION_HANDLED, ERROR_DBG_EXCEPTION_HANDLED); dlls/ntdll/unix/thread.c:430: if (status == DBG_CONTINUE || status == DBG_EXCEPTION_HANDLED) dlls/ntdll/unix/signal_arm64.c:669: if (status == DBG_CONTINUE || status == DBG_EXCEPTION_HANDLED) dlls/ntdll/unix/signal_i386.c:1615: if (status == DBG_CONTINUE || status == DBG_EXCEPTION_HANDLED) dlls/ntdll/unix/signal_x86_64.c:1982: if (status == DBG_CONTINUE || status == DBG_EXCEPTION_HANDLED) dlls/ntdll/unix/signal_arm.c:571: if (status == DBG_CONTINUE || status == DBG_EXCEPTION_HANDLED) dlls/ntdll/make_errors:67: DBG_EXCEPTION_HANDLED ERROR_DBG_EXCEPTION_HANDLED --- snip --- Wine source: https://source.winehq.org/git/wine.git/blob/9b12eae9ea445bbdeae196312fb65d2… --- snip --- 674 /* Continue a debug event */ 675 DECL_HANDLER(continue_debug_event) 676 { 677 struct process *process; 678 679 if (req->status != DBG_EXCEPTION_NOT_HANDLED && 680 req->status != DBG_CONTINUE && 681 req->status != DBG_REPLY_LATER) 682 { 683 set_error( STATUS_INVALID_PARAMETER ); 684 return; 685 } 686 687 if ((process = get_process_from_id( req->pid ))) 688 { 689 struct thread *thread = get_thread_from_id( req->tid ); 690 if (thread) 691 { 692 continue_debug_event( process, thread, req->status ); 693 release_object( thread ); 694 } 695 release_object( process ); 696 } 697 } ---- snip --- Following relevant changes made this a regression: * https://source.winehq.org/git/wine.git/commitdiff/7332de64a5a204cc285bdc1f8… ("server: Validate status in continue_debug_event."), Part of Wine 5.2 * https://source.winehq.org/git/wine.git/commitdiff/e2a1f00a3850dbce89ec0f85b… ("server: Implement DBG_REPLY_LATER handling.") With a fix applied, debugging (resuming) with CDB works again. $ wine --version wine-6.0-rc5 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 5

[Bug 49500] New: Wine is not displaying any windows
by WineHQ Bugzilla 08 Jan '21

08 Jan '21

https://bugs.winehq.org/show_bug.cgi?id=49500 Bug ID: 49500 Summary: Wine is not displaying any windows Product: Wine Version: 5.0 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: vld10(a)yandex.ru Distribution: --- If no monitor attached, wine is not displaying any windows. Trying to run winecfg. On wine-4.0.3 all works as expected. On wine-5.0 & wine-5.11 no window is displayed, although programs seems to work. In both cases, running winecfg via terminal, produces an output. Setup: start X via /etc/init.d/xdm; connect to display via x11vnc when necessary. Workaround1: do xinit -- /usr/bin/X -extension RANDR. Workaround2: do xinit -- /usr/bin/Xvfb Here is my xrandr output for default Setup: Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096 VGA-1 disconnected primary (normal left inverted right x axis y axis) Here is my xrandr output for Workaround 2: xrandr: Failed to get size of gamma for output screen Screen 0: minimum 1 x 1, current 1280 x 1024, maximum 1280 x 1024 screen connected 1280x1024+0+0 0mm x 0mm 1280x1024 0.00* I think this is enough info to reproduce. Let me know what logs to provide. -- 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 26016] New: xmllite installer crashes about 1 in 30 runs
by wine-bugs＠winehq.org 08 Jan '21

08 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=26016 Summary: xmllite installer crashes about 1 in 30 runs Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com While running the regression test for winetricks-alpha, I noticed that installing xmllite crashed like this: fixme:wintrust:CryptCATGetCatAttrInfo 0x13e700, L"SPLevel" wine: Unhandled page fault on read access to 0xffffffff at address 0x68a4875f (thread 0013), starting debugger... Backtrace: =>0 0x68a4875f SetupCommitFileQueueW+0x3cf(owner=(nil), handle=0x1414f0, handler=0x68a49040, context=0x33bcdc) [include/wine/unicode.h:200] in setupapi (0x0033bcec) 1 0x68a49031 SetupCommitFileQueueA+0x40(owner=(nil), queue=0x1414f0, handler=0x103be4b, context=0x33c228) [dlls/setupapi/queue.c:879] in setupapi (0x0033f384) 0x68a4875f SetupCommitFileQueueW+0x3cf [include/wine/unicode.h:200] in setupapi: cmpw $0,0x0(%edx) I ran the installer in a loop to try to reproduce, and on the 34th run, I got a different crash at about the same place: fixme:wintrust:CryptCATGetCatAttrInfo 0x1c8ba8, L"SPLevel" err:setupapi:SetupDefaultQueueCallbackA copy error 3 "c:\\e64013c352a7bbb4a28da0908ecc09\\SP2QFE\\xmllite.dll" -> "c:\\windows\\$hf_mig$\\KB915865\\SP2QFE\\xmllite.dll" fixme:setupapi:pSetupGetGlobalFlags stub fixme:setupapi:pSetupGetGlobalFlags stub wine: Unhandled page fault on read access to 0xffffffff at address 0x68c72252 (thread 003f), starting debugger... Backtrace: =>0 0x68c72252 StringTableDestroy+0x42(hStringTable=0x13ed98) [dlls/setupapi/stringtable.c:177] in setupapi (0x0033f384) 0x68c72252 StringTableDestroy+0x42 [dlls/setupapi/stringtable.c:177] in setupapi: movl 0x0(%edx,%edi,1),%edx I ran it again in a loop with WINEDEBUG=warn+heap,+setupapi, and on the 28th, 111th, and 114th runs, saw the error: ... fixme:advapi:RegisterEventSourceW (L"",L"NtServicePack"): stub fixme:advapi:ReportEventA (0xcafe4242,0x0004,0x0000,0x400e1119,0x120df8,0x0002,0x00000000,0x34bcb8,(nil)): stub fixme:advapi:ReportEventW (0xcafe4242,0x0004,0x0000,0x400e1119,0x120df8,0x0002,0x00000000,0x118f90,(nil)): stub fixme:advapi:DeregisterEventSource (0xcafe4242) stub err:heap:HEAP_ValidateInUseArena Heap 0x110000: block 0x137420 tail overwritten at 0x137430 (byte 0/32 == 0xff) 28 -- 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 51

[Bug 32554] New: XPSEP instalation fails with "Path not found" error
by wine-bugs＠winehq.org 08 Jan '21

08 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=32554 Bug #: 32554 Summary: XPSEP instalation fails with "Path not found" error Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: timoteo(a)unimed-agm.com.br Classification: Unclassified Created attachment 42963 --> http://bugs.winehq.org/attachment.cgi?id=42963 Backtrace shown in error window I got an error while trying to install .net framework 3.0 SP1 using winetricks (winetricks dotnet30sp1). I tried installing it by hand also (wine msiexec /i "XPSEP XP and Server 2003 32 bit.msi" /qb), but got the same error. Terminal output shows (among lots of fixmes) the following lines: err:eventlog:ReportEventW L"Windows" err:eventlog:ReportEventW L"" err:eventlog:ReportEventW L"Path not found.\r\n" And After debug information, the following lines: err:msi:ITERATE_Actions Execution halted, action L"EPUpdateInstallAction" returned 1627 err:msi:custom_get_thread_return Invalid Return Code 3 Information: Ubuntu Quantal running on a VirtualBox (I have the same problems running on physical hardware) $ uname -a Linux unimed-box 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:32:08 UTC 2012 i686 i686 i686 GNU/Linux $ wine --version wine-1.5.19 Backtrace attached -- 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 23

[Bug 36387] New: Multiple Microsoft installers crash or hang with heap corruption (XmlLite, XPSEP, IE7)
by wine-bugs＠winehq.org 08 Jan '21

08 Jan '21

https://bugs.winehq.org/show_bug.cgi?id=36387 Bug ID: 36387 Summary: Multiple Microsoft installers crash or hang with heap corruption (XmlLite, XPSEP, IE7) Product: Wine Version: 1.7.18 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: setupapi Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, continuation of bug 26016 I did more testing, trying to extract a pattern out of the crashes. Unfortunately there is no clear pattern. There was one crash log which gave me another idea though. --- snip --- $ WINEDEBUG=+tid,+seh,+relay,+heap wine ./update.exe -q >>log.txt 2>&1 ... 0035:Call setupapi.SetupInitDefaultQueueCallbackEx(00000000,ffffffff,00000000,00000000,00000000) ret=01053eac 0035:Call ntdll.RtlAllocateHeap(00110000,00000000,0000000c) ret=7e0c34d9 0035:trace:heap:RtlAllocateHeap (0x110000,70000062,0000000c): returning 0x1b70c0 0035:Ret ntdll.RtlAllocateHeap() retval=001b70c0 ret=7e0c34d9 0035:Ret setupapi.SetupInitDefaultQueueCallbackEx() retval=001b70c0 ret=01053eac ... 0035:Call setupapi.SetupCommitFileQueueA(00000000,001f3908,7e09e35c,001b70c0) ret=01053f55 0035:Ret setupapi.SetupCommitFileQueueA() retval=00000001 ret=01053f55 ... 0035:Call setupapi.SetupCommitFileQueueA(00000000,0011c5a0,0103be4b,0034c1b8) ret=01055f68 0035:Call setupapi.SetupDefaultQueueCallbackA(001b70c0,00000001,00000000,00000000) ret=0103bf44 0035:Ret setupapi.SetupDefaultQueueCallbackA() retval=00000001 ret=0103bf44 0035:Call ntdll.RtlFreeHeap(00110000,00000000,00000000) ret=7e0bf759 0035:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e0bf759 0035:Call ntdll.RtlAllocateHeap(00110000,00000000,00000080) ret=7e0bf782 0035:err:heap:HEAP_ValidateInUseArena Heap 0x110000: free block 0x1b70e0 overwritten at 0x1b70f0 by ffffffff ... --- snip --- There was a damaged heap block located near the context structure for the default queue callback. MSDN: http://msdn.microsoft.com/en-us/library/aa376956%28v=vs.85%29.aspx --- quote --- The SetupInitDefaultQueueCallback function builds the context structure that is used by the default queue callback routine. It returns a void pointer to that structure. This structure is essential for the default callback routine's operation and must be passed to the callback routine. You do can this either by specifying the void pointer as the context in a call to SetupCommitFileQueue, or by specifying the void pointer as the context parameter when calling SetupDefaultQueueCallback from a custom callback routine. This context structure must not be altered or referenced by the setup application. --- quote --- What if these guys writing the update installers, distributing their own copy of setupapi (updspapi) give a damn about MSDN and treat the context callback structure not as opaque, possibly peek/modify structure members? The context structured started at 0x001b70c0 .. the damaged part was at 0x1b70f0. Unfortunately, I could not replicate the corruption pattern at this offset with more tests. I gave the callback context structure a larger block - 0x40 bytes to be safe. The block was allocated with HEAP_ZERO_MEMORY to make sure that even if the installer code peeks into structure it doesn't see garbage. The current structure layout (member offsets) is most likely different from their layout but that doesn't seem to play a role here. With that change in place the crashes were gone. I got a random heap crit sec hang out of several hundred tries though (maybe unrelated?). Austin, can you pad the structure here up to 0x40 bytes: http://source.winehq.org/git/wine.git/blob/4d796458d0ed517d45adc57a1aedaf1c… --- snip --- 39 /* context structure for the default queue callback */ 40 struct default_callback_context 41 { 42 HWND owner; 43 HWND progress; 44 UINT message; 45 }; --- snip --- zero init alloc (HEAP_ZERO_MEMORY) here: http://source.winehq.org/git/wine.git/blob/4d796458d0ed517d45adc57a1aedaf1c… --- snip --- 1480 PVOID WINAPI SetupInitDefaultQueueCallbackEx( HWND owner, HWND progress, UINT msg, 1481 DWORD reserved1, PVOID reserved2 ) 1482 { 1483 struct default_callback_context *context; 1484 1485 if ((context = HeapAlloc( GetProcessHeap(), 0, sizeof(*context) ))) 1486 { 1487 context->owner = owner; 1488 context->progress = progress; 1489 context->message = msg; 1490 } 1491 return context; 1492 } --- snip --- and retest? Thanks. 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 13

[Bug 16879] New: .NET 3.0: XPSEPSC installer fails due to unimpl kernel32.RtlCaptureStackBackTrace
by wine-bugs＠winehq.org 08 Jan '21

08 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=16879 Summary: .NET 3.0: XPSEPSC installer fails due to unimpl kernel32.RtlCaptureStackBackTrace Product: Wine Version: 1.1.12 Platform: Other URL: http://www.microsoft.com/downloads/details.aspx?FamilyID =10cc340b-f857-4a14-83f5-25634c3bf043 OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, after getting past bug 16878 one runs into next one. Prerequisite: 1. clean WINEPREFIX 2. sh winetricks -q dotnet20 3. download .NET 3.0 Framework installer from: http://download.microsoft.com /download/4/d/a/4da3a5fa-ee6a-42b8-8bfa-ea5c4a458a7d/dotnetfx3setup.exe (sha1sum: a566bcd2ffffc3842a95adc57f7df3f8cd11577f) 4. export _SFX_CAB_SHUTDOWN_REQUEST=1 (workaround, see bug 9158) 5. wine ./dotnetfx3setup.exe It might take a while until all required packages are downloaded using BITS. Note: If you need to redo steps, backup the directory "dotnetfx304506.30" from "c:\\windows\\temp" to a different location, remove ~/.wine, copy "dotnetfx304506.30" again to "c:\\windows\\temp" to prevent BITS from downloading over and over again. --- snip --- fixme:advapi:RegisterEventSourceW ((null),L"Microsoft-Windows-SpoolerFilterPipelineSVC"): stub fixme:winspool:OpenPrinterW PRINTER_DEFAULTS ignored => (null),(nil),0x00000001 fixme:winspool:AddPrinterW DocumentPropertiesW on printer L"Microsoft XPS Document Writer" fails wine: Call from 0x105e0b0 to unimplemented function KERNEL32.dll.RtlCaptureStackBackTrace, aborting wine: Unimplemented function KERNEL32.dll.RtlCaptureStackBackTrace called at address 0x105e0b0 (thread 0014), starting debugger... Unhandled exception: unimplemented function KERNEL32.dll.RtlCaptureStackBackTrace called in 32-bit code (0x7bc485e6). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7bc485e6 ESP:0033ef1c EBP:0033ef70 EFLAGS:00000216( - 00 - IAP1) EAX:0033ef1c EBX:7bc9b830 ECX:0034002d EDX:007d3e0c ESI:0033f7cc EDI:007d3e18 Stack dump: 0x0033ef1c krb5_rc_dfl_init+0xfc: 80000100 00000001 00000000 0105e0b0 0x0033ef2c krb5_rc_dfl_init+0x10c: 00000002 010957de 01095722 60143151 0x0033ef3c krb5_rc_dfl_init+0x11c: 00110000 7bc9b830 00000000 00000000 0x0033ef4c krb5_rc_dfl_init+0x12c: 00000064 7bc43fe6 00000000 7bc6ebc4 0x0033ef5c krb5_rc_dfl_init+0x13c: 0033efc4 60145124 00000040 7bc6ed4d 0x0033ef6c krb5_rc_dfl_init+0x14c: 007d1288 0033efa4 0034003c 010957de Backtrace: =>0 0x7bc485e6 stub_entry_point+0x4b(dll="KERNEL32.dll", name="RtlCaptureStackBackTrace", ret_addr=0x105e0b0) [/opt/wine/wine-git/dlls/ntdll/loader.c:192] in ntdll (0x0033ef70) 1 0x0034003c in libkrb5.so.3 (+0x7503c) (0x0033efa4) 2 0x0105dbeb in printfilterpipelinesvc (+0x5dbeb) (0x0033efb4) 3 0x0105de7c in printfilterpipelinesvc (+0x5de7c) (0x0033f1dc) 4 0x0105e036 in printfilterpipelinesvc (+0x5e036) (0x0033f1fc) 5 0x0101cfb3 in printfilterpipelinesvc (+0x1cfb3) (0x0033fc34) 6 0x0101d020 in printfilterpipelinesvc (+0x1d020) (0x0033fd28) 7 0x0101dab1 in printfilterpipelinesvc (+0x1dab1) (0x0033fd6c) 8 0x0101be04 in printfilterpipelinesvc (+0x1be04) (0x0033fd94) 9 0x0101be76 in printfilterpipelinesvc (+0x1be76) (0x0033fdb0) 10 0x0101bf7f in printfilterpipelinesvc (+0x1bf7f) (0x0033fdd0) 11 0x0101e133 in printfilterpipelinesvc (+0x1e133) (0x0033fef8) 12 0x7b87ebd0 start_process+0xe4(arg=(nil)) [/opt/wine/wine-git/dlls/kernel32/process.c:904] in kernel32 (0x0033ffe8) ... 00000025 (D) C:\windows\system32\unknown\PrintFilterPipelineSvc.exe --- snip --- In case you are wondering about "unknown" in path, Wine doesn't know about directory id 55 which is printer processor directory. Although it might deserve its own bug I mention it here: --- snip --- 0045:fixme:setupapi:create_system_dirid unknown dirid 55 --- snip --- That whole print processor stuff needs to be tackled separately. --- snip --- 0032:Call KERNEL32.CopyFileW(0033f814 L"C:\\3e0c51033dbb7684e997f131b3146a\\update\\..\\i386\\filterpipelineprintproc.dll",0033fa1c L"C:\\windows\\system32\\spool\\prtprocs\\w32x86\\filterpipelineprintproc.dll",00000000) ret=0101cf79 0032:Ret KERNEL32.CopyFileW() retval=00000001 ret=0101cf79 0032:Call winspool.drv.AddPrintProcessorW(00000000,01002388 L"Windows NT x86",01001f9c L"filterpipelineprintproc.dll",01001fd4 L"MS_XPS") ret=0101d032 0032:fixme:winspool:AddPrintProcessorW ((null),L"Windows NT x86",L"filterpipelineprintproc.dll",L"MS_XPS"): stub 0032:Ret winspool.drv.AddPrintProcessorW() retval=00000000 ret=0101d032 --- snip --- There are several issues, though I leave them alone for now ... --- After adding RtlCaptureStackBackTrace() forward to kernel32.spec and adding stub to ntdll (FIXME params + returning STATUS_NOT_IMPLEMENTED), the crash is prevented. 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 9

[Bug 16906] New: .NET 3.0: XPSEPSC installer copies print processor files to wrong directory (setupapi unhandled dirid 55)
by wine-bugs＠winehq.org 08 Jan '21

08 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=16906 Summary: .NET 3.0: XPSEPSC installer copies print processor files to wrong directory (setupapi unhandled dirid 55) Product: Wine Version: 1.1.12 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: setupapi AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, I mentioned this in bug 16879 and before the issue gets lost... Wine doesn't know about directory id 55 which is print processor directory. --- snip --- ... 00c4:fixme:setupapi:create_system_dirid unknown dirid 55 00c4:Call KERNEL32.GetSystemDirectoryW(00000000,00000000) ret=789dacd1 00c4:Ret KERNEL32.GetSystemDirectoryW() retval=00000014 ret=789dacd1 ... 00c4:Call KERNEL32.lstrlenW(0015ab20 L"C:\\windows\\system32\\unknown") ret=789ecb4c ... 00c4:Call KERNEL32.CreateFileA(006f26f0 "c:\\windows\\system32\\unknown\\printfilterpipelinesvc.exe",80000000,00000003,00000000,00000003,08000000,00000000) ret=0106825d ... --- snip --- --- snip dlls/setupapi/dirid.c --- /* create the string for a system dirid */ static const WCHAR *create_system_dirid( int dirid ) { ... case DIRID_PRINTPROCESSOR: /* FIXME */ default: FIXME( "unknown dirid %d\n", dirid ); return get_unknown_dirid(); } ... } --- snip dlls/setupapi/dirid.c --- GetPrintProcessorDirectoryW() should provide all required information. With patch applied: --- snip --- ... 0031:Call KERNEL32.CopyFileW(0015b310 L"c:\\10976f8595cea39afb\\PrintFilterPipelineSvc.exe",0015cb70 L"C:\\windows\\system32\\spool\\prtprocs\\w32x86\\PrintFilterPipelineSvc.exe",00000000) ret=60afb0c9 --- snip --- 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