October 2024 - Wine-bugs - list.winehq.org

[Bug 16882] New: WMI core 1.5 installation hangs (needed for .NET 3.0 installer, WCF part), SECURITY_SERVICE_RID missing from service token group
by wine-bugs＠winehq.org 27 Nov '25

27 Nov '25

http://bugs.winehq.org/show_bug.cgi?id=16882 Summary: WMI core 1.5 installation hangs (needed for .NET 3.0 installer, WCF part), SECURITY_SERVICE_RID missing from service token group Product: Wine Version: 1.1.12 Platform: Other URL: http://www.microsoft.com/downloads/details.aspx?familyid =AFE41F46-E213-4CBF-9C5B-FBF236E0E875 OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: advapi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, after getting past bug 16879 one encounters this 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. ---- "c:\\windows\\temp\\dd_dotnetfx3error.txt": --- snip --- [01/11/09,12:50:20] Windows Communication Foundation: [2] Error: Installation failed for component Windows Communication Foundation. MSI returned error code 1603 [01/11/09,12:50:31] WapUI: [2] DepCheck indicates Windows Communication Foundation is not installed. [01/11/09,12:50:31] WapUI: [2] DepCheck indicates Microsoft .NET Framework 3.0 was not attempted to be installed. --- snip --- "c:\\windows\\temp\\dd_wcf_retMSI597F.txt": --- snip --- 1: C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe /r /x /y /v 2: 1: ERROR: Process returned non-0 value! CMDLINE: C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe /r /x /y /v 2: 1: Failed 2: --- snip --- and "c:\\windows\\temp\\dd_wcf_retCA69A1.txt": --- snip --- === Verbose logging started: 1/11/2009 12:50:17 Calling process: C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe === ServiceModelReg [12:50:18:302]: Warning: Could not detect IIS installation or IIS is disabled, skipping the Web Host Script Mappings component since it depends upon IIS to function properly. If you believe this message is an error, check your IIS installation to make sure it is installed properly. ServiceModelReg [12:50:18:329]: Information: The ServiceModelReg tool will take the following actions: Reinstalling configuration section system.serviceModel to C:\windows\Microsoft.NET\Framework\v2.0.50727\Config\machine.config. Reinstalling configuration section system.runtime.serialization to C:\windows\Microsoft.NET\Framework\v2.0.50727\Config\machine.config. Reinstalling configuration section system.serviceModel.activation to C:\windows\Microsoft.NET\Framework\v2.0.50727\Config\machine.config. Adding configuration entry for BuildProvider: System.ServiceModel.Activation.ServiceBuildProvider, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Reinstalling compilation assembly node to System.Web section group: System.Runtime.Serialization, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL Reinstalling compilation assembly node to System.Web section group: System.IdentityModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitectur... ServiceModelReg [12:50:18:358]: Uninstalling: Machine.config Section Groups and Handlers ServiceModelReg [12:50:18:366]: Warning: Configuration section system.serviceModel does not exist in C:\windows\Microsoft.NET\Framework\v2.0.50727\Config\machine.config. ServiceModelReg [12:50:18:369]: Warning: Configuration section system.runtime.serialization does not exist in C:\windows\Microsoft.NET\Framework\v2.0.50727\Config\machine.config. ServiceModelReg [12:50:18:373]: Warning: Configuration section system.serviceModel.activation does not exist in C:\windows\Microsoft.NET\Framework\v2.0.50727\Config\machine.config. ServiceModelReg [12:50:18:374]: Installing: Machine.config Section Groups and Handlers ServiceModelReg [12:50:18:893]: Uninstalling: System.Web Build Provider ServiceModelReg [12:50:19:095]: Warning: A configuration entry for BuildProvider System.ServiceModel.Activation.ServiceBuildProvider, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 does not exist. ServiceModelReg [12:50:19:096]: Installing: System.Web Build Provider ServiceModelReg [12:50:19:138]: Uninstalling: System.Web Compilation Assemblies ServiceModelReg [12:50:19:153]: Warning: All compilation assembly nodes do not exist in System.Web section group. ServiceModelReg [12:50:19:154]: Installing: System.Web Compilation Assemblies ServiceModelReg [12:50:19:246]: Uninstalling: HTTP Handlers ServiceModelReg [12:50:19:260]: Warning: HttpHandlers node *.svc does not exist in System.Web section group. ServiceModelReg [12:50:19:261]: Installing: HTTP Handlers ServiceModelReg [12:50:19:322]: Uninstalling: HTTP Modules ServiceModelReg [12:50:19:333]: Warning: HttpModules node ServiceModel does not exist in System.Web section group. ServiceModelReg [12:50:19:334]: Installing: HTTP Modules ServiceModelReg [12:50:19:365]: Repairing: WMI Classes ServiceModelReg [12:50:19:396]: Warning: Failure executing "C:\windows\system32\wbem\mofcomp.exe" with parameters ""C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof"": System.IO.FileNotFoundException: Could not load file or assembly 'C:\windows\system32\wbem\mofcomp.exe' or one of its dependencies. Exception from HRESULT: 0x80070002 File name: 'C:\windows\system32\wbem\mofcomp.exe' at System.ServiceModel.Install.InstallHelper.ExecuteWaitHelper(String program, String parameters) at System.ServiceModel.Install.InstallHelper.ExecuteWait(String program, String parameters, Int32[] allowedExitCodes) at System.ServiceModel.Install.WmiInstallComponent.OnInstall(OutputLevel outputLevel) ServiceModelReg [12:50:19:516]: System.InvalidCastException: Retrieving the COM class factory for component with CLSID {4590F811-1D3A-11D0-891F-00AA004B2E24} failed due to the following error: 80004002. at System.Management.ManagementScope.InitializeGuts(Object o) at System.Management.ManagementScope.Initialize() at System.Management.ManagementScope.Connect() at System.ServiceModel.Install.WmiInstallComponent.get_IsInstalled() at System.ServiceModel.Install.WmiInstallComponent.ApplyNamespaceDacl(OutputLevel outputLevel) at System.ServiceModel.Install.WmiInstallComponent.OnInstall(OutputLevel outputLevel) at System.ServiceModel.Install.WmiInstallComponent.Reinstall(OutputLevel outputLevel) at Microsoft.Tools.ServiceModel.ServiceModelReg.PerformAction(ActionItem actionItem, Nullable`1 confirmUninstall) at Microsoft.Tools.ServiceModel.ServiceModelReg.Run(String[] args) at Microsoft.Tools.ServiceModel.ServiceModelReg.TryRun(String[] args) === Verbose logging stopped: 1/11/2009 12:50:19 === --- snip --- Oh joy ... WMI. Providing fake mofcomp.exe (returning success) is not enough, WCF installer will try *use* WMI hence there needs to be some working infrastructure: --- snip --- ServiceModelReg [19:37:29:832]: Starting tool 'C:\windows\system32\wbem\mofcomp.exe' with parameters '"C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof"'. ServiceModelReg [19:37:29:895]: ServiceModelReg [19:37:29:896]: ServiceModelReg [19:37:29:897]: Tool 'C:\windows\system32\wbem\mofcomp.exe' with parameters '"C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof"' exited with code '0'. ServiceModelReg [19:37:29:955]: System.InvalidCastException: Retrieving the COM class factory for component with CLSID {4590F811-1D3A-11D0-891F-00AA004B2E24} failed due to the following error: 80004002. at System.Management.ManagementScope.InitializeGuts(Object o) at System.Management.ManagementScope.Initialize() at System.Management.ManagementScope.Connect() at System.ServiceModel.Install.WmiInstallComponent.get_IsInstalled() at System.ServiceModel.Install.WmiInstallComponent.ApplyNamespaceDacl(OutputLevel outputLevel) at System.ServiceModel.Install.WmiInstallComponent.OnInstall(OutputLevel outputLevel) at System.ServiceModel.Install.WmiInstallComponent.Reinstall(OutputLevel outputLevel) at Microsoft.Tools.ServiceModel.ServiceModelReg.PerformAction(ActionItem actionItem, Nullable`1 confirmUninstall) at Microsoft.Tools.ServiceModel.ServiceModelReg.Run(String[] args) at Microsoft.Tools.ServiceModel.ServiceModelReg.TryRun(String[] args) === Verbose logging stopped: 1/8/2009 19:37:29 === --- snip --- This is a big blocker and getting WMI to work with Wine is imperative for .NET 3.0 and higher. Of course this also useful for older .NET Frameworks Roll-back, prepare clean WINEPREFIX again;-) We need to install native WMI core 1.5 from: http://www.microsoft.com/downloads/details.aspx?familyid=AFE41F46-E213-4CBF… Download wmicore http://download.microsoft.com/download/platformsdk/wmicore/1.5/W9XNT4/EN-US… (sha1sum: f7a36668eb6c82a28393637ffdf0ec6e8adfa6a1) Make sure you set winver to NT 4.0 (don't forget to reset to default) and execute the installer (I already have my own winetricks step for this): --- snip --- wine wmicore.exe --- snip --- The installer will then hang at some point "Configuring repository". With winedbg one can see following processes: --- snip --- Wine-dbg>info process pid threads parent executable (all id:s are in hex) 0000000c 5 0000000a 'services.exe' 0000000f 1 0000000a 'explorer.exe' 0000001b 4 0000000c 'winedevice.exe' 00000025 1 00000000 'wmicore.exe' 00000027 2 00000025 'GLBbab.tmp' 00000022 4 0000000c 'WinMgmt.exe' --- snip --- The problem is "WinMgmt.exe" which ought to be a service but due to Wine insufficiency the service thinks it's a normal process not showing usual service process behaviour as registering control handler and the like. If you do 'wineserver -k' and try to start anything with Wine nothing will happen until wineboot times out... As quickfix, start regedit (wait until wineboot timeout) and set service start type key for "WinMgmt" to manual start, e.g. "2" -> "3". Also a kernel driver (service) that is installed with WMI "smbios" fails to load but this currently harmless. If we look now in "c:\\windows\\system32\\WBEM" we see the whole stuff installed. The logs in "logs" subdirs are not revealing much so we have to increase the log level: --- snip --- [HKEY_LOCAL_MACHINE\Software\Microsoft\WBEM\CIMOM] "Logging"="1" "Logging Directory"="C:\\windows\\system32\\WBEM\\Logs" --- snip --- LogLevel is 0 to turn off logging, a 1 to turn on logging, and a 2 for verbose logging. After that, we manually try to start the service: --- snip --- $ wine net start winmgmt err:winedevice:ServiceMain driver L"smbios" failed to load The Windows Management Instrumentation service is starting. fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),2,2,(nil),32,(nil)) - stub! fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),1,3,(nil),0,(nil)) - stub! fixme:advapi:RegisterEventSourceW (L"",L"WinMgmt"): stub wine: Call from 0x7b844f54 to unimplemented function ole32.dll.CoSwitchCallContext, aborting err:rpc:I_RpcReceive we got fault packet with status 0x80000100 fixme:ole:CoCreateInstance no instance created for interface {00000000-0000-0000-c000-000000000046} of class {8bc3f05e-d86b-11d0-a075-00c04fb68820}, hres is 0xc0000005 --- snip --- This is bug 7187 After fixing this problem, we repeat the whole stuff again to get this in logs: --- snip --- (Sun Jan 11 13:41:41 2009) : Starting WinMgmt, ProcID = 26, CmdLine = , User = focht(Sun Jan 11 13:41:41 2009) : WinMgmt bIsService = 0, return code from function determining if service = 0(Sun Jan 11 13:41:41 2009) : WinMgmt gbRunAsApp = 1(Sun Jan 11 13:41:41 2009) : Starting Initialize, ID = 26(Sun Jan 11 13:41:41 2009) : Registered class factory with flags: 0x15 (Sun Jan 11 13:41:41 2009) : RegOpenKey returned 0x2 while trying to open the transports node. Using default transports!(Sun Jan 11 13:41:41 2009) : Initialize complete(Sun Jan 11 13:41:41 2009) : WindowProc got hWnd=20026, message=24, wParam=0, lParam=33f814(Sun Jan 11 13:41:41 2009) : WindowProc got hWnd=20026, message=81, wParam=0, lParam=33fce8(Sun Jan 11 13:41:41 2009) : WindowProc got hWnd=20026, message=83, wParam=0, lParam=33f974(Sun Jan 11 13:41:41 2009) : WindowProc got hWnd=20026, message=1, wParam=0, lParam=33fce8(Sun Jan 11 13:41:41 2009) : Inside the waiting function --- snip --- "WinMgmt bIsService = 0" is the culprit. The process retrieves token information and checks if process token groups contain "SECURITY_INTERACTIVE_RID" (-> normal process) or "SECURITY_SERVICE_RID" (service process). I think it's actually services.exe that adds the SECURITY_SERVICE_RID sid to the newly created service process (token groups). This requires some infrastructure, including wineserver. I already quick-hacked a path to verify this and it works as expected, letting the service successfully start ;-) 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 24

