wine-bugs September 2014

wine-bugs@winehq.org

1 participants
9491 discussions

[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

[Bug 16878] New: .NET 3.0: XPSEPSC installer fails due to missing ntoskrnl.exe placeholder and version resource
by wine-bugs＠winehq.org 08 Jan '21

08 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=16878 Summary: .NET 3.0: XPSEPSC installer fails due to missing ntoskrnl.exe placeholder and version resource 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: ntoskrnl AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, NOTE: bug 16875 which covers two issues in setupapi.SetupGetTargetPathW needs to be properly fixed for *both* cases, see "update.inf" snippet which is part of this bug report. After bug 16875 (and 16876) are fixed, the installer fails: "c:\\windows\\temp\\dd_dotnetfx3error.txt": --- snip --- [01/11/09,11:36:24] Microsoft .NET Framework 2.0: [2] Error: Installation failed for component Microsoft .NET Framework 2.0. MSI returned error code 1603 [01/11/09,11:36:37] WapUI: [2] DepCheck indicates Microsoft .NET Framework 2.0 is not installed. [01/11/09,11:36:37] WapUI: [2] DepCheck indicates Microsoft .NET Framework 3.0 was not attempted to be installed. --- snip --- "c:\\windows\\temp\\dd_dotnetfx3install.txt": --- snip --- [01/11/09,11:36:37] WapUI: Return for RGB Rast indicates a successful installation. DepCheck indicates the component is installed. [01/11/09,11:36:37] WapUI: Return for MSXML 6.0 Parser indicates a successful installation. DepCheck indicates the component is installed. [01/11/09,11:36:37] WapUI: Return for WIC Installer indicates a successful installation. DepCheck indicates the component is installed. [01/11/09,11:36:37] WapUI: DepCheck indicates Microsoft .NET Framework 2.0 is not installed. --- snip --- Obviously bug 12401 (which I have analyzed in bug 10601). So the prerequisite expands. 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. After applying prerequisite the installer fails again: "c:\\windows\\temp\\dd_dotnetfx3error.txt": --- snip --- [01/11/09,11:53:13] XPSEPSC x86 Installer: [2] Error code 1603 for this component means "ERROR_INSTALL_FAILURE " [01/11/09,11:53:13] XPSEPSC x86 Installer: [2] Setup Failed on component XPSEPSC x86 Installer [01/11/09,11:53:24] WapUI: [2] DepCheck indicates XPSEPSC x86 Installer is not installed. --- snip --- "c:\\windows\\temp\\dd_XPS.txt": --- snip --- [dd_XPS.txt] 0.007: ================================================================================ 0.008: 2009/01/11 11:53:12.167 (local) 0.009: C:\a71b96a363115310c46014e60bbc1d36\update\update.exe (version 6.2.29.0) 0.009: Hotfix started with following command line: /quiet /norestart /log:C:\windows\temp\dd_XPS.txt 0.009: GetKernelType: GetInternalFilename failed 0.552: In Function TestVolatileFlag, line 11873, RegOpenKeyEx failed with error 0x2 0.552: In Function TestVolatileFlag, line 11905, RegOpenKeyEx failed with error 0x2 0.552: DoInstallation: CleanPFR failed: 0x2 0.553: SetProductTypes: InfProductBuildType=BuildType.IP 0.554: SetAltOsLoaderPath: No section uses DirId 65701; done. 0.554: RegisterDll: Executing command line: "C:\windows\system32\regsvr32.exe" /s "C:\windows\system32\licdll.dll" ... 0.634: RegisterDll: Exit code=0x00000001 0.634: RegisterDll: Executing command line: "C:\windows\system32\regsvr32.exe" /s "C:\windows\system32\regwizc.dll" ... 0.712: RegisterDll: Exit code=0x00000001 0.713: Unexpected Error While Executing Line 1 ( Condition.Requirement ) of W2K.Condition 0.713: ExConditionalEvaluateSection: Syntax error in 'Condition' key of section W2K.Condition. 0.713: DoInstallation: Error 0xf00c while evaluating extended conditional section [ProductInstall.ExtendedConditional]. 0.713: CleanupTrustedInfFile: GetFileAttributes for C:\windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\update.cat failed: 0x2 0.714: The XpsEPSC c:\a71b96a363115310c46014e60bbc1d36\update\update.inf file is not correct. 0.714: Update.exe extended error code = 0xf00c 0.714: Update.exe return code was masked to 0x643 for MSI custom action compliance. --- snip --- Relevant "update.inf": --- snip --- ... [ProductInstall.ExtendedConditional] ConditionInstall=W2K.Condition [W2K.Condition] Condition = SingleOp, Condition.Requirement ConditionalOperations=Install.Not2k [Condition.Requirement] GreatOrEqualOp=CheckFilever, System32.files, ntoskrnl.exe, >=, 5.1.0.0 ... [DestinationDirs] Copy.System32=11 Copy.System32.not2k=11 Copy.PrintProc=55 Copy.dllcache=65619 Copy.dllcache.not2k=65619 --- snip --- Adding version resource to ntoskrnl.exe alone is not sufficient, a placeholder needs to be present in system32: --- snip --- 0028:Call KERNEL32.FindFirstFileA(0033ac3c "C:\\windows\\system32\\ntoskrnl.exe",0033a18c) ret=0106da6d 0028:Ret KERNEL32.FindFirstFileA() retval=ffffffff ret=0106da6d 0028:Call KERNEL32.GetLastError() ret=0106b894 0028:Ret KERNEL32.GetLastError() retval=00000002 ret=0106b894 ... 0028:Call msvcrt._vsnprintf(0033a967,000007f7,01027e3c "Unexpected Error While Executing Line %d ( %ws ) of %ws \n",0033b198) ret=0106b900 --- snip --- After fixing this problem the condition is satisfied. 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 34217] New: MS XPSEP GUI installer crashes if dotnet20 installed
by wine-bugs＠winehq.org 08 Jan '21

