• Your i5-7600K has 4 cores and 4 threads, and the dump shows the engine running only two “short job” workers, both near the top of their stacks at the same moment (1005 KB and 922 KB). If that sort is split across the short workers, a 4-thread CPU hands each worker a much bigger slice than a 12- or 24-thread CPU does. Most people on Nasdara have far more threads, so each worker’s share stays shallow. I can’t prove the split without a dump from a bigger CPU, but it fits everything we’ve seen.

• Settings and server. High object detail plus a long object view distance put more instances in each slice. That’s the part we control, and it’s why LOW survived 18 towns.

Can't attach files sadly

thank claude later

Draft bug report for Bohemia (report.bistudio.com / feedback.bistudio.com) - DayZ 1.30.164200 client crash on Nasdara

Title: Client crash on Nasdara: stack overflow in an enfWorkShort worker thread (1 MB stack exhausted), crash handler then dies on the exhausted stack, so Windows reports StackHash_0000 / c0000005 and no .mdmp is written

Build: 1.30.164200.56 (Steam stable, exe dated 2026-10-27), Windows 11 23H2, RTX 2070 SUPER 8 GB (driver 621.01), i5-7600K, 32 GB RAM, 2560x1440 monitor, game at 1920x1080 fullscreen.

What happens: on Nasdara only (community servers and a local vanilla server from DayZ-Central-Economy dayzOffline.nasdara, no mods), the client dies 60-120 s after connecting while the landscape streams in, or after 1-2 hours of play, and instantly when a video setting is applied in game (resolution 1920x1080 -> 2560x1440). Chernarus-side sessions and the main menu are fine. 29 crashes between 26 and 30 October; reinstalling the game, verifying files, reinstalling mods and reinstalling the GPU driver changed nothing. Settings at the time: terrainGrid 3.125, sceneComplexity 500000, viewDistance 2200, preferredObjectViewDistance 2000, TexQuality 2, shadowQuality 2, FXAO 2, FXAA 2, PostFX 1.

Evidence (DayZDiag_x64.exe 1.30.164200.56 without BattlEye, Windows LocalDumps dump of pid 22712):

• Exception c0000005, WRITE to 0x8102400000, thread 20464 enfWorkShort 1, rip DayZDiag_x64.exe+0x12f5bc8, rsp 0x8102404a38 - the write is 0x4a38 below rsp, i.e. below the stack after the guard page was already used.

• That thread's captured stack is 1005 KB of a 1024 KB reserve (PE SizeOfStackReserve = 0x100000 for every thread); enfWorkShort 2 was at 922 KB at the same moment.

• Return addresses on the crashing stack repeat: DayZDiag_x64.exe+0x676c52 (27x), +0x6761ab (20x), +0x69d209 (14x), +0x69d4f8 (13x) - a recursion of roughly 27 levels with large frames, run as a short job.

• The frames nearest rsp are the crash handler (DayZDiag_x64.exe+0x23c9b7, +0x23d6be, +0x23e805, VCRUNTIME140, KERNELBASE, ntdll exception dispatch): the first overflow is caught, the handler runs on the same exhausted stack and faults again, so retail builds leave no .mdmp and Windows logs StackHash_0000 / PCH_84 (identical bucket for all 29 retail crashes).

• Last RPT lines before the crash are ordinary Nasdara streaming (Land_Garage_Row_Big, Land_Factory_Small ...).

Suggested fix: a larger stack for the enfWorkShort workers (or SizeOfStackReserve > 1 MB), or bounding the recursion in the job at +0x676c52 / +0x6761ab. Lowering the graphics preset to Medium is the community workaround and is consistent with the recursion depth depending on scene/terrain settings.

Attachments to add: the dump DayZDiag_x64.exe.22712.dmp (105 MB), DayZDiag_x64_2026-10-30_04-19-30.RPT, dump_22712_analysis.txt, dump_22712_threads.txt, and a retail DayZ_x64_*.RPT + crash_*.log pair from %LOCALAPPDATA%\DayZ.