I have a dual boot 9800x3d, 64gigs of ram, and a 5090. I can play fine in linux with proton, it never crashes. Once I log into Windows 11, I can only play for about 20-30 minutes before I crash. If I switch to the AMD on board graphics, I won't crash either, but I will only get about 40 fps.
#Crashing after 20-30 minutes of playing.
weary topaz
glad cape
You overclocked anywhere?
Or undervoltaged?
Both of those for whatever reason are known to cause this exact symptom
weary topaz
No, stock settings. I don't think it would be anything like that, because it won't crash in Linux
glad cape
Dang, was hoping it was the easy answer
weary topaz
also, it doesn't crash with the on board graphics
glad cape
Your card drivers are all updated and stuff?
glad cape
I'm out of town atm so can't dig deep, but if you wanna send me your player.log file after your next crash I can look on my return
weary topaz
I attached them to this post
glad cape
Oh fantastic
weary topaz
I use Bepinex, and a couple of mods
glad cape
I would try running vanilla to see if it persists
This playerlog looks like you crashed on closing the game is that always the case?
weary topaz
I guess it's not a total crash. The game locks up completely, no movement, no sound, no response. I have to use task manager to close out the game.
It just happened again, but it didn't generate a crash log.
I will try vanilla
weary topaz
Vanilla locked up, also. Same exact way. No movement, sound, or response. No new crash report either
weary topaz
It didn't generate a new one
glad cape
Player log is generated on startup so it should be there
glad cape
It's in users/appdata/locallow/burgeemedia/erenshor
weary topaz
yeah
glad cape
It's a d3d driver failing to respond, I've seen it in a few cases (usually that overclocking issue)
You may try rolling back drivers if you're so inclined, or keep running it in Linux. I do plan to add vulkan support at some point which would also be a fix but I'm not there just yet
weary topaz
strange, I don't even have pbo/tjmax enabled
I do have 6400mhz ram though, would that be an issue?
glad cape
Not sure, it's definitely not an issue of your system can't hang
weary topaz
oh, I just had a complete crash
glad cape
I'll take the new log just to see
glad cape
You 100% sure that beast of a system didn't come overclocked?
weary topaz
I just went thru every bios setting just now, to dbl check
I built it myself about 1 year ago
glad cape
What zone are you in?
glad cape
Have you tried any other zones?
weary topaz
it was crashing on me on Stowaway
glad cape
Could be a bad Steam download and needing a verify assets
weary topaz
I will try a complete reinstall. I verified the files already
glad cape
I threw your crash dump into Claude just because I'm remote on my phone and here's what it said
loaded the actual crash dump and pulled the exception record — this gives a much more precise answer than the log alone.
What the dump shows:
Exception code: 0xC0000005 — ACCESS_VIOLATION
Type: Read access violation
Faulting address being read: 0x0000000000000000 — a null pointer dereference
Crash location: UnityPlayer.dll + 0x9371A7 (thread ID 26584)
So this confirms precisely what kind of crash it is: something in Unity's native engine code tried to read through a null pointer, right after that big zone/asset unload finished (43,418 assets). This is a genuine engine-level bug trigger, not corrupted memory or a driver fault — the "null pointer" detail is the important new piece.
What this changes about my earlier diagnosis:
A null-deref in UnityPlayer.dll during asset unload is usually one of these:
A destroyed/unloaded object still being referenced by native code right after the mass unload (43k assets is a lot — likely a full zone transition) — something the game (or a specific asset in the new zone) is holding a stale reference to.
Less likely now, but still possible: a hook DLL (DisplayFusion) interfering with a callback Unity expects to be non-null. Hook injection crashes usually show corrupted/garbage addresses rather than a clean null pointer, so this is less likely than I first suggested — a null pointer is more classic of "the engine expected an object to still exist and it didn't."
Given this, I'd prioritize differently than before:
This looks like a genuine Erenshor/Unity bug tied to a specific zone or asset, reproducible right after that same large unload. This is worth reporting directly to the Erenshor developers (via Steam forums or their Discord) with this crash dump attached — that offset (UnityPlayer.dll+0x9371A7) and null-pointer detail is exactly the kind of thing they can search their own symbol database for.
Still worth testing without DisplayFusion running, but I'd treat it as secondary now rather than primary suspect.
If you can note which zone you were entering right before each crash, that reproducibility detail is gold for a bug report — if it's the same zone every time, that strongly points to a specific broken asset reference in that area rather than anything on your end.
Want me to check the thread list in the dump to see if this happened on the main thread or a background loading thread? That could help narrow down whether it's tied to async loading specifically.
weary topaz
I do have Displayfusion, should I try disabling it?
steam just got done reinstalling, I love fiber, lol
glad cape
Can't hurt
glad cape
We stable?
weary topaz
yeah, that's how I have been managing to play. it's just a pain to reboot if I need windows for something else
I am trying with a few of my regular programs like rewasd and overwolf stopped
who knows, maybe one of them has something going on that was interferring with the game
glad cape
There's not any globally known crashes atm, these d3d errors seem to be system specific but I haven't narrowed down a why yet
So if you keep fiddling you may find a solution
weary topaz
going on 40 mins, and I still haven't had a crash. I have my fingers crossed