[Bug 24963] New: Okad2: Unhandled page fault at address 0x00007f8a during startup
by wine-bugs＠winehq.org 26 Nov '25

26 Nov '25

http://bugs.winehq.org/show_bug.cgi?id=24963 Summary: Okad2: Unhandled page fault at address 0x00007f8a during startup Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: pandolfo(a)gis.net Created an attachment (id=31617) --> (http://bugs.winehq.org/attachment.cgi?id=31617) a description of the page fault plus an annotated backtrace During program startup, Okad2-xx-pd (xx = version) generates an unhandled page fault when loading an icon. The page fault is caused by CreateFileW as it processes the name of the file from the parameter list. The name pointer is 0x00007f8a, which is an address in an unmapped page. This value is also an index into Windows resources, selecting the hourglass icon. What has happened is that the application was attempting to load the hourglass icon and passed in BOTH the Windows resource index and a flag indicating LOADFROMFILE. Wine attempted to load-from-file and looked for the file name through the "name" parameter (0x00007f8a) generating the page fault. Native Windows appears to give the value of the "name" pointer precedence and determines that the "name" parameter is actually a resource number; hence it does not page fault and runs Okad2 normally. Wine *DOES* check the "name" parameter to see if it is a resource index, but several subroutine calls later it forgets this fact and branches based on the LOADFROMFILE bit. The backtrace has been annotated to provide both a description and source lines involved in the decision. This behavior was found in the latest version of Wine for Debian (.1.42) and in a MacOS X version. -- 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 17

