[Bug 54436] New: wine-staging-8.0 regression (not working): Command & Conquer 3: Tiberium Wars Kane's Wrath
https://bugs.winehq.org/show_bug.cgi?id=54436
Bug ID: 54436 Summary: wine-staging-8.0 regression (not working): Command & Conquer 3: Tiberium Wars Kane's Wrath Product: Wine-staging Version: 8.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: kolAflash@kolahilft.de CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Created attachment 73981 --> https://bugs.winehq.org/attachment.cgi?id=73981 wine-staging-8.0: left is fine, right is broken
With wine-staging-7.0 "Command & Conquer 3: Tiberium Wars Kane's Wrath" was working fine.
In wine-8.0 and wine-staging-8.0 it's broken.
With wine-staging-8.0 the menu looks broken. See attached screenshot. (left is fine, right is broken)
With wine-8.0 the menu loads, but starting a skirmish game crashes the application. There's an error dialog window saying: Direct3D error 0x8007000e (E_OUTOFMEMORY)
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #1 from kolAflash kolAflash@kolahilft.de --- Related: https://bugs.winehq.org/show_bug.cgi?id=46012
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #2 from kolAflash kolAflash@kolahilft.de --- Created attachment 73982 --> https://bugs.winehq.org/attachment.cgi?id=73982 wine-8.0 crash logs
I did some more tests. I'm using OS version "Windows XP" and maximum ingame graphics settings.
wine-7.0 and wine-staging-7.0 are definitely fine. And if C:\windows\system32\d3dx9_29.dll from "winetricks d3dx9" is present, there's not even the graphics problem from bug 46012 (not even the WINEDLLOVERRIDES is needed, the d3dx9_29.dll just has to be overwritten by the correct version).
When the application is crashing under wine-8.0, it seems to make no difference if d3dx9_29.dll is the original or the "winetricks d3dx9" version. But if additionally WINEDLLOVERRIDES from "winetricks d3dx9" is set, the application crashes directly at startup. It even stays the same if I replace all the system32/*.dll's with the original versions, as long as I keep the WINEDLLOVERRIDES. See: wine-8.0_d3dx9.txt
For wine-8.0_d3dx9_dll-builtin.txt I removed the WINEDLLOVERRIDES from registry. In this case the application is starting, but the main menu is distorted and there's a crash if I try to load a level/map. No difference if I replace d3dx9_29.dll with the original version (only the registry entries seem to make the difference). With wine-7.9 in this scenario the application already crashes at startup, like in wine-8.0_d3dx9.txt
wine-7.8 seems to be the last fully working version. If it helps I can try to do a bisect between wine-7.8 and wine-7.9. Just tell me if it's needed.
https://bugs.winehq.org/show_bug.cgi?id=54436
Erich E. Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover@gmail.com
--- Comment #3 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to kolAflash from comment #2)
... wine-7.8 seems to be the last fully working version. If it helps I can try to do a bisect between wine-7.8 and wine-7.9. Just tell me if it's needed.
That would definitely help narrow things down. It sounds like this is both wine-staging and vanilla wine, is that correct?
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #4 from kolAflash kolAflash@kolahilft.de --- The problem happens with wine-staging and vanilla wine. And it happens with 32 bit and 64 bit wine prefixes.
Commits in chronological order.
This commit is the last which is completely fine (except for bug 46012). https://gitlab.winehq.org/wine/wine/-/commit/37b74e644a9011e9c79c2540c4bb715... git describe -> wine-7.8-191-g37b74e644a9
Beginning with this commit the game crashes directly at startup. This looks a little odd to me. Because the game uses DirectX-9 and as far as I know Vulkan shouldn't be used at all. (no DXVK installed) https://gitlab.winehq.org/wine/wine/-/commit/4a98b07c4bcc35a698448261478ba85... winex11.drv: Open a Vulkan device for D3DKMTOpenAdapterFromLuid(). The Vulkan device is used for querying video memory information for implementing D3DKMTQueryVideoMemoryInfo(). git describe -> wine-7.8-192-g4a98b07c4bc
With this commit the application starts again if d3dx9_29.dll from "winetricks d3dx9" is being used. But there are very heavy graphical glitches. https://gitlab.winehq.org/wine/wine/-/commit/deaf0891b096628cf99e58834c39a45... ntdll: Improve block size rounding compatibility. This also increase the default heap size to 2MiB (32bit) / 4MiB (64bit), for the tests to pass. git describe -> wine-7.9-314-gdeaf0891b09
Beginning with this commit the application starts again, even without using d3dx9_29.dll from "winetricks d3dx9". But the main menu has graphical glitches and the application crashes when loading a level/map. https://gitlab.winehq.org/wine/wine/-/commit/fd8e52b4e7604e85924afd70482282e... ntdll: Keep the region base offset in the block header. git describe -> wine-7.22-56-gfd8e52b4e76
https://bugs.winehq.org/show_bug.cgi?id=54436
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Product|Wine-staging |Wine CC|leslie_alistair@hotmail.com | Component|-unknown |d3d
https://bugs.winehq.org/show_bug.cgi?id=54436
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|d3d |-unknown
https://bugs.winehq.org/show_bug.cgi?id=54436
kolAflash kolAflash@kolahilft.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|wine-staging-8.0 regression |wine-8.0 regression (not |(not working): Command & |working): Command & Conquer |Conquer 3: Tiberium Wars |3: Tiberium Wars Kane's |Kane's Wrath |Wrath
https://bugs.winehq.org/show_bug.cgi?id=54436
kolAflash kolAflash@kolahilft.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|wine-8.0 regression (not |wine-8.0 regression |working): Command & Conquer |(E_OUTOFMEMORY): Command & |3: Tiberium Wars Kane's |Conquer 3: Tiberium Wars |Wrath |Kane's Wrath
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #5 from Erich E. Hoover erich.e.hoover@gmail.com --- The variety of symptoms here and what you're describing makes me think that the app uses stack-allocated memory and the stack is full.
https://bugs.winehq.org/show_bug.cgi?id=54436
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #6 from kolAflash kolAflash@kolahilft.de --- (In reply to Erich E. Hoover from comment #5)
The variety of symptoms here and what you're describing makes me think that the app uses stack-allocated memory and the stack is full.
How can this be influenced by the changes between wine-7.8 and wine-8.0 ?
Why did the stack not become full with wine <= 7.8 ?
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #7 from Austin English austinenglish@gmail.com --- (In reply to kolAflash from comment #6)
(In reply to Erich E. Hoover from comment #5)
The variety of symptoms here and what you're describing makes me think that the app uses stack-allocated memory and the stack is full.
How can this be influenced by the changes between wine-7.8 and wine-8.0 ?
Why did the stack not become full with wine <= 7.8 ?
Well, given that this bug is a regression, it sounds like some commit introduced a difference in memory allocation (or potentially a memory leak) that caused the crash you're seeing.
If you use native d3x9, does it not crash at deaf0891b096628cf99e58834c39a45a6c99c54c, but does crash at fd8e52b4e7604e85924afd70482282efd583e74c? If so, a bisect (with native d3dx9) between those two commits should identify the problem.
If that is not the case, then I'd suggest trying 4a98b07c4bcc35a698448261478ba856c149cbea, then cherry-pick deaf0891b096628cf99e58834c39a45a6c99c54c and/or fd8e52b4e7604e85924afd70482282efd583e74c and see how that behaves.
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #8 from kolAflash kolAflash@kolahilft.de --- Replaced the commit ids with git describe infos for comprehensibility. (example: commit deaf0891b09 is wine-7.9-314-gdeaf0891b09, see last 11 digits)
I assume with native you mean "d3dx9_29.dll" from "winetricks d3dx9"! Correct?
(In reply to Austin English from comment #7)
[...] If you use native d3x9, does it not crash at wine-7.9-314-gdeaf0891b09, but does crash at wine-7.22-56-gfd8e52b4e76 ? If so, a bisect (with native d3dx9) between those two commits should identify the problem.
Sadly this seems not to be easily testable, because: ---> With native d3dx9_26.dll and wine >= 7.9-314-gdeaf0891b09 the application sometimes immediately crashes and sometimes gets to the main menu.
With this in mind: ---> My bisect regarding native d3dx9_29.dll working (with glitches) with wine
= 7.9-314-gdeaf0891b09 may have been incorrect!
But the bisect with builtin d3dx9_29.dll seem to be fine. ---> So I suggest to debug the Wine buildin d3dx9_29.dll regression with wine-7.8-192-g4a98b07c4bc first.
If that is not the case, then I'd suggest trying wine-7.8-192-g4a98b07c4bc , then cherry-pick wine-7.9-314-gdeaf0891b09 and/or wine-7.22-56-gfd8e52b4e76 and see how that behaves.
wine-7.9-314-gdeaf0891b09 and/or wine-7.22-56-gfd8e52b4e76 conflict if being applied on wine-7.8-192-g4a98b07c4bc Unfortunately I don't know enough about the Wine code to resolve these conflicts, so I can't test that.
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #9 from kolAflash kolAflash@kolahilft.de --- The problem only seems to exist on certain hardware. I got three computers:
desktop computer CPU: Ryzen 7 5800X GPU: Radeon RX 590 (Gigabyte) Memory: 32 GB Video memory: 8192 MB (according to glxinfo) Ingame display resolution: 1920x1080 ---> crashes with wine-8.1
HP Notebook Model: HP EliteBook 735 G6 CPU + GPU: Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx Memory: 16 GB Video memory: 2048 MB (according to glxinfo) Ingame display resolution: 1920x1080 ---> works fine with wine-8.1
ThinkPad Notebook Model: ThinkPad X220 CPU + GPU: Core i7-2620M Memory: 8 GB Video memory: 1536 MB (according to glxinfo) Ingame display resolution: 1280x720 ---> works fine with wine-8.1
I booted a Debian live image on my different computers. So the software stack was always the same. https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware...
Additionally I discovered, that the problems seems not to happen with minimum ingame graphics settings. There seem to be different graphics settings triggering the problem. But for example a very high texture quality seems to trigger the problem.
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #10 from kolAflash kolAflash@kolahilft.de --- Created attachment 74034 --> https://bugs.winehq.org/attachment.cgi?id=74034 "Star Trek: Armada II" GL_OUT_OF_MEMORY crashlog
Now I have had the same problem with another game. I attached the log.
01b4:err:d3d:wined3d_debug_callback 00814310: "GL_OUT_OF_MEMORY in glMapBufferRange(map failed)".
Star Trek: Armada II https://appdb.winehq.org/objectManager.php?sClass=application&iId=2115
I have had this problem recently 2 times. "Star Trek: Armada II" never ran stable with wine-8.1 for more than 15 minutes. But I was able to run it without problems for more than 90 minutes using wine-7.0.
On the other hand I have played a lot of "Diablo III" and "StarCraft II" in the recent months. And they ran completely stable. I have always used the most recent wine version in the last month (so a lot of wine >= 7.9). So I guess these games are not affected at all.
Diablo III (mostly played with Wine OpenGL based DirectX renderer) https://appdb.winehq.org/objectManager.php?sClass=version&iId=29952
StarCraft II (mostly played with DXVK) https://appdb.winehq.org/objectManager.php?sClass=version&iId=20882
The main difference that comes to my mind is, that "Diablo III" and "StarCraft II" these are 64 bit applications. While "Star Trek: Armada II" and "Command & Conquer 3: Tiberium Wars" are 32 bit applications.
---> Is this problem maybe something about running 32 bit games on system with a lot of GPU memory?
Remember, "Command & Conquer 3: Tiberium Wars" runs fine on my notebooks with a maximum of 2048 MB of GPU memory. But the game crashes on my desktop computer with 8192 MB of GPU memory.
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #11 from Rafał Mużyło galtgendo@o2.pl --- Well, it just might be that those out of memory errors are actually the program running out of virtual mapping space.
There's a 4GB limit on that for 32bit apps, once you hit that crashes are some of more straightforward effects possible.
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #12 from kolAflash kolAflash@kolahilft.de --- (In reply to Rafał Mużyło from comment #11)
Well, it just might be that those out of memory errors are actually the program running out of virtual mapping space.
There's a 4GB limit on that for 32bit apps, once you hit that crashes are some of more straightforward effects possible.
That thought also came to my mind. But how can this be related to the changes between Wine 7.8 and 8.0?
May it be the Wine d3dx9 dlls using more space when loaded into the applications memory?
If yes, is this happening kind of deliberately? (saying: is this a somehow accepted change, because that additional memory is needed to implement new stuff)
Or is this maybe a limited memory leak, so there's really something broken? (limited, so it just crashes the 4 GB but not much more, so it neither affects 64 bit applications nor consumes all the systems memory)
https://bugs.winehq.org/show_bug.cgi?id=54436
kolAflash kolAflash@kolahilft.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|8.0 |8.1
--- Comment #13 from kolAflash kolAflash@kolahilft.de --- Until now I only tested with pure Debian-11 systems. (either installed or Debian-11.6 live image) Now I tested a Manjaro live image and could NOT reproduce the problem. https://download.manjaro.org/kde/22.0.3/manjaro-kde-22.0.3-minimal-230213-li...
Then I tried a custom Mesa 3D, libdrm and Vullkan versions I compiled some weeks ago. Also this also made the problem disappear. Command:
env \
VK_ICD_FILENAMES="${HOME}"/opt/mesa3d-versions/mesa-22.2.4/share/vulkan/icd.d/radeon_icd.x86_64.json:"${HOME}"/opt/mesa3d-versions/mesa-22.2.4/share/vulkan/icd.d/radeon_icd.i686.json \
LD_LIBRARY_PATH="${HOME}"/opt/mesa3d-versions/mesa-22.2.4/lib:"${HOME}"/opt/mesa3d-versions/mesa-22.2.4/lib32 /opt/wine-devel/bin/wine ...
Debian-11 has Mesa 3D version 20.3. Library versions in "${HOME}"/opt/mesa3d-versions/mesa-22.2.4/ - libdrm-2.4.114 - mesa-22.2.4 - Vulkan-Headers-1.3.238 - Vulkan-Loader-1.3.238
Strangely the issue also disappears if I simple use:
env VK_ICD_FILENAMES=/dev/zero /opt/wine-devel/bin/wine ...
... I'm confused!
https://bugs.winehq.org/show_bug.cgi?id=54436
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=54436
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |imwellcushtymelike@gmail.co | |m
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #14 from Ken Sharp imwellcushtymelike@gmail.com --- Adding VK_ICD_FILENAMES=/dev/zero causes the issue for me. Before this I am seeing an OOM error in the console, but no dialog window. However I am using DX9 to workaround graphical issues.
Under Windows 10, on the same hardware, the process uses around 1.5 GB of RAM and 1.0 GB of VRAM (and runs okay - it can still crash but much later on).
Are you still seeing the same behaviour in Wine 9.6?
https://bugs.winehq.org/show_bug.cgi?id=54436
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #15 from Ken Sharp imwellcushtymelike@gmail.com --- I just triggered it!
In the settings menu while clicking around, the game crashed with the error dialog. (While trying to work around another bug which isn't logged yet)
No native DLLs (including no DX9) but using a NoCD.
Tried again but I cannot reliably trigger the bug. Either way with and without DX9 the game exits.
According to htop and nvidia-smi the memory use never hits 1 GB RAM & 1GB VRAM. I don't know why it is having issues with memory.
https://bugs.winehq.org/show_bug.cgi?id=54436
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|wine-8.0 regression |Command & Conquer 3: |(E_OUTOFMEMORY): Command & |Tiberium Wars Kane's Wrath |Conquer 3: Tiberium Wars |exits with E_OUTOFMEMORY |Kane's Wrath |
https://bugs.winehq.org/show_bug.cgi?id=54436
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://cncnz.com/games/tib | |erium-wars/demo-information | |-download/ Keywords| |download
--- Comment #16 from Ken Sharp imwellcushtymelike@gmail.com --- Triggered trying to start a skirmish in the demo.
https://cncnz.com/games/tiberium-wars/demo-information-download/ $ sha1sum cnc3_demo.exe f6af21eba2d17eb6d8bb6a131b501b41c3a7eaf7 cnc3_demo.exe (Ignore the casing in my example, if comparing)
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #17 from Ken Sharp imwellcushtymelike@gmail.com --- Created attachment 76310 --> https://bugs.winehq.org/attachment.cgi?id=76310 Demo - Wine 9.6 console log [~15MB]
https://bugs.winehq.org/show_bug.cgi?id=54436
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|8.1 |8.0
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #18 from Ken Sharp imwellcushtymelike@gmail.com --- Created attachment 76312 --> https://bugs.winehq.org/attachment.cgi?id=76312 Wine 9.6 - demo showing graphics corruption
Tried various graphics settings within the demo but couldn't find any single setting that causes the issue. It simply seems to be turning everything all the way up that causes the issue, hence: a memory problem.
The demo even functioned without issue with settings set to "Ultra" which enables everything except anti-aliasing. However, lowering all the settings and setting anti-aliasing to its highest level does not cause the crash.
Attached screenshot is interesting: with everything set to its highest level and anti-aliasing set to L4, the game starts but with clearly corrupt graphics. Increasing the setting causes the crash. I suspect this may depend on hardware though.
Tried Staging 9.6 and the same thing.
https://bugs.winehq.org/show_bug.cgi?id=54436
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |56550
https://bugs.winehq.org/show_bug.cgi?id=54436
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor
--- Comment #19 from Ken Sharp imwellcushtymelike@gmail.com --- What's good for the demo is good for KW – lowering the graphics settings avoids the error.
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #20 from Ken Sharp imwellcushtymelike@gmail.com --- Been playing for a while and can confirm that the crash occurs when the VIRT mem hits the 4 GiB limit.
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #21 from Ken Sharp imwellcushtymelike@gmail.com --- I tried changing the ORM and shader backend but they made no difference. Changing the renderer to Vulkan leads to Bug 56716.
https://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #22 from Ken Sharp imwellcushtymelike@gmail.com --- (In reply to kolAflash from comment #2)
wine-7.0 and wine-staging-7.0 are definitely fine.
I'm still seeing the OOM in Wine 7.0 and earlier, but it could vary by hardware.
NVIDIA Corporation GK104GL [Quadro K5000] (rev a1)
I couldn't get KW to work properly at all with high graphics settings, though I didn't install fresh (clean wineprefix) every time as it takes too long. I can do that if I thought it would help.
My testing:
CNC3 Single Player Demo 1.0 Wine 6.0.2 - OK Wine 7.0 & 7.0.2 - OK Wine 7.6-7.7 - crashes before starting Wine 7.8 - memory usage is higher, but somehow manages to stay below the 4GB limit during gameplay (Skirmish is limited to one small map) Wine 7.9 - crashes before starting Wine 8.0-8.0.2 - OOM
CNC3: KW 1.2 Wine 3.0.5² - Too many problems Wine 6.0.2¹ - OOM Wine 7.0² & 7.0.2¹ - OOM Wine 7.6²-7.9² - crashes before starting Wine 8.0² - OOM crash Wine 8.0.1²-8.0.2² - Black screen
¹ No overrides ² Native d3dx_26.dll
http://bugs.winehq.org/show_bug.cgi?id=54436
--- Comment #23 from Hans Leidekker hans@meelstraat.net --- It's worth retesting 32-bit games like this using a new wow64 build. There may be more virtual address space available in that setup.
-
WineHQ Bugzilla