World of Warcraft crashes with Error 132 (Access Violation)

[ghost]

I've been playing World of Warcraft using Wine 4.6+ and DXVK 1.1+ for the last many months without any issues, but this week the game repeatedly crashes throwing an "Error 132 - Access Violation" exception. The exception happens as soon as the loading screen finishes and the "actual game" is about to render. I have tried running the game with both Directx 11 and Directx 11 Legacy, and here is the Lutris installer script that I used: https://lutris.net/games/install/8505/view

I tried disabling DXVK and the game no longer throws the exception at all but it's unplayable at around 1-2 FPS. This is my I think it's an issue related to DXVK.

Please help! <3

Software information

Game: World of Warcraft Retail (Battle For Azeroth Version 8.1.5.30706)

System information

• GPU: Nvidia GeForce GTX 970
• Driver: NVidia Proprietary Driver 418.56
• Distro: Ubuntu 19.04 but the same behaviour is seen on Fedora 30 and Manjaro 18.04 (GNOME)
• Wine version: I've tried several, ranging from 4.0-tkg through to the latest 4.9 ge-protonified
• DXVK version: I've tried several ranging from 1.1.1 to latest 1.2.1 release

Apitrace file(s)

• Failed to Execute

Log files

https://pastebin.com/SAGewRpX

[doitsujin]

Relevant line in the log:

err:   DxvkMemoryAllocator: Memory allocation failed
  Size:      41984
  Alignment: 256
  Mem flags: 0x7
  Mem types: 0x681

No idea why, but your graphics driver fails to allocate system memory for some reason. Please make sure that you actually have enough RAM available and close anything that might eat gpu resources (browser); other than that I have absolutely no idea why this would fail.

[ghost]

Interesting. I had nothing else running and have 8 GB DDR4 RAM available, memory was only sitting at 43% in game.

On another note, I upgraded the driver to 430.14 and it is definitely better. Been playing for 10 min without a crash. I wish I knew why though =/

EDIT: Scratch that.. just crashed with the same exception :(

[SveSop]

I have also experienced those random crashes at times. I have had 1-2 crashes in a row trying to zone into eg. Darkshore from Boralus. Then for some random reason, the zoning goes through just fine, and after zoning back and forth a couple of times successfully it seems to clear up, but this is more or less just a general feeling, and i have not been able to find a reproducible method of causing this.

It is not a "out of memory" problem, but it is related to this #977 . Since i have not found a really reproducible way to make this happen, and sadly i do not have that much time to test these days, i have just given this issue up.

This does not happen with vkd3d and d3d12 tho, so of late i have used that. (Especially to try to help out with the wine-staging-4.9 crash issue that is solved in recent wine git).

[SveSop]

Just a random thought:
Since wine of late have done some overhaul of the msvcr library, and this has caused all kinds of issues with stuff that uses c++ like "Battle.net" and whatnot... AND DXVK being a cpp project, could this be related?
Wine now uses by default mingw-w64 to generate some linkage and stuff, and dxvk requires a up-to-date mingw-w64 to compile. Could some changes to the wine libraries cause SOME weirdness not neccessarily related directly to rendering? Ie. some dxvk module that writes files to disc, and changes with wine causes some random crud to be created due to changes, and that again causes crap to be piped back to the dxvk shader compiler?

Sorry, i am just shooting random ideas around, but i think the wine changes to msvcr started some time around wine-4.4-4.6 or so, and there have been various compile problems and stuff between each release of wine.. especially this time with wine-4.9 that crashed immediately for a lot of Battle.net games. The error causing dxvk to crash might not be logged as a understandable dxvk error, or as in this case be logged as some "out of memory" error when the factual thing is that the gfx adapter is far from oom. DXVK uses wine functions to do stuff, and if some of those functions is causing crap...?

Creating a +trace log with wine while playing WoW for "random time" in case one of those crashes happens is out of the question, so if anyone is able to create some reproducible test that will cause this every time that would be nice. Eg. "If clearing cache, starting from A and zone to B, relog and then zone from B -> C, this crash will happen 10 out of 10 times". Just so a manageable log can be created. (As this MAY absolutely be a wine problem causing dxvk to crash).

[ghost]

I can actually consistently reproduce it on this machine. As soon as I try to log in it crashes with the error. On my other machine I was seeing the same kind of behaviour as you're describing, where it happened "once in a while but not often and seemingly randomly".

I am new to DXVK troubleshooting though, is there a way I can provide some useful logging considering I can reproduce the problem?

[doitsujin]

You could enable DXVK_HUD=memory to check whether DXVK for some reason allocates very large amounts of memory, otherwise this sounds like some random driver/setup issue.

[prosenboim]

Just tried that. When loaded the char, It was about 900Mb allocated and 600Mb used when char just loaded. After few quests, zone changes it gradually raised to about 1900Mb allocated and 1600Mb used. Then, after using portal, it crashed. Don't know if these amounts considered normal or very large.

[Hamdor]

Just tried that. When loaded the char, It was about 900Mb allocated and 600Mb used when char just loaded. After few quests, zone changes it gradually raised to about 1900Mb allocated and 1600Mb used. Then, after using portal, it crashed. Don't know if these amounts considered normal or very large.

Can you provide some logs? The memory usage depends on the graphic settings used. But looks not too bad.

[pchome]

WINEDEBUG="+loaddll" logs could be useful too.
Just a guess, but such things usually happen when wine running wined3d, opengl32 and so on, along with DXVK/D9VK d3d* libs.

[SveSop]

Just tried that. When loaded the char, It was about 900Mb allocated and 600Mb used when char just loaded. After few quests, zone changes it gradually raised to about 1900Mb allocated and 1600Mb used. Then, after using portal, it crashed. Don't know if these amounts considered normal or very large.

Some of those "bugs" we are talking about could just aswell be program bugs with WoW. The thing is, that in Windows things might happen that does not cause crashes, but wine and/or dxvk on the other hand is something different. There are numerous things that DXVK have to do that is NOT "correct", but need to be done cos it is that way in Windows for some reason.

I have talked about WoW seems to eat small chunks of vram the longer you play, and loose some performance over the course of a gaming session. This CAN be the same in Windows, but i would not know (no Windows partition, only VM), or this CAN also be some sort of non-released memory of sorts.. i dont know.

So.. Log in, check memory/gpu/cpu usage and fps. Run around, play/raid/whatnot for a couple of hours, and then head back to where you logged in. After doing that, i more or less constantly experience lower fps and somewhat higher gpu/cpu usage. Not by much, but eg. go from 85 fps -> 78 fps in the same spot after a gaming session + more vram usage. Exit WoW and log back in, and i find myself at the mem usage/fps++ i had when i first logged in.

Solution? Dont know if it is any.. IS it anything wrong? Dunno. Can i point to a particular thing happening? Nope. Conclusion: Well.. Blame Blizzard, and do frequent game restarts :)