08 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=34217 Bug #: 34217 Summary: MS XPSEP GUI installer crashes if dotnet20 installed Product: Wine Version: 1.7.0 Platform: x86-64 URL: http://download.microsoft.com/download/2/5/2/2526f55d- 32bc-410f-be18-164ba67ae07d/XPSEP%20XP%20and%20Server% 202003%2032%20bit.msi OS/Version: Linux Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk Blocks: 32164, 32166, 32167, 32168 Classification: Unclassified Created attachment 45524 --> http://bugs.winehq.org/attachment.cgi?id=45524 Wine 1.7.0 console output The Microsoft XML Paper Specification Essentials Pack (XPSEP) GUI installer fails 100% of the time when dotnet20 is first installed in a clean WINEPREFIX. err:msi:ITERATE_Actions Execution halted, action L"EPUpdateInstallAction" returned 1627 err:msi:custom_get_thread_return Invalid Return Code 3 Affects Winetricks in multiple verbs. Run: 1. winetricks dotnet20 2. Install. -- 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 19624] New: winspool.drv needs to properly handle local printer server config data queries (XPSEPSC update/installer)
by wine-bugs＠winehq.org 08 Jan '21

08 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=19624 Summary: winspool.drv needs to properly handle local printer server config data queries (XPSEPSC update/installer) Product: Wine Version: 1.1.27 Platform: PC URL: http://go.microsoft.com/fwlink/?LinkId=96332 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: spooler AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, that component is a needed prerequisite for .NET 3.0 Framework SP1, 3.5, 3.5 SP1 Fortunately can be reproduced without all the .NET installer mess: clean WINEPREFIX, run the installer from link. Local printer server has no name associated with it (NULL), leading to later problem when querying for registry data. --- snip --- 0032:Call KERNEL32.CreateProcessA(00000000,0015a5e8 "C:\\windows\\system32\\spool\\prtprocs\\w32x86\\printfilterpipelinesvc.exe /RegServer C:\\3b6becc6d220eb7bdd60153c\\update\\",00000000,00000000,00000000,00000000,00000000,00000000,0033ba98,0033badc) ... 003b:Call winspool.drv.OpenPrinterW(00000000,0033f8a0,00000000) ret=0102ed15 003b:trace:winspool:OpenPrinterW ((null), 0x33f8a0, (nil)) ... 003b:trace:winspool:OpenPrinterW returning 1 with 0 and 0x1 003b:Ret winspool.drv.OpenPrinterW() retval=00000001 ret=0102ed15 003b:Call winspool.drv.GetPrinterDataW(00000001,01004ad8 L"DefaultSpoolDirectory",00000000,00000000,00000000,0033f8a8) ret=0102ed82 003b:trace:winspool:GetPrinterDataExW (0x1, L"PrinterDriverData", L"DefaultSpoolDirectory" (nil), (nil), 00000000, 0x33f8a8) 003b:Ret winspool.drv.GetPrinterDataW() retval=00000006 ret=0102ed82 ... 003b:Call KERNEL32.GetLastError() ret=01021138 003b:Ret KERNEL32.GetLastError() retval=00000000 ret=01021138 ... 003b:Call KERNEL32.MultiByteToWideChar(00000000,00000008,0033f718 "Unexpected return value.",00000100,0033f518,00000100) ret=0105ec7c 003b:Ret KERNEL32.MultiByteToWideChar() retval=00000100 ret=0105ec7c ... 003b:Call KERNEL32.RaiseException(e06d7363,00000001,00000003,0033f810) ret=0101e688 003b:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b84303a ip=7b84303a tid=003b 003b:trace:seh:raise_exception info[0]=19930520 003b:trace:seh:raise_exception info[1]=0033f83c 003b:trace:seh:raise_exception info[2]=01086754 003b:trace:seh:raise_exception eax=7b82cb69 ebx=7b8d091c ecx=00000000 edx=0033f7fc esi=0033f7fc edi=0033f770 003b:trace:seh:raise_exception ebp=0033f758 esp=0033f6f4 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000246 ... 003b:Call KERNEL32.OutputDebugStringA(01002aec "Invalid parameter passed to C runtime function.\n") ret=01022579 003b:Ret KERNEL32.OutputDebugStringA() retval=ffffffff ret=01022579 --- 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 14

