Thanks for linking DZEXP-234. A bike being loaded or rendered at a distance is a plausible explanation, but I cannot confirm it from my tests: the client logs record entity loading, not the bike's distance or whether it was visible at the moment of failure.

In two official Many Motorbikes sessions, concrete motorbike loads were logged 8–30 seconds before Windows recorded the crash. I did not need to mount or ride one. A blue Jana had also rendered successfully earlier, so simply seeing any bike was not sufficient to cause an immediate crash. Other crashes occurred on ordinary official Experimental servers, including sessions with no concrete bike load recorded.

Your linked report contains a crash log explicitly reporting stack overflow. My repeated Windows faults were access violations at executable RVA 0x10d1f08, in a stack-probing routine. These findings are compatible with a related failure, but they do not establish the same underlying cause without a call stack or developer analysis.

Your graphics-setting result is a useful lead. My resolution reduction did not prevent the crash; I have not tested your change from Extreme to Medium or isolated view-distance settings. Those are different tests.

For the moderators: could these reports be compared, particularly the dump supplied in DZEXP-234 and the stack-probing fault here? I still have no dump from these crashes and would appreciate a supported capture method with BattlEye enabled.

Hello, no .mdmp was generated for the September 2026 crashes described in this report. The client froze and closed without showing a DayZ crash reporter. I checked the DayZ Experimental log folder and the configured Windows dump folders again today; the only .mdmp files available are from January 2025, so they are unrelated to this build.

Windows Error Reporting local full-dump collection was configured for DayZ_x64.exe, but its output folder remained empty after these crashes. A Microsoft Sysinternals ProcDump capture was also attempted, but BattlEye blocked it and no dump was captured. The monitor was stopped, and BattlEye remained enabled.

Could you provide a supported way to capture the required dump with BattlEye enabled, or advise whether the RPT, error/script logs and Windows crash event details would be useful in the meantime? Those logs from the reported runs are still available and could be supplied through private attachments.