Crashing is possibly not directly related to this, atleast not when crashing immediately when logging in, but i tend to clear out any shader caches generated from nVidia /home/.nv folder and the WoW/retail/Cache folder rather frequently and that seems to help the issues a bit...

[prosenboim]

Not sure if game restarts will help here. On my setup, I see that when memory usage is almost full before game launch, game will almost certainly crash immediately after character load. In my case, it is firefox using lots of memory. Quitting firefox frees up this memory and usually, after that I can play without any issues for a long time.

[Pyrathar]

I do run the same problem all the time my workaround always works as well:
Close everything before launching it, then launch it.
Even a browser is enough to trigger this, but once memory is allocated everything runs fine

[SveSop]

@Pyrathar

I do run the same problem all the time my workaround always works as well:
Close everything before launching it, then launch it.
Even a browser is enough to trigger this, but once memory is allocated everything runs fine

So is this on "low memory system", or does this happen even with a 8GB vram card, and 32GB system ram? Cos 2GB vram i would understand it could be an issue, but cant really see WoW using >4GB vram even at 8MSAA at gfx level 10 i think.

[IngeniousDox]

https://bugs.winehq.org/show_bug.cgi?id=47351

Perhaps that can help.

[SveSop]

https://devtalk.nvidia.com/default/topic/1050516/vulkan/vk_ext_memory_budget-returns-too-high-budget/
Hmm..

I just tested VK_EXT_memory_budget with driver 425.30 on an RTX 2070 and Win 7, and the budget for the device memory is too high. If i try to allocate 95% of the budget minus the usage, which i should be allowed to do, i get an out of device memory error.

Not the same driver version and card, but makes me wonder if this could be some connection?

EDIT: It seems vkd3d does not "check" this in the same way, and that might explain why i dont really experience the same problems there perhaps?

Reimplement IDXGIAdapter3::QueryVideoMemoryInfo() on top of VK_EXT_memory_budget. Ideally, Vulkan implementations should return the memory budget based on total system load (memory used by all graphics APIs).

Is listed on the ToDo sheet of vkd3d, but i think DXVK checks this extension if its available (since 1.0). So.. anyone remember how to disable vulkan extensions in a easy manner for testing?