[Bug 51537] New: Mouse does not work in civilization VI
by WineHQ Bugzilla 25 Nov '25

25 Nov '25

https://bugs.winehq.org/show_bug.cgi?id=51537 Bug ID: 51537 Summary: Mouse does not work in civilization VI Product: Wine Version: 6.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: voker57(a)gmail.com Distribution: --- Created attachment 70376 --> https://bugs.winehq.org/attachment.cgi?id=70376 complete log Mouse does not work in Sid Meier's Civilization VI, menu loads but it is not possible to do anything further. This comment https://bugs.winehq.org/show_bug.cgi?id=49315#c9 suggests a cause of this bug. -- 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 11

[Bug 54352] New: Performance tanks when looking at occluded part of the level
by WineHQ Bugzilla 25 Nov '25

25 Nov '25

https://bugs.winehq.org/show_bug.cgi?id=54352 Bug ID: 54352 Summary: Performance tanks when looking at occluded part of the level Product: Wine Version: 8.0-rc4 Hardware: x86-64 OS: Windows Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: mirh(a)protonmail.ch https://github.com/doitsujin/dxvk/issues/1845 This is basically the equivalent of the missed optimization I had already reported to dxvk (except wined3d had like half the framerate to begin with). With the native nvidia d3d9 driver, you barely can spot a difference in the Mass Effect comm room between looking at the emptiest wall in human history, or the closed door behind that gives access to the rest of the ship. With wined3d, I go from like 220fps to ~70. Btw there's an apitrace in the thread above, if it can help. -- 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 56470] New: Wined3d has windows always sitting in background
by WineHQ Bugzilla 25 Nov '25

