https://bugs.winehq.org/show_bug.cgi?id=44920
Bug ID: 44920
Summary: Starcraft II Arcade Crash during load
Product: Wine
Version: 3.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: antonio.e.russo(a)gmail.com
Distribution: ---
Created attachment 61011
--> https://bugs.winehq.org/attachment.cgi?id=61011
WINEDEBUG=warn+all log of crash (gzipped)
Starcraft II is a moving target. After the most recent patch, I was unable to
use wine-staging 2.21, which had been working excellently for me. Wine 3.5 has
trouble: loading the "Hero Attack 3X" (popular) arcade game, the game crashes.
I've attached a "WINEDEBUG=warn+all" log, and can help debug.
I checked "use 32-bit version", and I am using a clean prefix.
--
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.
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.
https://bugs.winehq.org/show_bug.cgi?id=56486
Bug ID: 56486
Summary: Battle.net App Crash Cycle on Startup
Product: Wine
Version: 9.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: wschmrdr(a)gmail.com
Distribution: ---
Created attachment 76256
--> https://bugs.winehq.org/attachment.cgi?id=76256
Backtrace from the Program Error
Starting up Battle.net App. Login screen shows with a loading circle as if it's
trying to use a saved password to login. I receive a notice that there's an
error and Battle.net has to shut down. I close it, and the error shows up
again. This continues in a cycle until I use "wineserver -k" to exit. The
backtrace saved from this has been attached. I am able to use the Settings
button on the login screen for the Battle.net app, as well as typing in a
username/password, but I cannot go any farther than that because there is no
submit button and it doesn't seem to want to load.
Be aware that I had previously been loading Starcraft II directly using the
SC2Switcher.exe executable, but because a new version needs to be downloaded,
I'm needing to get into the Battle.net app. Not sure if not using the app is a
side effect. For the heck of it, I tried running the setup to update
Battle.net, and the same thing occurred.
--
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.
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.
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.
https://bugs.winehq.org/show_bug.cgi?id=40574
Bug ID: 40574
Summary: bbtalk.exe wont start
Product: Wine
Version: 1.9.9
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: eore26(a)gmail.com
Distribution: ---
Created attachment 54413
--> https://bugs.winehq.org/attachment.cgi?id=54413
Program error detail
Unhandled Exception
--
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.
https://bugs.winehq.org/show_bug.cgi?id=43985
Bug ID: 43985
Summary: I could not run my game 梦幻西游
Product: Packaging
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: yizhongwang(a)yahoo.com
CC: michael(a)fds-team.de, sebastian(a)fds-team.de
Distribution: ---
I could not run my game
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54979
Bug ID: 54979
Summary: Futexes which protect memory allocation congest,
causing 100x performance degradation
Product: Wine
Version: 8.0.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: nagle(a)animats.com
Distribution: ---
Created attachment 74518
--> https://bugs.winehq.org/attachment.cgi?id=74518
Debugger output with multiple threads stuck in spinlocks.
SUMMARY
Under the wrong circumstances, a program doing many memory allocations from
multiple threads can
experience more than 100x performance degradation.
I'm seeing this in my own Rust program, which has 16 sometimes-compute-bound
threads on a 12 CPU machine. This works fine on Microsoft Windows and when
compiled for Linux. Under Wine, it can be over 100x slower.
Multiple threads are banging on a spinlock at
_InterlockedCompareExchange
[Z:\usr\src\packages\BUILD\include\winnt.h:6630] in ntdll
spin_lock
[Z:\usr\src\packages\BUILD\dlls\ntdll\sync.c:937] in ntdll
This is the spin lock around the queue for pausing threads.
DISCUSSION
This looks like futex congestion. That's a known kind of problem, but doesn't
seem to have
been seen in Wine before. It may be that some programs just run really slow
under Wine,
and nobody knows why.
The code in NTDLL is clearly intended to handle the fast case without doing an
OS-level lock. Under light load, that's O(1). But under heavy load, with
multiple threads pounding on spinlocks, each spinlock waits longer, and there
are multiple threads, so it becomes O(N^2). Which means huge slowdowns.
See discussion at https://forum.winehq.org/viewtopic.php?t=37688 which has
snippets of the code that's causing the problem. I can copy all that info over
here if necessary. Let me know.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=55981
Bug ID: 55981
Summary: Dragon Age Origins: Runs slowly when using the
experimental wow64 mode
Product: Wine
Version: 8.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: berillions(a)gmail.com
Distribution: ---
Created attachment 75572
--> https://bugs.winehq.org/attachment.cgi?id=75572
Dragon Age : Origins main menu with new wow64 + OpenGL renderer
Dragon Age : Origins works with the new wow64 experimental mode but it's very
slowly and unplayable. This bug affect "Beyond Good & Evil" too.
Use DXVK fix this issue so something wrong with new wow64 + opengl renderer ?
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54455
Bug ID: 54455
Summary: CodeMeterRuntime: Install fails with
'00c4:err:service:process_send_command service
protocol error - failed to write pipe!'
Product: Wine
Version: 8.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: irmin.okic(a)gmail.com
Distribution: ---
Created attachment 74012
--> https://bugs.winehq.org/attachment.cgi?id=74012
Terminal output of the installer.
Steps to reproduce:
* Install dotnet48 into the prefix with winetricks.
* Download CodeMeterRuntime 64bit 7.60 (but earlier versions had the same
error) for Windows from:
https://www.wibu.com/us/support/user/downloads-user-software.html
* Execute the installer.
* To reduce complexity in the installer on the Custom Setup step select "don't
install" for all components except "CodeMeter Runtime Kit". I.e. "don't
install" for Network Server, WibuShellExtension, User Help, Automatic server
search, Remote access to WebAdmin.
* Finish the installation. The installer will state that it ended prematurely.
The relevant errors are probably:
00c4:err:service:process_send_command service protocol error - failed to write
pipe!
016c:err:msi:ITERATE_StartService failed to start service L"CmWebAdmin.exe"
(1053)
016c:err:msi:execute_script Execution of script 0 halted; action
L"StartServices" returned 1627
016c:err:msi:ITERATE_Actions Execution halted, action L"InstallExecute"
returned 1627
In Wine 7 I ignored the installer error with the following arguments to the
installer:
/ComponentArgs "*":"/qn ADDLOCAL=Complete,DotNET_Modules,AutomaticServerSearch
REMOVE=WibuShellExtension,EnableNetworkServer,AccessToWebAdmin /l*v
C:\users\z0rb\Temp\keyinst.log /norestart DISABLEROLLBACK=1 PROP_CMCC=\"none\""
The important argument was DISABLEROLLBACK=1. This meant that I can keep the
install even with the failure. Then run CodeMeterCC.exe which started the
CodeMeter windows service. With that service I could use further software that
uses CodeMeter as their licensing service. In wine 8 even that service
(together with CmWebAdmin.exe) started having the "failed to write pipe
error!". I am out of workarounds at the moment and asking here for help. If you
can instruct me with further debug flags and similar to narrow down the error I
am ready to put in the work.
--
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.