[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)
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@winehq.org Reporter: focht@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
https://bugs.winehq.org/show_bug.cgi?id=46568
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
https://bugs.winehq.org/show_bug.cgi?id=46568
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch CC| |xerox.xerox2000x@gmail.com
--- Comment #1 from Louis Lenders xerox.xerox2000x@gmail.com --- Hi,
I AFAICT patches from Derek which are still pending on the list seem to help here:
https://www.winehq.org/pipermail/wine-devel/2019-October/151857.html https://www.winehq.org/pipermail/wine-devel/2019-October/151859.html
I applied both patches, did a winetricks msxml3 msxml6 and that did get Altium Designer a tiny bit further (to run into a next crash)
For now AFAICT it looks like patches seem to help so I add keyword patch for now
https://bugs.winehq.org/show_bug.cgi?id=46568
winetaste@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetaste@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=46568
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #2 from Paul Gofman gofmanp@gmail.com --- Created attachment 65805 --> https://bugs.winehq.org/attachment.cgi?id=65805 patch
Does this patch fix the issue as well?
https://bugs.winehq.org/show_bug.cgi?id=46568
--- Comment #3 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Paul Gofman from comment #2)
Created attachment 65805 [details] patch
Does this patch fix the issue as well?
Yes it does!
Symptoms without the patch (after winetricks msxml6):
wine X2.EXE
003d:err:ole:COMPOBJ_DllList_Add couldn't load in-process dll L"C:\windows\system32\msxml6.dll" 003d:err:ole:create_server class {88d96a05-f192-11d4-a65f-0040963251e5} not registered 003d:err:ole:CoGetClassObject no class object {88d96a05-f192-11d4-a65f-0040963251e5} could be created for context 0x5 003d:fixme:msxml:domdoc_setProperty Ignoring property L"ProhibitDTD", value 0x52ea88 {VT_BOOL: 0} wine: Unhandled page fault on read access to 0000000000000000 at address 0000001400053E4C (thread 003d), starting debugger... 0048:fixme:dbghelp:elf_search_auxv can't find symbol in module ( loads of these errors)
With the patch it gets to the loginscreen (after disabling Altium`s own IntegratedLibrary.dll needed because of missing msado15, see bug 46107 for other workaround)
Nice job Paul, is this now a duplicate or should it be linked to the AION-bug?
https://bugs.winehq.org/show_bug.cgi?id=46568
--- Comment #4 from Paul Gofman gofmanp@gmail.com --- (In reply to Louis Lenders from comment #3)
(In reply to Paul Gofman from comment #2)
is this now a duplicate or should it be linked to the AION-bug?
This does not look a duplicate to me, though solution I want to test is supposed to help both (and that's how this version of msxml and probably Mortal Kombat 11 succeed on Windows 8+). Here the program relies on pre-Win8 16TB user space address limit, which was lifted in Win8. AION is not fine with 8TB address range, it wants the addresses in 16GB range in my observations. All of that succeed on Windows (most of the time) because Windows allocates virtual memory bottom up (unless top down is explicitly requested for virtual allocation). That is, it will not give an application high memory pointers if the lower memory addresses are available. My patch makes Wine allocations behave in a similar way.
https://bugs.winehq.org/show_bug.cgi?id=46568
--- Comment #5 from Paul Gofman gofmanp@gmail.com --- Also, the patches attached here in comment #1 (in the form they are given, maybe there are updated versions somewhere) have the problem that Wine tends to eat tenths TBs of virtual address space with them. This happens due to the following scenario in dlls/ntdll/virtual.c:map_view():
wine_anon_mmap(NULL, ...) tend to return high memory addresses under Linux (it is coming from native mmap()). map_view() is not happy with address above user space limit (which was reduced by the patch). It adds the received mapping to a reserved area instead of unmapping it (otherwise it would get the same address again and it would result in infinite loop). So it keeps reserving virtual address space until the addresses between the (reduced) user space limit and native host user space limit is mostly filled.
I suppose fixing that is no easier than to do what my patch is trying to do, it should probably reduce to something similar.
https://bugs.winehq.org/show_bug.cgi?id=46568
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/ntdll-ForceBotto | |mUpAlloc
https://bugs.winehq.org/show_bug.cgi?id=46568
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=49931
https://bugs.winehq.org/show_bug.cgi?id=46568
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|https://download.microsoft. |https://web.archive.org/web |com/download/2/e/0/2e01308a |/20060628215935/http://down |-e17f-4bf9-bf48-161356cf9c8 |load.microsoft.com/download |1/msxml6_x64.msi |/2/e/0/2e01308a-e17f-4bf9-b | |f48-161356cf9c81/msxml6_x64 | |.msi
https://bugs.winehq.org/show_bug.cgi?id=46568
jswinebz@kanargh.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jswinebz@kanargh.org.uk
--- Comment #6 from jswinebz@kanargh.org.uk --- I note from https://github.com/wine-staging/wine-staging/commits/master/patches/ntdll-Fo... that this patchset appears to oscillate between broken and fixed fairly frequently.
As Fedora takes snapshots of wine-staging every so often, it's a bit pot luck whether their build catches it at a good time or not. I upgraded to F39 yesterday and got unlucky: their current wine-8.19-1.fc39 built 2023-10-30 has the patch disabled so I see crashes. I note that the current git state (as of two days ago) is fixed again.
But after 4 years shouldn't this be a bit more stable? Like, no longer part of the staging patchset?
https://bugs.winehq.org/show_bug.cgi?id=46568
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jkfloris@dds.nl
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- *** Bug 55783 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=46568
--- Comment #8 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 77585 --> https://bugs.winehq.org/attachment.cgi?id=77585 possibel patch
Patch from bug 55783 from Fabian
Note to the Staging maintainers: the patch in the Staging field in this bugreport has been broken for quite long time....
-
wine-bugs＠winehq.org -
WineHQ Bugzilla