25 Nov '25

https://bugs.winehq.org/show_bug.cgi?id=56470 Bug ID: 56470 Summary: Wined3d has windows always sitting in background Product: Wine Version: 9.5 Hardware: x86-64 OS: Windows Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: mirh(a)protonmail.ch So.. as I always do every few month, I try to see if wined3d finally holds a candle for helping with games in Windows. This time I was surprised by a constant 30FPS lock, despite the fact both my game of choice settings and the external tools profiles for its executable didn't have one (indeed if I removed wine's dlls, native d3d9 could easily get almost 10 times as much framerate) Long story short, after some time banging my head I figured this was happening because "Background Application Max Frame Rate" was enabled in the nvidia control panel. Problem being of course that a foreground fullscreen window definitively isn't supposed to be affected by that. This does not happen with normal opengl games (even after I renamed their exe, just to be extra safe about whitelisting and whatnot) so it seems something on your side of things. -- 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 4

[Bug 44021] New: LiveMaker engine fails to find font despite overrides set up
by wine-bugs＠winehq.org 25 Nov '25

25 Nov '25

https://bugs.winehq.org/show_bug.cgi?id=44021 Bug ID: 44021 Summary: LiveMaker engine fails to find font despite overrides set up Product: Wine Version: 2.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: galtgendo(a)o2.pl Distribution: --- Going by https://github.com/xupefei/Locale-Emulator/issues/80, doesn't access the font in question (MS Gothic) directly, yet despite its overrides being set up correctly (HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes: both English and Japanese names), the engine crashes unless that font is actually present in drive_c/windows/Fonts. It might be that this can't be done as font matching/replacing takes place at much later stage, yet would be nice if someone could verify one way or the other. Perhaps those names should simply hardcoded to be returned in Japanese locale, regardless of the fonts being actually present ? Cause before Windows 10 (which has a different Japanese font), they couldn't not be there after a proper Japanese Windows install. -- 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 2

