https://bugs.winehq.org/show_bug.cgi?id=49305
Bug ID: 49305
Summary: Sniper Elite V2 (Sniper Elite 3, Zombie Army Trilogy)
fails to start on Steam
Product: Wine
Version: 5.9
Hardware: x86
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: mountmgr.sys
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: hans(a)meelstraat.net
Regression SHA1: 4ed26b63ca0305ba750c4f38002cf1eb674f688c
Distribution: ---
Created attachment 67315
--> https://bugs.winehq.org/attachment.cgi?id=67315
terminal output
The games in the bug title refuse to start, the executable is present in the
process list, but the launcher of the games doesn't appear. This seems to only
happen in a WOW64 prefix, the launcher starts properly in a 32-bit WINEPREFIX.
This error appears in the terminal after starting Sniper Elite V2 (2012):
>>00a0:err:seh:setup_exception stack overflow 2288 bytes in thread 00a0 eip 000000007bcb7596 esp 0000000000ab0d20 stack 0xab0000-0xab1000-0xbb0000
Reverting commit 4ed26b63ca0305ba750c4f38002cf1eb674f688c fixes the problem for
me.
The original Sniper Elite V2 that I own is no longer available on Steam, it was
replaced with the Remastered edition, but I don't have that particular version
to test if the bug is present with that too.
This is the version I have:
https://store.steampowered.com/app/63380/Sniper_Elite_V2/
The other games that are affected by this bug:
https://store.steampowered.com/app/238090/Sniper_Elite_3/https://store.steampowered.com/app/301640/Zombie_Army_Trilogy/
wine-5.9-238-g3c86adab76
--
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=7102
Alexandre Julliard <julliard(a)winehq.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #24 from Alexandre Julliard <julliard(a)winehq.org> ---
Closing bugs fixed in 5.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=38587
Bug ID: 38587
Summary: RF:G is Incredibly Laggy, Then Crashes
Product: Wine
Version: 1.6
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: superrobowizard(a)gmail.com
Distribution: ---
When trying to run Red Faction: Guerrilla on Wine, the introduction credits
audio constantly loops the most recent second over the current audio, making it
sound really glitchy. When it gets to the loading screen everything is fine
again, and it loads the main menu. The menu works fine at full speed for less
than half a second, then my framerate tanks to about 1-2 FPS. After a few
seconds of this (the game works fine, it's just incredibly laggy) the window
locks up entirely. I can't do anything after that except mash ctrl+alt+delete
until I log off. I have used apt-get purge as well as apt-get uninstall and
then re-installing multiple times, and it doesn't help. (I launch it using
"wine /directory/Steam.exe -no-dwrite")
--
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=49160
Bug ID: 49160
Summary: Unity: SystemInfo.deviceUniqueIdentifier always the
same under Wine
Product: Wine
Version: 5.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wmi&wbemprox
Assignee: wine-bugs(a)winehq.org
Reporter: jamiesonc2(a)gmail.com
Distribution: Ubuntu
Unity's SystemInfo.deviceUniqueIdentifier always returns the same value under
Wine, because the underlying data used to populate the property are hardcoded
in Wine. Applications that depend on SystemInfo.deviceUniqueIdentifier being
unique between different systems may behave unexpectedly, including identity
collisions in cloud services clients.
This behavior was observed in the Syrinscape Online (beta) application, which
relies on SystemInfo.deviceUniqueIdentifier to link desktop apps with online
accounts. Wine users are getting linked with other Wine users' online accounts
because all of the Syrinscape Online clients appear to be running on the same
device.
https://www.syrinscape.com/online/
See this Syrinscape support forum thread where the issue was discussed:
https://forum.syrinscape.com/t/who-is-stuart-kehoe/8850
Details about Unity's SystemInfo.deviceUniqueIdentifier:
https://docs.unity3d.com/ScriptReference/SystemInfo-deviceUniqueIdentifier.…
The following data is retrieved from wbemprox to generate a UID:
Win32_BaseBoard::SerialNumber
Win32_BIOS::SerialNumber
Win32_Processor::UniqueId
Win32_DiskDrive::SerialNumber
Win32_OperatingSystem::SerialNumber
As of Wine 5.8, these values are hardcoded. From the latest wbemprox/builtin.c
at the time of this writing:
https://source.winehq.org/git/wine.git/blob/93758fc3ef16eed6cf1639aa6c31f6a…
Line 1103: Baseboard serial number = L"None"
Line 1295: BIOS serial number = L"0"
Line 2117: DiskDrive serial number = L"WINEHDISK"
Line 3216: Processor unique ID = NULL
Line 3417: OS serial number = L"12345-OEM-1234567-12345"
As a consequence of the above, the value of Unity's
SystemInfo.deviceUniqueIdentifier is always:
12a9126b14ff9b78b28d00f78e2bff20a224611b
PROPOSED:
If it is impractical to obtain actual serial numbers/IDs for the aforementioned
components, consider populating the values in a way that facilitates more
convenient user customization to workaround application issues.
1. Consider sourcing the values from specially designated registry keys,
populated during new WINE_PREFIX setup.
2. Consider populating said registry keys with random values rather than fixed
values. This will obviate the need for users to do any manual workarounds. (Not
sure if it would break other things, but philosophically, it's not unreasonable
to treat every WINE_PREFIX as though it's a whole new system build.)
--
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=49117
Bug ID: 49117
Summary: Virtual memory allocation gets slower when large
number of views are allocated (We Happy Few)
Product: Wine
Version: 5.7
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: rbernon(a)codeweavers.com
Distribution: ---
Created attachment 67101
--> https://bugs.winehq.org/attachment.cgi?id=67101
Patch for upcoming Wine 5.8
We Happy Few allocates an unusually large number of individual virtual memory
views (17k views allocated once the menu is reached), which then makes the
virtual memory allocation slower because of the large rbtree traversal.
Using a dedicated structure to track free memory ranges instead of the view
rbtree traversal leads to a huge FPS increase (tested at +20% when CPU bound)
once in 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=49211
Bug ID: 49211
Summary: BandLab Cakewalk 2020.04 crashes in
I_ScUnregisterDeviceNotification
Product: Wine
Version: 5.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: rpisl(a)seznam.cz
Distribution: ---
Created attachment 67218
--> https://bugs.winehq.org/attachment.cgi?id=67218
backtrace
BandLab Cakewalk 2020.04 crashes in I_ScUnregisterDeviceNotification on null
pointer dereference on exit.
--
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.