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

[Bug 50355] New: Commandos 2: Men of Courage hangs after starting
by WineHQ Bugzilla Jan. 8, 2021

Jan. 8, 2021

https://bugs.winehq.org/show_bug.cgi?id=50355 Bug ID: 50355 Summary: Commandos 2: Men of Courage hangs after starting Product: Wine Version: 5.21 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: quartz Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com CC: baskanov(a)gmail.com Regression SHA1: a73460bca0e7f97fc371264bd5ad669357882b68 Distribution: --- Commandos 2 (legacy version, not the HD remaster) hangs completely after starting, showing only a black screen with the game cursor visible on the screen. This was tested with the GOG.com version. Maybe not a real regression because videos, including the intro video didn't work correctly before (intro video was simply skipped and the game was loading the main menu). The current problem is present since commit a73460bca0e7f97fc371264bd5ad669357882b68 amstream: Wait for the state transition to complete in AMMultiMediaStream::SetState. With the commit reverted, the game works just as before (no intro video, but the main menu is accessible). Plain terminal output shows only 0024:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION 0024:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work. wine-6.0-rc2-52-g0aa6f8e2ea1 -- 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 50151] New: World of Tanks fails to launch if LC_LANG/LC_ALL are set ja_JP
by WineHQ Bugzilla Jan. 8, 2021

Jan. 8, 2021

https://bugs.winehq.org/show_bug.cgi?id=50151 Bug ID: 50151 Summary: World of Tanks fails to launch if LC_LANG/LC_ALL are set ja_JP Product: Wine Version: 5.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ankouslash(a)yahoo.co.jp Distribution: --- Created attachment 68659 --> https://bugs.winehq.org/attachment.cgi?id=68659 WoT's python.log including failed case and launched case Since wine-4.20, World of Tanks fails to launch if LC_LANG and LC_ALL are set ja_JP.UTF-8. Error is recorded in python.log of WoT, please see attached. Steps to reproduce: 1. Launch Wargaming.net Game Center 2. Click"PLAY" button in WORLD OF TANKS tab Actual result: World of Tanks fails while syncing data on launching. In the following case, WoT is launched properly: - Use wine-4.19 - Use latest wine with LC_LANG/LC_ALL=en_US.UTF-8 Version: wine & wine-staging 4.20-5.21 Platform: Arch Linux (64bit) https://worldoftanks.com/ -- 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 17

[Bug 49511] New: Kontakt (Native Instruments) runtime is broken (regression)
by WineHQ Bugzilla Jan. 8, 2021

Jan. 8, 2021

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 50454] New: Icons have non-transparent background in HxD
by WineHQ Bugzilla Jan. 8, 2021

Jan. 8, 2021

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 Jan. 8, 2021

Jan. 8, 2021

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 50437] New: wineserver crashes when running SteelSeries Engine client
by WineHQ Bugzilla Jan. 8, 2021

Jan. 8, 2021

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 49500] New: Wine is not displaying any windows
by WineHQ Bugzilla Jan. 8, 2021

Jan. 8, 2021

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 Jan. 8, 2021

Jan. 8, 2021

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 Jan. 8, 2021

Jan. 8, 2021

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 Jan. 8, 2021

Jan. 8, 2021

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