[Bug 16227] New: Tooltips on mouse hover in EMS SQL Manager block the mouse click
by wine-bugs＠winehq.org 05 Jan '21

05 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=16227 Summary: Tooltips on mouse hover in EMS SQL Manager block the mouse click Product: Wine Version: 1.1.9 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P1 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: ksfreitas(a)gmail.com Created an attachment (id=17473) --> (http://bugs.winehq.org/attachment.cgi?id=17473) Screenshot of a tooltip bloocking the mouse click In EMS SQL Manager (Free and Full), the tooltips block the mouse click, having to resize to see all item without tooltip for click. The link for freeware software download: http://www.sqlmanager.net/en/products/postgresql/manager/download -- 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 13

[Bug 27502] New: app freezes when WM_KILLFOCUS creates modal dialog
by wine-bugs＠winehq.org 03 Jan '21

03 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=27502 Summary: app freezes when WM_KILLFOCUS creates modal dialog Product: Wine Version: unspecified Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: efrias(a)syncad.com Created an attachment (id=35159) --> (http://bugs.winehq.org/attachment.cgi?id=35159) simple example which produces the error When a program brings up a modal dialog box in response to a WM_KILLFOCUS message, the program will freeze. I've attached a simple test case, all boilerplate except for: case WM_KILLFOCUS: MessageBox(hWnd, _T("Killing Focus"), _T("Note"), MB_OK); in the main event loop. If you run the program and then give focus to another application, the messagebox will pop up and then the program will become unresponsive. What is happening is: - x11drv gets a FocusOut event and calls the event handler, which ends up SendMessage-ing a WM_KILLFOCUS to the program. - The programs's code creates a modal dialog like the MessageBox above, and enters the dialog's event loop, which winds up calling GetMessage which calls MsgWaitForMultipleObjectsEx to get more X11 events. - X11DRV_MsgWaitForMultipleObjectsEx executes this: if (data->current_event) mask = 0; /* don't process nested events */ where data->current_event is true since we're still handling the FocusOut event. Since we're not processing nested events, we'll never be able to process the usual events like keys or mouse events which could exit this nested event loop. This type of error occurs in a few places in our application, where a WM_KILLFOCUS message to an edit box triggers some input validation and displays an error on failure. This works correctly in the normal case, where the user tabs out or clicks on another control in the dialog box containing the edit control -- since everything stays in the same top-level window, there is no FocusOut event from X11 and the WM_KILLFOCUS is generated internally by wine in response to, say, a KeyEvent. I think these key or mouse events are just posted to the windows message queue, and the X11 event handler has already exited by the time the application gets around to processing the ensuing WM_KILLFOCUS. But in the case where focus is lost by clicking outside the dialog containing the edit control, the WM_KILLFOCUS is generated by the FocusOut handler which is still executing, and we lock up. I suspect this is related to bug 11595 "Notepad++ freezes if native application changes a file it has open (dogfood)". My guess is in that case, a FocusIn event triggers something like a WM_ACTIVATE, in which notepad++ notices a file is changed and displays a messagebox asking if you want to reload. Since wine is still processing the FocusIn event, the modal message loop's call to MsgWaitForMultipleObjectsEx will never process any useful events because it's a nested event. Our application's built-in text editor has this same problem. I don't understand the event handling code well enough to propose a solution. As a test, I allowed nested event processing and it solved the problem without introducing any obvious errors, but I'm sure that check was in there for a reason. It's probably better to keep the application code from being executed from inside the event handler, if that's possible. Note: this bug was also posted as a message to wine-devel here: http://www.winehq.org/pipermail/wine-devel/2011-June/090652.html -- 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 14

[Bug 32058] New: Guild Wars 2 launcher freezes/hangs (unable to launch game)
by wine-bugs＠winehq.org 03 Jan '21

03 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=32058 Bug #: 32058 Summary: Guild Wars 2 launcher freezes/hangs (unable to launch game) Product: Wine Version: 1.5.15 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: x.egam.wodahs.x(a)gmail.com CC: julliard(a)winehq.org Classification: Unclassified Once I updated wine to version 1.5.15, the Guild Wars 2 launcher can no longer launch the game because it just freezes/hangs. This was not an issue in 1.5.14, and in order to run the game for now I'm using wine 1.5.14 compiled from source. In wine 1.5.14, the launcher is black (can't see UI at all, but it's still functional) unless using the -dx9single flag. Using -dx9single, the background is black instead of transparent but the UI inside is properly rendered. This information is important because, before submitting this bug report, I performed two separate git bisects between 1.5.14 and 1.5.15: one without any command-line parameters, and one using -dx9single. Technical details follow: ======================================================================= 1) git bisect for running the game without any parameters: In the last good commit (8dcbeff760115834656f3f1fc85922e3a9af14d0), the launcher is still black but it still works. You cannot see the UI but by blindly logging in, the game does launch. In the first bad commit (f12c1c6630f0bf842dde9af10da4ab188ff16e94), the behavior is different from the wine 1.5.15 release and the other commits tested: here, instead of locking up, the window just disappears. It's still there, but I guess it's fully transparent. Because this leaves us even more "blind", I considered this "bad" in the git bisect, yielding the following result: --- f12c1c6630f0bf842dde9af10da4ab188ff16e94 is the first bad commit commit f12c1c6630f0bf842dde9af10da4ab188ff16e94 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Wed Sep 26 13:12:17 2012 +0200 winex11: Switch to an ARGB visual for layered windows with per-pixel alpha. :040000 040000 e9933c28f3e50c52d2cee37a43b06a2f5cb5a497 3870099a31a68a69cd7c022857794700c2343aa9 M dlls --- If, however, we consider f12c1c6630f0bf842dde9af10da4ab188ff16e94 "good" in the git bisect, we get: --- d8247efd5ecb8c4604624eb2bbf47e194ce59e7e is the first bad commit commit d8247efd5ecb8c4604624eb2bbf47e194ce59e7e Author: Alexandre Julliard <julliard(a)winehq.org> Date: Thu Sep 27 20:47:08 2012 +0200 winex11: Take the alpha channel into account to compute the region of layered windows. :040000 040000 3870099a31a68a69cd7c022857794700c2343aa9 d9ec62b63405f910db90b095145a7910cc124eef M dlls --- In this case, the launcher does indeed lock up in the first bad commit (d8247efd5ecb8c4604624eb2bbf47e194ce59e7e). 2) git bisect for running the game using -dx9single: Using the -dx9single flag, we seem to be able to get to a later commit before it stops working (but does not work in the 1.5.15 release). In the last good commit (dbff4f422c943a837f0098e921f831eb4a94ac11), everything seems to be fine (when using the -dx9single flag) and even the transparency seems to be working. However, in the first bad commit (6f3b097a203d9ca248732cb45eed462599ca3af1), things start to lock up. This yields the following git bisect result: --- 6f3b097a203d9ca248732cb45eed462599ca3af1 is the first bad commit commit 6f3b097a203d9ca248732cb45eed462599ca3af1 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Wed Oct 3 00:09:01 2012 +0200 winex11: Fix a typo in the surface region computation with an alpha channel. :040000 040000 fa11ac3c80763b81911ba999d8302029d2c6d147 566c9c06b11f8785c870a1e09ec53d42e13d1524 M dlls --- -- 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 19

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs September 2014