[doitsujin]

DXVK does not use the extension for internal purposes. It's merely used to report current VRAM utilization to the application, and 99.5% of all D3D11 games don't ever even call the function.

It would be very useful to know under which exact condition the game keeps crashing (especially memory and VRAM utilization), but in general, if memory allocation fails then there's absolutely nothing I can do.

[SveSop]

Well, it kinda seems as nVidia driver COULD have an issue with this extension, and perhaps reporting the wrong utilization? What happens if the game thinks more VRAM is used than it actually is? (For a game that actually calls this function). Would usage of this extension show up in a DXVK log for me to understand?

Since the crashing atleast for me seems completely random, where i could crash 2 times in 10 minutes, then play 10 days without issues, pinpointing the exact usage is kinda hard. The absolute fact is that it CANNOT be a REAL issue of running out of VRAM (disregarding an earlier issue with this when switching between various degrees of MSAA where memory was not released). I dont know the correlation between DXVK HUD reporting memory usage vs. nVidia SMI reporting usage tho, cos the numbers are not the same. Allocated vs. used and so on? I dont think nVidia SMI have any report of allocated vram, but only "in use now" type of report (and that is probably two different beasts)

[doitsujin]

What happens if the game thinks more VRAM is used than it actually is?

Nothing really. If the game over-subscribes VRAM, DXVK will just fall back to system memory. If that doesn't work either, you're basically completely screwed.

[IngeniousDox]

I was having it constantly today, then I switched from 430 to the 418.52.10 vulkan beta, and I haven't crashed since.

Fixes: Fixes crash when changing presentMode between swapchains

[SveSop]

I had a couple of crashes today switching back to DXVK from vkd3d. This happened when zoning from Boralus -> Darkshore. (See screenshot).

What seems to happen is that the loading screen kinda takes a while, and then crash. I was able to reproduce this 3 times (since when you crash, you get put back where you came from). However, the 4th time, there was no error.

Now, looking at the stats in the HUD, the "Memory allocated" and "Memory used", what does it REALLY mean? Is it system memory? Cos it has no similarity between actual vram used when reported by nVidia SMI (Cos at the time, nVidia SMI reported appx 1.7GB used, vs HUD reports 3.1GB.). When i was able to zone without crash, Memory used passed 4GB tho (RTX2070 with 8GB vram).

Has this number nothing really to do with vram usage, but more of a "what could be used" (which i kinda thought "allocated" meant). WoW is 64-bit, so 4GB+ should be no issue in that matter tho.

[doitsujin]

Now, looking at the stats in the HUD, the "Memory allocated" and "Memory used", what does it REALLY mean? Is it system memory?

"Memory allocated" is the amount of memory allocated from the graphics driver. This includes both VRAM and system memory used for graphics resources (i.e. constant buffers, staging buffers for data uploads, etc.)

[SveSop]

Now, looking at the stats in the HUD, the "Memory allocated" and "Memory used", what does it REALLY mean? Is it system memory?

"Memory allocated" is the amount of memory allocated from the graphics driver. This includes both VRAM and system memory used for graphics resources (i.e. constant buffers, staging buffers for data uploads, etc.)

What is "Memory used" then?

[doitsujin]

That's the amount of memory actually required for all resources. DXVK allocates memory in chunks of 64 MB, so if you have a simple application that creates e.g. one 4MB texture, you're going to end up with 64 MB allocated but only 4MB used. Of course it tries to stuff subsequent allocations into the same 64 MB chunk.

It also never frees these chunks, so you'll never see "Memory allocated" decrease unless a dedicated allocation is being freed (e.g. for render targets on Nvidia, or very large resources in general).

[SveSop]

That's the amount of memory actually required for all resources. DXVK allocates memory in chunks of 64 MB, so if you have a simple application that creates e.g. one 4MB texture, you're going to end up with 64 MB allocated but only 4MB used. Of course it tries to stuff subsequent allocations into the same 64 MB chunk.

It also never frees these chunks, so you'll never see "Memory allocated" decrease unless a dedicated allocation is being freed (e.g. for render targets on Nvidia, or very large resources in general).

Hmm.. im still somewhat confused between the "allocated" and "used" part.
If DXVK loads a 4MB texture, would the DXVK hud read 64MB used and 64MB allocated? And nVidia SMI read 4MB vram used? :)

[doitsujin]

you're going to end up with 64 MB allocated but only 4MB used

nvidia-smi would show the 64 MB if that texture is allocated in VRAM, otherwise 0 MB.

[doitsujin]

Closing in favour of #1100.