[Bug 53819] New: some versions of Unity engine need GetWindowTheme implemented to properly display crash dialog
by WineHQ Bugzilla 25 Nov '25

25 Nov '25

https://bugs.winehq.org/show_bug.cgi?id=53819 Bug ID: 53819 Summary: some versions of Unity engine need GetWindowTheme implemented to properly display crash dialog Product: Wine Version: 7.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: uxtheme Assignee: wine-bugs(a)winehq.org Reporter: galtgendo(a)o2.pl Distribution: --- So, I've stumbled upon a Unity engine game that crashes every now and then due to what seems to be virtual mapping space exhaustion. Not sure about the crash itself - it's more likely to be graphics related that winegstreamer, but that's just a guess. Anyway, once the crash happens, console is flooded by: 03b0:err:module:DelayLoadFailureHook failed to delay load uxtheme.dll.GetWindowTheme wine: Call from 7B0123C6 to unimplemented function uxtheme.dll.GetWindowTheme, aborting 03b0:err:seh:KiUserCallbackDispatcher ignoring exception and the Unity crash dialog doesn't display properly. -- 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 4

[Bug 56447] New: PlayOnline Viewer: The "splash screen" is blank/grey without its image.
by WineHQ Bugzilla 23 Nov '25

23 Nov '25

https://bugs.winehq.org/show_bug.cgi?id=56447 Bug ID: 56447 Summary: PlayOnline Viewer: The "splash screen" is blank/grey without its image. Product: Wine Version: 9.4 Hardware: x86-64 URL: https://web.archive.org/web/20210810150839/http://www. playonline.com/ff11eu/download/media/install_win.html OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: chiitoo(a)gentoo.org Distribution: Gentoo This is a very old one, but as far as I can tell, not reported until now (aside from some side-mentions). PlayOnline Viewer, which is used to launch Final Fantasy XI Online, has a blank/grey window for its "splash screen". It has been working in Wine Staging for some time. Not sure if related, but comparing the logging between runs, each of these show up twice with Vanilla but only once with Staging: err:d3d:wined3d_fence_wait glClientWaitSync returned 0x911b. err:d3d:wined3d_context_gl_wait_command_fence Failed to wait for command fence with id 0x1, ret 0x4. err:d3d:wined3d_fence_wait glClientWaitSync returned 0x911b. err:d3d:wined3d_context_gl_wait_command_fence Failed to wait for command fence with id 0x2, ret 0x4. -- 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 46568] New: 64-bit msxml6.dll from Microsoft Core XML Services 6.0 redist package fails to load (Wine doesn't respect 44-bit user-mode VA limitation from Windows < 8.1)
by wine-bugs＠winehq.org 22 Nov '25

22 Nov '25

https://bugs.winehq.org/show_bug.cgi?id=46568 Bug ID: 46568 Summary: 64-bit msxml6.dll from Microsoft Core XML Services 6.0 redist package fails to load (Wine doesn't respect 44-bit user-mode VA limitation from Windows < 8.1) Product: Wine Version: 4.0 Hardware: x86-64 URL: https://download.microsoft.com/download/2/e/0/2e01308a -e17f-4bf9-bf48-161356cf9c81/msxml6_x64.msi OS: Linux Status: NEW Keywords: download, win64 Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, reported by Louis in https://bugs.winehq.org/show_bug.cgi?id=46107#c2 --- quote --- I tried winetricks msxml3 and msxml6, but somehow it didn`t work out in 64-bit wineprefix; i get errors that msxml is not registered etc, Does anyone know a workaround to use native msxml on 64-bit prefix? --- quote --- Relevant part of trace log: --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Altium/AD18 $ WINEDEBUG=+seh,+relay,+loaddll,+virtual wine64 ./X2.EXE >>log.txt 2>&1 ... 002a:Call KERNEL32.LoadLibraryExW(0053f2b0 L"C:\\windows\\system32\\msxml6.dll",00000000,00000008) ret=7fbe435d7558 ... 002a:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\msxml6.dll" at 0x7ff79e00000: native 002a:Call PE DLL (proc=0x7ff79e0101c,module=0x7ff79e00000 L"msxml6.dll",reason=PROCESS_ATTACH,res=(nil)) ... 002a:Call KERNEL32.HeapCreate(00000001,00000000,00000000) ret=7ff79e18411 002a:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00110000 2000 00000004 002a:trace:virtual:map_view got mem with anon mmap 0x7fbe39819000-0x7fbe39929000 002a:trace:virtual:VIRTUAL_DumpView View: 0x7fbe39820000 - 0x7fbe3992ffff (valloc) 002a:trace:virtual:VIRTUAL_DumpView 0x7fbe39820000 - 0x7fbe3992ffff --rw- 002a:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff 0x7fbe39820000 00010000 1000 00000004 002a:trace:virtual:mprotect_exec forcing exec permission on 0x7fbe39820000-0x7fbe3982ffff 002a:trace:virtual:VIRTUAL_DumpView View: 0x7fbe39820000 - 0x7fbe3992ffff (valloc) 002a:trace:virtual:VIRTUAL_DumpView 0x7fbe39820000 - 0x7fbe3982ffff c-rw- 002a:trace:virtual:VIRTUAL_DumpView 0x7fbe39830000 - 0x7fbe3992ffff --rw- 002a:Ret KERNEL32.HeapCreate() retval=7fbe39820000 ret=7ff79e18411 ... 002a:Call ntdll.RtlAllocateHeap(7fbe39820000,00000000,00000060) ret=7ff79e03c10 002a:Ret ntdll.RtlAllocateHeap() retval=7fbe39822730 ret=7ff79e03c10 002a:Call msvcrt.memset(7fbe39822740,00000000,00000042) ret=7ff79e03a5a 002a:Ret msvcrt.memset() retval=7fbe39822740 ret=7ff79e03a5a 002a:trace:seh:NtRaiseException code=c0000005 flags=0 addr=0x7ff79e03efe ip=7ff79e03efe tid=002a 002a:trace:seh:NtRaiseException info[0]=0000000000000000 002a:trace:seh:NtRaiseException info[1]=ffffffffffffffff 002a:trace:seh:NtRaiseException rax=000000000011b2d0 rbx=6c61567274736270 rcx=0000000000000008 rdx=0000000000000000 002a:trace:seh:NtRaiseException rsi=0000000000007fbe rdi=0000000000000730 rbp=00000ff7c73044e8 rsp=000000000053ea70 002a:trace:seh:NtRaiseException r8=00007fbe39822740 r9=0000000000000000 r10=0000000000000000 r11=0000000000000000 002a:trace:seh:NtRaiseException r12=00007fbe39822740 r13=000007ff79f8dc80 r14=00007fbe436c6160 r15=000000000053f708 ... 002a:exception c0000005 in PE entry point (proc=0x7ff79e0101c,module=0x7ff79e00000,reason=PROCESS_ATTACH,res=(nil)) 002a:Ret PE DLL (proc=0x7ff79e0101c,module=0x7ff79e00000 L"msxml6.dll",reason=PROCESS_ATTACH,res=(nil)) retval=0 002a:Call PE DLL (proc=0x7ff79e0101c,module=0x7ff79e00000 L"msxml6.dll",reason=PROCESS_DETACH,res=(nil)) 002a:Ret PE DLL (proc=0x7ff79e0101c,module=0x7ff79e00000 L"msxml6.dll",reason=PROCESS_DETACH,res=(nil)) retval=1 002a:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\msxml6.dll" : native 002a:Ret KERNEL32.LoadLibraryExW() retval=00000000 ret=7fbe435d7558 002a:err:ole:COMPOBJ_DllList_Add couldn't load in-process dll L"C:\\windows\\system32\\msxml6.dll" --- snip --- It seems that certain older 64-bit components such as Microsoft XML libs make assumptions about the 64-bit user-mode virtual address space layout. This is different from the usual broken apps a la "I failed at porting my 32-bit app to 64-bit" (pointer truncation). In this case, pointers from certain allocations are broken into multiple parts and used as indices into multi-level lookup tables. Pitfall: there is a 44-bit user-mode VA limitation (8TB) for 64-bit Windows which was lifted starting with Windows 8.1+. Wine doesn't respect the 44-bit pre-Windows 8.1 virtual address space limits, allowing process heaps to be placed in 0000'7Fxx'0000'0000 range (128 TB) which causes out-of-bounds access to lookup tables when indices overflow (derived from pointer bits). The exception occurs in entry point, causing 'msxml6.dll' to be unloaded. One workaround is to move Wine's top-down allocations/heaps into 8 TB VA range (Wine preloader) and impose same user-mode address space bits limits as with all 64-bit Windows versions < 8.1 to stay "compatible". I've tested it and it works for native here. Not sure if it's worth to change though. I don't know if a separate 64-bit MSXML6 re-distributable package exists that has been fixed wrt Windows 8.1+ address space limits. MSXML6 is part of Windows OS for newer versions and automatically kept up-to-date. $ sha1sum msxml6_x64.msi 1eb84eeae7729ea5db7fe79779f4e216114261ba msxml6_x64.msi $ du -sh msxml6_x64.msi 2.6M msxml6_x64.msi $ wine --version wine-4.0-276-g84459ba94b 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 17

[Bug 15039] New: MSVC 6: Menu popdowns too narrow for arrows
by wine-bugs＠winehq.org 22 Nov '25

22 Nov '25

http://bugs.winehq.org/show_bug.cgi?id=15039 Summary: MSVC 6: Menu popdowns too narrow for arrows Product: Wine Version: 1.1.1 Platform: PC-x86-64 OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: claus.fischer(a)clausfischer.com CC: claus.fischer(a)clausfischer.com Microsoft Visual C++ 6 is working to a large extent. When opening a menu of the developer studio, the menu items with arrows (that open submenus) are not displayed correctly. The triangular arrows on the right end will stick out of the menu popdown area. I'm not sure if they just stick out to the end of the "shadow" (3d effect) around the popdown, or sometimes more. They should be fully contained in the popdown area. -- 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