https://bugs.winehq.org/show_bug.cgi?id=47731
Bug ID: 47731 Summary: World of Warcraft BFA Crash with error 132 Memory could not be read. Product: Wine-staging Version: 4.15 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: eaglecomputers.ok@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Pulling from git, and compiling on my system. 4.15 is crashing with error 132 in WoW-BFA. I can run the WoW Classic, but not the retail version. The regression first appeared in 4.14 -063 commit.
https://bugs.winehq.org/show_bug.cgi?id=47731
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |normal CC| |dark.shadow4@web.de
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- Are you using wine-staging or wine here?
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #2 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Fabian Maurer from comment #1)
Are you using wine-staging or wine here?
Win-staging, as shown on the product drop down.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #3 from Fabian Maurer dark.shadow4@web.de --- That's not what that dropdown means, it means that the issue is in wine-staging, instead of vanilla wine. Do you know if a staging patchset causes the error, or a wine-staging patchset?
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #4 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Fabian Maurer from comment #3)
That's not what that dropdown means, it means that the issue is in wine-staging, instead of vanilla wine. Do you know if a staging patchset causes the error, or a wine-staging patchset?
what is the difference between staging patchset and wine-staging patchset? All I am certain of, is wine staging 4.14 works fine, and when I compiled with a wine-staging git pull that started with -063, the error appeared, so I would assume that the problem is in the wine-staging repository.
https://bugs.winehq.org/show_bug.cgi?id=47731
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #5 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Steve Ebey from comment #4)
All I am certain of, is wine staging 4.14 works fine, and when I compiled with a wine-staging git pull that started with -063, the error appeared, so I would assume that the problem is in the wine-staging repository.
Hello,
I assume -063 is the number of commits, taken from the wine version number, and not an actual commit tag.
The regression can caused by any commit between the release tag and the last commit pulled.
Please, perform a regression test on the wine-staging git tree.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=47731
Sveinar Søpler cybermax@dexter.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax@dexter.no
--- Comment #6 from Sveinar Søpler cybermax@dexter.no --- Are you using DXVK with a nVidia adapter? If so, it could be that wine-staging-4.15 has made the DXVK "vulkan memory allocation" issue with nVidia more apparent somehow (unsubstantiated/unverified theory i must admit).
I have noticed more frequent crashing after wine-staging-4.15, but did not contribute this to a particular staging commit (yet).
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #7 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 47786 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #8 from Zebediah Figura z.figura12@gmail.com --- This issue seems to have gotten somewhat muddied. And since this keeps coming up, I've tried to clarify what we need on a Wiki page: https://wiki.winehq.org/Wine-Staging#Reporting_and_debugging_bugs_against_Staging
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #9 from Sveinar Søpler cybermax@dexter.no --- (In reply to Zebediah Figura from comment #8)
This issue seems to have gotten somewhat muddied. And since this keeps coming up, I've tried to clarify what we need on a Wiki page: https://wiki.winehq.org/Wine- Staging#Reporting_and_debugging_bugs_against_Staging
Since you cannot play WoW without staging patches it is kinda hard to say this is only a staging bug.
It is ofc possible to pick those patches that are not just "rebases" when viewing https://github.com/wine-staging/wine-staging/commits/master
If however a wine upstream patch causes a bug, but you MUST use staging to play a game, it is a tedious task to bisect ALL patches from 4.14-4.15 as this is many hundreds and taking quite a few minutes between each compile.. Well..
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- (In reply to Sveinar Søpler from comment #9)
Since you cannot play WoW without staging patches it is kinda hard to say this is only a staging bug.
Yes, that's accounted for in the link above.
It is ofc possible to pick those patches that are not just "rebases" when viewing https://github.com/wine-staging/wine-staging/commits/master
If however a wine upstream patch causes a bug, but you MUST use staging to play a game, it is a tedious task to bisect ALL patches from 4.14-4.15 as this is many hundreds and taking quite a few minutes between each compile.. Well..
The magic of bisections is that "many hundreds" still only means about ten steps ;-)
Anyway, yes, it's a lot of work, but someone has to do it, or you have to ask developers to solve this bug as if they knew nothing about it. Believe me when I say that's far more difficult.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #11 from Sveinar Søpler cybermax@dexter.no --- (In reply to Zebediah Figura from comment #10)
The magic of bisections is that "many hundreds" still only means about ten steps ;-)
Anyway, yes, it's a lot of work, but someone has to do it, or you have to ask developers to solve this bug as if they knew nothing about it. Believe me when I say that's far more difficult.
Yep. But you would only end up with a staging patch commit anyway, cos it is not that easy to bisect wine when needing staging. (Atleast not for me). Ie. Lets say i take a random git pull of wine, and try to apply staging to that it will fail.
So you would end up with a certain commit of staging causing a regression, but the commit COULD still be in wine, and somewhat harder to find out as its not "just" reverting patches of wine without breaking staging.
Then again, i am not that pro, so it could be easy for those in the know :)
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #12 from Zebediah Figura z.figura12@gmail.com --- (In reply to Sveinar Søpler from comment #11)
Yep. But you would only end up with a staging patch commit anyway, cos it is not that easy to bisect wine when needing staging. (Atleast not for me). Ie. Lets say i take a random git pull of wine, and try to apply staging to that it will fail.
So you would end up with a certain commit of staging causing a regression, but the commit COULD still be in wine, and somewhat harder to find out as its not "just" reverting patches of wine without breaking staging.
Then again, i am not that pro, so it could be easy for those in the know :)
Yes, that's why, as the instructions say, you want to first identify the minimal subset of Staging patches that are necessary to allow the application to run. That takes every other patch out of the equation, and also means they won't be a problem when trying to apply patches.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #13 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Zebediah Figura from comment #12)
(In reply to Sveinar Søpler from comment #11)
Yep. But you would only end up with a staging patch commit anyway, cos it is not that easy to bisect wine when needing staging. (Atleast not for me). Ie. Lets say i take a random git pull of wine, and try to apply staging to that it will fail.
So you would end up with a certain commit of staging causing a regression, but the commit COULD still be in wine, and somewhat harder to find out as its not "just" reverting patches of wine without breaking staging.
Then again, i am not that pro, so it could be easy for those in the know :)
Yes, that's why, as the instructions say, you want to first identify the minimal subset of Staging patches that are necessary to allow the application to run. That takes every other patch out of the equation, and also means they won't be a problem when trying to apply patches.
FWIW, for WoW you should only need winebuild-Fake_Dlls, ntdll-Builtin_Prot and ntdll-User_Shared_Data staging patchsets.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #14 from Sveinar Søpler cybermax@dexter.no --- (In reply to Matteo Bruni from comment #13)
FWIW, for WoW you should only need winebuild-Fake_Dlls, ntdll-Builtin_Prot and ntdll-User_Shared_Data staging patchsets.
Nice. I will see if i can get WoW running with only those patches.
Instead of posting a rather detailed explanation to what could be causing this error, i fear it would be deemed of topic, so i will just conclude with asking the OP - Steve Ebay the following:
1. Are you using WineD3D or DXVK? 2. Is the problem still the same with 4.16? (And possibly upcoming 4.17 this weekend). 3. In the case of DXVK and "YES" to #2: Are you using a nVidia graphics card?
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #15 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #14)
(In reply to Matteo Bruni from comment #13)
FWIW, for WoW you should only need winebuild-Fake_Dlls, ntdll-Builtin_Prot and ntdll-User_Shared_Data staging patchsets.
Nice. I will see if i can get WoW running with only those patches.
Instead of posting a rather detailed explanation to what could be causing this error, i fear it would be deemed of topic, so i will just conclude with asking the OP - Steve Ebay the following:
- Are you using WineD3D or DXVK?
- Is the problem still the same with 4.16? (And possibly upcoming 4.17 this
weekend). 3. In the case of DXVK and "YES" to #2: Are you using a nVidia graphics card?
1. vkd3d (for dx12), and dxvk. 1a. it only appears to crash with retail. I can run the classic version with no problems. 2. yes, to 4.15 and 4.16. 3. yes, same card I have used for 4 years, GTX 970, with proprietary drivers.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #16 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #15)
- vkd3d (for dx12), and dxvk.
1a. it only appears to crash with retail. I can run the classic version with no problems. 2. yes, to 4.15 and 4.16. 3. yes, same card I have used for 4 years, GTX 970, with proprietary drivers.
1. Since "Classic" does not support D3D12, you would be using DXVK there. vkd3d is currently broken in Nazjatar, so if you use D3D12 in "Retail" you cant go there. I would assume you have not tried WineD3D and see if you crash with that (99.9% sure you won't).
3. What version is "proprietary"? The distro provided drivers? (Currently 430.26 for Ubuntu 18.04 afaik). You should try the 435.24.02 drivers, or atleast 435.19.03. Ref. release notes to 435.19.03:
Fall back to system memory when video memory is full for some driver-internal > allocations.
This can help fix Xid 13 and Xid 31 cases when video memory is full.
There is additional improvements for this in 435.24.02 although not listed on the releasenotes.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #17 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #16)
(In reply to Steve Ebey from comment #15)
- vkd3d (for dx12), and dxvk.
1a. it only appears to crash with retail. I can run the classic version with no problems. 2. yes, to 4.15 and 4.16. 3. yes, same card I have used for 4 years, GTX 970, with proprietary drivers.
- Since "Classic" does not support D3D12, you would be using DXVK there.
vkd3d is currently broken in Nazjatar, so if you use D3D12 in "Retail" you cant go there. I would assume you have not tried WineD3D and see if you crash with that (99.9% sure you won't).
- What version is "proprietary"? The distro provided drivers? (Currently
430.26 for Ubuntu 18.04 afaik). You should try the 435.24.02 drivers, or atleast 435.19.03. Ref. release notes to 435.19.03:
Fall back to system memory when video memory is full for some driver-internal > allocations.
This can help fix Xid 13 and Xid 31 cases when video memory is full.
There is additional improvements for this in 435.24.02 although not listed on the releasenotes.
1. Got pathfinder, so do not need to do nazjatar, so i do run vkd3d on retail. How do I implement WineD3D, and will I need to remove vulkan?
3. Nvidia 435.24.02 on Fedora 30.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #18 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #17)
- Got pathfinder, so do not need to do nazjatar, so i do run vkd3d on
retail. How do I implement WineD3D, and will I need to remove vulkan?
- Nvidia 435.24.02 on Fedora 30.
And you are crashing with "Error 132" with d3d12/vkd3d too?
To switch to WineD3D you need to uninstall dxvk (via the dxvk package script). Choosing D3D11 in WoW settings will then use WineD3D. (WineD3D is wine's D3D11 -> OpenGL translation).
May i also ask what motherboard you have?
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #19 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #18)
(In reply to Steve Ebey from comment #17)
- Got pathfinder, so do not need to do nazjatar, so i do run vkd3d on
retail. How do I implement WineD3D, and will I need to remove vulkan?
- Nvidia 435.24.02 on Fedora 30.
And you are crashing with "Error 132" with d3d12/vkd3d too?
To switch to WineD3D you need to uninstall dxvk (via the dxvk package script). Choosing D3D11 in WoW settings will then use WineD3D. (WineD3D is wine's D3D11 -> OpenGL translation).
May i also ask what motherboard you have?
Yes, I am crashing, with vkd3d on retail.
to aid you, I have included a subset of inxi, showing system info
Machine: Type: Desktop Mobo: ASUSTeK model: M5A97 LE R2.0 v: Rev 1.xx serial: 150954265201367 BIOS: American Megatrends v: 2701 date: 03/24/2016 CPU: Topology: 8-Core model: AMD FX-8350 bits: 64 type: MCP arch: Bulldozer family: 15 (21) model-id: 2 stepping: N/A microcode: 6000852 L1 cache: 384 KiB L2 cache: 2048 KiB L3 cache: 8192 KiB flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 64215 Speed: 4111 MHz min/max: 1400/4000 MHz boost: enabled Core speeds (MHz): 1: 4112 2: 4106 3: 4109 4: 4112 5: 4107 6: 4111 7: 4110 8: 4109 Vulnerabilities: Type: l1tf status: Not affected Type: mds status: Not affected Type: meltdown status: Not affected Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization Type: spectre_v2 mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling Graphics: Device-1: NVIDIA GM204 [GeForce GTX 970] vendor: ZOTAC driver: nvidia v: 435.21 bus ID: 01:00.0 chip ID: 10de:13c2 Display: server: Fedora Project X.org 1.20.5 driver: nvidia resolution: 1680x1050~60Hz OpenGL: renderer: GeForce GTX 970/PCIe/SSE2 v: 4.6.0 NVIDIA 435.21 direct render: Yes
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #20 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #19)
Machine: Type: Desktop Mobo: ASUSTeK model: M5A97 LE R2.0 v: Rev 1.xx serial: 150954265201367 BIOS: American Megatrends v: 2701 date: 03/24/2016
I could not find the bios setting i was looking for on that motherboard, so it is probably not that.
Also i can't say i have ever experienced huge issues with vkd3d and this error, even when i had GTX970, so i dunno. Well.. Back to the theory spinning again :P
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #21 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #20)
(In reply to Steve Ebey from comment #19)
Machine: Type: Desktop Mobo: ASUSTeK model: M5A97 LE R2.0 v: Rev 1.xx serial: 150954265201367 BIOS: American Megatrends v: 2701 date: 03/24/2016
I could not find the bios setting i was looking for on that motherboard, so it is probably not that.
Also i can't say i have ever experienced huge issues with vkd3d and this error, even when i had GTX970, so i dunno. Well.. Back to the theory spinning again :P
Compiled and ran 4.17 and it also crashed on the retail but not on classic. Crashed with wined3d, vkd3d, and dxvk. the crashes started back around the 4th or 5th commit, from the git, in version 4.14. I have kept a working 4.14 staging, and trying to learn how to bisect the git to see the commit that caused the problem.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #22 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #21)
Compiled and ran 4.17 and it also crashed on the retail but not on classic. Crashed with wined3d, vkd3d, and dxvk. the crashes started back around the 4th or 5th commit, from the git, in version 4.14. I have kept a working 4.14 staging, and trying to learn how to bisect the git to see the commit that caused the problem.
I had no such problems with wine-staging-4.17.
Did you try to clear out WoW caches, DXVK caches and nVidia caches?
~/.nv/GLCache (Unless you use custom folder) c/Program Files (x86)/World of Warcraft/_retail_/Cache (delete everything) c/Program Files (x86)/World of Warcraft/_retail_/Wow.dxvk-cache
World of Warcraft ofc residing inside the wineprefix you use.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #23 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #22)
(In reply to Steve Ebey from comment #21)
Compiled and ran 4.17 and it also crashed on the retail but not on classic. Crashed with wined3d, vkd3d, and dxvk. the crashes started back around the 4th or 5th commit, from the git, in version 4.14. I have kept a working 4.14 staging, and trying to learn how to bisect the git to see the commit that caused the problem.
I had no such problems with wine-staging-4.17.
Did you try to clear out WoW caches, DXVK caches and nVidia caches?
~/.nv/GLCache (Unless you use custom folder) c/Program Files (x86)/World of Warcraft/_retail_/Cache (delete everything) c/Program Files (x86)/World of Warcraft/_retail_/Wow.dxvk-cache
World of Warcraft ofc residing inside the wineprefix you use.
Still crashed. Not sure what else to try.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #24 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #23)
Still crashed. Not sure what else to try.
Not really sure what else to try. Might try toggling the BIOS option IOMMU to see if it is creating some weirdness, but i doubt it would be that.
Quote from https://download.nvidia.com/XFree86/Linux-x86_64/340.104/README/dma_issues.h...
On AMD's AMD64 platform, the size of the IOMMU can be configured in the system BIOS or, if no IOMMU BIOS option is available, using the 'iommu=memaper' kernel parameter. This kernel parameter expects an order and instructs the Linux kernel to create an IOMMU of size 32 MB^order overlapping physical memory. If the system's default IOMMU is smaller than 64 MB, the Linux kernel automatically replaces it with a 64 MB IOMMU.
To reduce the risk of stability problems as a result of IOMMU space exhaustion on the X86-64 platform, the NVIDIA Linux driver internally limits its use of these interfaces. By default, the driver will not use more than 60 MB of IOMMU space, leaving at least 4 MB for the rest of the system (assuming a 64 MB IOMMU).
I only mention this, as the use of "IOMMU" has come up as a troubleshooting thing on various DXVK posts. It might not be in the right direction, but probably will not hurt to try? :)
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #25 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #24)
(In reply to Steve Ebey from comment #23)
Still crashed. Not sure what else to try.
Not really sure what else to try. Might try toggling the BIOS option IOMMU to see if it is creating some weirdness, but i doubt it would be that.
Quote from https://download.nvidia.com/XFree86/Linux-x86_64/340.104/README/dma_issues.h...
On AMD's AMD64 platform, the size of the IOMMU can be configured in the system BIOS or, if no IOMMU BIOS option is available, using the 'iommu=memaper' kernel parameter. This kernel parameter expects an order and instructs the Linux kernel to create an IOMMU of size 32 MB^order overlapping physical memory. If the system's default IOMMU is smaller than 64 MB, the Linux kernel automatically replaces it with a 64 MB IOMMU.
To reduce the risk of stability problems as a result of IOMMU space exhaustion on the X86-64 platform, the NVIDIA Linux driver internally limits its use of these interfaces. By default, the driver will not use more than 60 MB of IOMMU space, leaving at least 4 MB for the rest of the system (assuming a 64 MB IOMMU).
I only mention this, as the use of "IOMMU" has come up as a troubleshooting thing on various DXVK posts. It might not be in the right direction, but probably will not hurt to try? :)
My iommu is set to 64MB in the bios. Should I disable iommu and see what happens?
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #26 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #25)
My iommu is set to 64MB in the bios. Should I disable iommu and see what happens?
Unless you know you need IOMMU for virtualization, you could try to disable it to see if it makes a difference. Might not, but does not hurt to try in case it could be causing troubles with the driver.
https://bugs.winehq.org/show_bug.cgi?id=47731
krovikan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |krovikan@gmail.com
--- Comment #27 from krovikan@gmail.com --- Always that I exit of the game, I have a 132 error.
I am with a wine-staging 5.8.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #28 from Sveinar Søpler cybermax@dexter.no --- (In reply to krovikan from comment #27)
Always that I exit of the game, I have a 132 error.
I am with a wine-staging 5.8.
Same for me. I am actually struggling with the difference of nVidia driver "branches".
Did some tests with nVidia "Vulkan beta - 440.66.1x" versions, and those seems to crash with "Error #132" rather randomly while playing, vs. the 440.100 and 450.51 Beta seems to crash mostly just when logging out after you have played for 2-3+ hours. Just logging in/out does not crash for me, but raiding a couple of hours, switching characters+++ for a few hours, exiting the game always generates a #132 crash.
This is with wine-lutris-4.16 + dxvk 1.4.6. (Does not really matter what wine/dxvk version i have used tho.. #132 happens in varying degree anyway)
I have only used this driver for 3 or 4 days, so it is too early to say if it NEVER crashes mid-game, but i am seriously getting ticked off by this. Since this CLEARLY (atleast on my system) exhibits differences when switching between nVidia driver branches/versions, i do believe this is something that is not necessarily wine and/or dxvk to blame.
For me this kind of crash usually only happens when i have played for a few hours without logging out. This in turn COULD mean some sort of memory management issue perhaps? Not something easily tested, as you cannot just change a setting, and log on do a quick M+ and think "Wow.. problem solved.. i did not crash". It is more of "How many crashes did i have this week per hour played, vs last week when i used X or Y".
https://bugs.winehq.org/show_bug.cgi?id=47731
LittleLunia94@Gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |LittleLunia94@Gmail.com
--- Comment #29 from LittleLunia94@Gmail.com --- Currently have this happen constantly on lutris-5.7.5 with DXVK 1.7.
It mostly happens when I take any portal, it will crash on the loading screen and from there on the game will constantly crash more and more often until I delete the GLCache and WoW Cache folders.
From there on it'll be fine again for a while until the next crash occurs and
it snowballs into more and more crashes again and I have to delete the folders again.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #30 from Sveinar Søpler cybermax@dexter.no --- (In reply to Lunia from comment #29)
Currently have this happen constantly on lutris-5.7.5 with DXVK 1.7.
It mostly happens when I take any portal, it will crash on the loading screen and from there on the game will constantly crash more and more often until I delete the GLCache and WoW Cache folders.
From there on it'll be fine again for a while until the next crash occurs and it snowballs into more and more crashes again and I have to delete the folders again.
What driver are you using?
The 450.56.02 driver from https://developer.nvidia.com/vulkan-driver seems to be working quite well with vkd3d-proton and d3d12 atleast.
Depending on distro, it can be a slightly scary business to upgrade the driver using the nVidia .run version vs. distro package. In the case of deb/ubuntu the "official" repo is horribly far behind on the releases me thinks.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #31 from Lunia LittleLunia94@Gmail.com --- (In reply to Sveinar Søpler from comment #30)
(In reply to Lunia from comment #29)
Currently have this happen constantly on lutris-5.7.5 with DXVK 1.7.
It mostly happens when I take any portal, it will crash on the loading screen and from there on the game will constantly crash more and more often until I delete the GLCache and WoW Cache folders.
From there on it'll be fine again for a while until the next crash occurs and it snowballs into more and more crashes again and I have to delete the folders again.
What driver are you using?
The 450.56.02 driver from https://developer.nvidia.com/vulkan-driver seems to be working quite well with vkd3d-proton and d3d12 atleast.
Depending on distro, it can be a slightly scary business to upgrade the driver using the nVidia .run version vs. distro package. In the case of deb/ubuntu the "official" repo is horribly far behind on the releases me thinks.
I'm using 450.57 right now. DX12 with VKD3D works perfectly fine with no error 132 except sometimes when closing the game, however DX12 VKD3D performance is quite a lot worse than DX11 DXVK for me, so I'd love to get DXVK working. :(
This seems to be some weird issue with DXVK + NVIDIA. Doitsujin said it was fixed by NVIDIA in like 440.59 but clearly that hasn't really been the case. My friend using an AMD GPU has no issue whatsoever and whenever I google this problem every single person seems to have an NVIDIA GPU.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #32 from Sveinar Søpler cybermax@dexter.no --- (In reply to Lunia from comment #31)
I'm using 450.57 right now. DX12 with VKD3D works perfectly fine with no error 132 except sometimes when closing the game, however DX12 VKD3D performance is quite a lot worse than DX11 DXVK for me, so I'd love to get DXVK working. :(
This seems to be some weird issue with DXVK + NVIDIA. Doitsujin said it was fixed by NVIDIA in like 440.59 but clearly that hasn't really been the case. My friend using an AMD GPU has no issue whatsoever and whenever I google this problem every single person seems to have an NVIDIA GPU.
I don't feel vkd3d is "quite a lot worse" when i use the vkd3d-proton branch atm, but it is lower than DXVK. And yes, the #132 error does happen a lot more with DXVK than with vkd3d-proton.
I did try the 450.57 driver, but found the performance a bit worse than 450.51 when it comes to "release" drivers.
The reason for using the "vulkan beta" driver is that it is nVidia's testbed of new vulkan extensions. The nVidia "versioning scheme" is really confusing, cos one would THINK that 450.57 had all the stuff 450.56 has, but that is not the case. The 450.56.x "vulkan beta" driver has vulkan extensions the 450.57 does not have.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #33 from Lunia LittleLunia94@Gmail.com --- Well, apparently Final Fantasy 14 started getting similar memory related crashes as well. Someone recommended creating a file called dxvk.conf with the contents:
d3d11.apitraceMode = True
where the Final Fantasy game executable is located.
I just created this dxvk.conf file next to the WoW.exe and surprisingly I was able to play all day with DXVK (DX11) enabled without a single crash, not even a crash when exiting the game. 12 hour session, closed game about 5 or 6 times.
Could totally be a fluke since the #132 error is kinda random but perhaps it works for someone else too.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #34 from Sveinar Søpler cybermax@dexter.no --- (In reply to Lunia from comment #33)
Could totally be a fluke since the #132 error is kinda random but perhaps it works for someone else too.
This!
Yeah... i have had situations where i have played 4-6 hours a day for a week or more... for it to crash 3 times the next night.
It does (to me) seems as the latest vulkan driver for nVidia (450.56.06 or 450.56.02 drivers) are more stable than the previous 440.x series vulkan beta.
https://bugs.winehq.org/show_bug.cgi?id=47731
--- Comment #35 from Lunia LittleLunia94@Gmail.com --- Just a little update on this, I've played three full days without a single crash with the d3d11.apitraceMode = True in the dxvk.conf now. It seems to have resolved the issue entirely.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla