Server Troubleshooting
Summary: A symptom index for the most common DayZ server operations problems -- startup failures, connection issues, crashes, loot and vehicle spawning, persistence, and performance. Find your symptom, run the first-aid check, then follow the link to the chapter that owns the full fix.
Scope: This chapter is for running a server. For problems inside mod code -- script errors, RPC, UI, PBO builds -- see the mod-development Troubleshooting Guide.
Table of Contents
- Server Won't Start
- Players Can't Connect
- Crashes and Null Pointers
- Loot Not Spawning
- Vehicles Not Spawning
- Persistence Issues
- Performance Problems
- Reading Log Files
- Quick Diagnostic Checklist
Server Won't Start
Missing DLL Files
If DayZServer_x64.exe crashes immediately with a missing DLL error, install the latest Visual C++ Redistributable for Visual Studio 2019 (x64) from Microsoft's official site and restart.
Port Already in Use
Another DayZ instance or application is occupying port 2302. Check with netstat -ano | findstr 2302 (Windows) or ss -tulnp | grep 2302 (Linux). Kill the conflicting process or change your port with -port=2402.
Missing Mission Folder
The server expects mpmissions/<template>/ where the folder name exactly matches the template value in serverDZ.cfg. For Chernarus, that is mpmissions/dayzOffline.chernarusplus/ and it must contain at least init.c.
Invalid serverDZ.cfg
A single missing semicolon or wrong quote type prevents startup silently. Watch for:
- Missing
;at end of value lines - Smart quotes instead of straight quotes
- Missing
{};block around class entries
Missing Mod Files
Every path in -mod=@CF;@VPPAdminTools;@MyMod must exist relative to the server root and contain an addons/ folder with .pbo files. A single bad path prevents startup.
Players Can't Connect
Port Forwarding
DayZ needs these UDP ports forwarded and open in your firewall:
| Port | Protocol | Purpose |
|---|---|---|
| 2302 | UDP | Main game traffic |
| 2303-2304 | UDP | Steam networking |
| 2305 | UDP | Steam query port (steamQueryPort, default) |
The engine reserves the block 2302-2305 off the base port. If you change the base with -port=, the whole block shifts by the same offset. The query port default of 2305 is confirmed in Server Setup.
Firewall Blocking
Add DayZServer_x64.exe to your OS firewall exceptions. On Windows: netsh advfirewall firewall add rule name="DayZ Server" dir=in action=allow program="C:\DayZServer\DayZServer_x64.exe" enable=yes. On Linux, open the ports with ufw or iptables.
Mod Mismatch
Clients must have the exact same mod versions as the server. If a player sees "Mod mismatch," either side has an outdated version. Update both when any mod receives a Workshop update.
Missing .bikey Files
Every mod's .bikey file must be in the server's keys/ directory. Without it, BattlEye rejects the client's signed PBOs. Look inside each mod's keys/ or key/ folder.
Server Full
Check maxPlayers in serverDZ.cfg (default 60).
Crashes and Null Pointers
Null Pointer Access
SCRIPT (E): Null pointer access in 'MyClass.SomeMethod' -- the most common script error. A mod is calling a method on a deleted or uninitialized object. This is a mod bug, not a server misconfiguration. Report it to the mod author with the full script_*.log.
Finding Script Errors
Script errors land in the script_*.log, not the .RPT. Search that file for SCRIPT (E); the class and method name tells you which mod is responsible. Log locations:
- Server: the
profiles/directory (set with-profiles=, otherwise the server root) - Client:
%localappdata%\DayZ\
Engine-level failures -- missing addons, signature errors, hard crashes -- go in the .RPT instead. See Reading Log Files.
Crash on Restart
If the server crashes on every restart, storage_1/ may be corrupted. Stop the server, back up storage_1/, delete storage_1/data/events.bin, and restart. If that fails, delete the entire storage_1/ directory (wipes all persistence). See World State & Persistence for a safe recovery routine.
Crash After Mod Update
Revert to the previous mod version. Check the Workshop changelog for breaking changes -- renamed classes, removed configs, and changed RPC formats are common causes.
Loot Not Spawning
Loot lives in the central economy (CE). Most "it won't spawn" cases are a registration or tag mismatch, not a missing item.
| Symptom | Likely cause | First-aid check |
|---|---|---|
| A custom item never appears anywhere | types file not registered in cfgeconomycore.xml | Confirm a <file name="..." type="types" /> entry exists for your file |
| One item is absent, the rest spawn fine | Category / usage / value tag mismatch | Tags in types.xml must match cfglimitsdefinition.xml names exactly (case-sensitive: Military, not military) |
| Item is registered but count stays at zero | nominal is 0 | Set nominal to at least 1 for natural spawning |
| Item loads with no errors but still absent | No matching map group positions | Assign categories/usages that already have positions in mapgroupproto.xml |
First-aid: search the script_*.log at boot for CE load lines and any complaint about your economy files. A rejected types file logs an error there.
Full field-by-field walkthrough of cfgeconomycore.xml, tag definitions, nominal/min/lifetime tuning, and map group positions: see Loot Economy Deep Dive.
Vehicles Not Spawning
Vehicles use the event system, not types.xml.
| Symptom | Likely cause | First-aid check |
|---|---|---|
| No vehicles anywhere | Event set to <active>0</active> | Set the event to <active>1</active> in events.xml |
| Event active but no vehicles appear | Missing spawn coordinates | <position>fixed</position> events need entries in cfgeventspawns.xml |
| Vehicle count drops over time and never recovers | Wrecks occupy slots | Set remove_damaged="1" so the CE cleans up destroyed vehicles |
First-aid: confirm the event name in events.xml matches the name referenced in cfgeventspawns.xml exactly.
Full event structure (nominal/min/max, radii, children, spawn coordinates) is covered in Vehicle & Dynamic Event Spawning.
Persistence Issues
| Symptom | Likely cause | First-aid check |
|---|---|---|
| Bases and stored objects disappear | Territory flag expired | Check FlagRefreshFrequency in globals.xml (default 432000 = 5 days); a flag not refreshed in that window deletes everything in its radius |
| Items vanish after a restart | lifetime expired | Each item has a lifetime (seconds) in types.xml; container contents inherit the container's lifetime |
storage_1/ grows very large | Too many economy items | Reduce nominal values, especially food, clothing, and ammunition |
| All players spawn fresh | Player data lost | Player inventories live in storage_1/players/; back up storage_1/ regularly |
First-aid: never edit persistence files while the server is running -- it will overwrite your changes on the next save.
Lifetime reference values, flag refresh tuning, and safe storage_1/ maintenance are covered in World State & Persistence.
Performance Problems
| Symptom | Likely cause | First-aid check |
|---|---|---|
| Low server FPS (target is 30+) | Too many entities or heavy loot | Reduce ZombieMaxCount and AnimalMaxCount in globals.xml; lower nominal values |
| Rubber-banding, delayed actions, invisible zombies (desync) | Server FPS below ~15 | Fix the underlying FPS problem -- there is no desync-specific setting |
| Restarts take longer than 2-3 minutes | Oversized storage_1/ | Reduce loot nominals and set appropriate lifetimes to shrink persistence |
First-aid: watch server FPS in the admin console or a monitoring tool before changing settings, so you can measure the effect of each change.
Default values, the entity/loot/persistence trade-offs, and a step-by-step tuning method are in Performance Tuning.
Reading Log Files
Server Log Locations
Both logs live in profiles/ -- the directory passed to -profiles=, or the server root if that flag is unset:
script_<date>_<time>.log-- script output andSCRIPT (E)errors. This is your primary debugging tool.DayZServer_x64_<date>_<time>.RPT-- the engine report: startup, crashes, missing addons, and signature failures.
What to Search For
| Search term | Log | Meaning |
|---|---|---|
SCRIPT (E) | script log | Script error -- a mod has a bug |
Cannot register | RPT | Class-name collision between two mods |
Missing addons | RPT | A dependency is not loaded (wrong load order or missing mod) |
Signature verification failed | RPT | .bikey mismatch or missing key |
Cannot open | RPT | Missing file (PBO, config, mission) |
Crash | RPT | Application-level crash |
For mod-conflict diagnosis using these same logs, see Mod Management.
BattlEye Logs
BattlEye logs are in the BattlEye/ directory within your server root. These show kick and ban events. If players report being kicked unexpectedly, check here first.
Quick Diagnostic Checklist
When something goes wrong, work through this list in order:
1. Check the script_*.log for SCRIPT (E), and the .RPT for engine errors
2. Verify every -mod= path exists and contains addons/*.pbo
3. Verify all .bikey files are copied to keys/
4. Check serverDZ.cfg for syntax errors (missing semicolons)
5. Check port forwarding: 2302 UDP + Steam ports 2303-2305 UDP
6. Verify mission folder matches the template value in serverDZ.cfg
7. Check storage_1/ for corruption (delete data/events.bin if needed)
8. Test with zero mods first, then add mods one at a timeStep 8 is the most powerful technique. If the server works vanilla but breaks with mods, you can isolate the problem mod through binary search -- add half your mods, test, then narrow down.