https://bugs.winehq.org/show_bug.cgi?id=54235
Bug ID: 54235
Summary: Horizon Zero Dawn crashes: Illegal instruction in
64-bit code
Product: Wine
Version: 8.0-rc2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: cweiske(a)cweiske.de
Distribution: ---
Created attachment 73782
--> https://bugs.winehq.org/attachment.cgi?id=73782
Crash log for wine-8.0rc2
The game "Horizon Zero Dawn" crashes upon start with "illegal instruction in
64-bit code". It is the GOG version "HRZ-PCR 181/7517962 09:56 - Tue Jan 18
2022".
I had to install mfc410.dll before it would try to start (see bug #44856).
It was run with a fresh wineprefix, and windows version set to 10, and no other
dlls installed except mfc410.
The crash happens on both wine-7.0.1 and wine-8.0-rc2. Crash log is attached.
My system runs Ubuntu 20.04.5 with a Radeon R9 380 graphics card, using the
open source drivers.
--
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=54092
Bug ID: 54092
Summary: FreeArc fails under wine when memory limit is set too
high
Product: Wine
Version: 7.21
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Downloaded the program from
https://archive.org/details/FreeArc-0.666-win32bin-Sources
Testfile I used is the ubuntu iso:
https://releases.ubuntu.repulsive.eu/22.04.1/ubuntu-22.04.1-desktop-amd64.i…
Unpacked into a folder called "freearc"
Command used:
wine freearc/bin/Arc.exe -mx -ld2600 -sfx a test.arc *.iso
It soon fails with "ERROR: write error (disk full?) in compression algorithm
tempfile"
The same command works flawlessly under by Win7 x64 VM.
--
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=41411
Bug ID: 41411
Summary: 7za (part of 7-zip) handles some non-latin file names
incorrectly under wine
Product: Wine
Version: 1.6.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: unxed(a)mail.ru
Distribution: ---
app: http://www.7-zip.org/a/7z1603-extra.7z
sample archive to test:
http://pnboy.pinguix.com/gapan/23-10-2012-b-fasi-eaep.zip
1. list sample archive using 7za: "7za.exe l 23-10-2012-b-fasi-eaep.zip"
2. compare to it's output on windows (or with listing using "unzip -l
23-10-2012-b-fasi-eaep.zip")
you will see incorrect filename encoding in 7za's output
p7zip, 7za's native linux port, behaves correctly with this archive
--
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=42412
Bug ID: 42412
Summary: WinUAE 3.4.0: Networking over Slirp in AmigaOS 4.1
works bad.
Product: Wine
Version: 2.0
Hardware: x86
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winsock
Assignee: wine-bugs(a)winehq.org
Reporter: bobben(a)wigilius.se
When using WinUAE (both version 3.3.0 and 3.4.0) with slirp networking (only
way when running AmigaOS 4.1), network transfers gets damaged (md5 and file
size doesn't match) whether it's downloaded from internet or from local file
server.
This happens both on 32bit and 64bit Wine and WinUAE.
Changing the MTU value on the AmigaOS side doesn't help either.
I suspect this has something to do with the issue:
fixme:winsock:set_dont_fragment IP_DONTFRAGMENT for IPv4 not supported in this
platform.
The author of WinUAE also suspects this is the problem:
"IP_DONTFRAG (or IP_MTU_DISCOVER and friends) are not defined in some platform
specific file"
Currently using Wine 2.0-staging and macOS 10.11.6
--
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=50438
Bug ID: 50438
Summary: Wine 3.12 32 bit and greater cannot install dotnet
3.5, fails with "Error 25541 Failed to open XML file
C:\windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\w
eb_mediumtrust config. system error: -2147024786"
Product: Wine
Version: 3.12
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: wodencafe(a)gmail.com
Distribution: ---
Created attachment 69049
--> https://bugs.winehq.org/attachment.cgi?id=69049
Dot net 3.5 installation failure.
Cannot install dotnet 3.5 or 3.5 sp1 on wine 3.12 32 bit or greater with
winetricks, even up to the latest version of 5.x.
Works on wine 3.11 and earlier.
The error is:
"Error 25541 Failed to open XML file
C:\windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\web_mediumtrust config.
system error: -2147024786"
Previous versions of dotnet install successfully, it only begins to fail on 3.5
and 3.5 sp1.
Ubuntu 20.04.1 LTS
Screenshot attached, please try it yourself and you will see it fails.
I have tried with and without msxml3 installed, same error both times. I tried
several versions going all the way back to 3.12. From 3.11 and prior, the
installation succeeds, so this appears to be a regression.
The file referenced in the error message does not exist.
This is preventing LA Noire from starting, and most likely anything that
depends on dot net 3.5.
--
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=52334
Bug ID: 52334
Summary: Vanilla WoW 1.12.1 performance regression between 6.22
and 6.23 (still present 7.0rc4)
Product: Wine
Version: 7.0-rc4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: karabaja4(a)gmail.com
Distribution: ---
There was a regression between Wine 6.22 and 6.23 that caused a FPS performance
drop in Vanilla WoW 1.12.1 client (Nostalrius client, played on
https://darrowshire.com).
This regression is still present in 7.04c4. The FPS is almost double the value
in 6.22 compared to 6.23 or 7.0rc4.
Pure Wine installation, my OS is Arch Linux 5.10.88 with nvidia 495.46
proprietary drivers with Openbox WM.
Here are a few screenshot for comparison:
6.22:
https://avacyn.aerium.hr/stuff/wine/wine622.jpg
7.0rc4:
https://avacyn.aerium.hr/stuff/wine/wine70rc4.jpg
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.
https://bugs.winehq.org/show_bug.cgi?id=53658
Bug ID: 53658
Summary: During start of The Bat! the sound is disturbed
Product: Wine
Version: 7.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mywine(a)schiermeier-it.de
Distribution: ---
When the mail program The Bat! starts up a running vlc is disturbed and cut
into pieces. I suspect a regression so I did a regression test.
Here is the result of this test:
joerg@Archimedes ~/Projekte/wine_src/wine % git bisect bad
fcf4d07161478ec8ea0707a50af02acc7fe6df6a is the first bad commit
commit fcf4d07161478ec8ea0707a50af02acc7fe6df6a
Author: Jacek Caban <jacek(a)codeweavers.com>
Date: Tue Jul 26 18:23:30 2022 +0200
user32: Use GetWindowLongPtr for GetWindowModuleFileName implementation.
dlls/user32/win.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
joerg@Archimedes ~/Projekte/wine_src/wine %
--
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=54139
Bug ID: 54139
Summary: rpcrt4:server - test_stop_wait_for_call() sometimes
crashes on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: rpc
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
test_stop_wait_for_call() sometimes crashes on Windows:
server.c:2258: this is the last test seen before the exception
20e8:server: unhandled exception 000006a6 at 776CC392
server.c:1226: unhandled exception 000006a6 in child process 20e8
See https://test.winehq.org/data/patterns.html#rpcrt4:server
Where 0x000006a6 == RPC_S_INVALID_BINDING.
This is similar to the RPC_S_CALL_FAILED crash that happens on Windows 10+.
--
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=54148
Bug ID: 54148
Summary: shell32:shlfolder - test_SHOpenFolderAndSelectItems()
sometimes fails on Windows 11 with a generic E_FAIL
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: shell32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
test_SHOpenFolderAndSelectItems() sometimes fails on Windows 11 with a generic
E_FAIL:
shlfolder.c:5493: Test failed: Got unexpected hr 0x80004005.
See https://test.winehq.org/data/patterns.html#shell32:shlfolder
This happens a bit under twice per month and so far all 7 instances are on
w11pro64*.
--
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=54167
Bug ID: 54167
Summary: urlmon:url - The ftp test sometimes time out in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: urlmon
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
urlmon:url - The ftp test sometimes time out in Wine:
url.c:4231: ftp test...
url.c:1638: Test marked todo: unexpected call OnProgress_FINDINGRESOURCE
url.c:1650: Test marked todo: unexpected call OnProgress_CONNECTING
urlmon:url:027c done (258) in 120s 4472B
See https://test.winehq.org/data/patterns.html#urlmon:url
This happens a bit under one time per month.
urlmon:url usually takes under 10 seconds to run so it's not just the test
being a little bit slow. Also this test never times out on Windows so it's
doubtful that this is caused by network issues or server unavailability.
--
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.