Freeze: 67 causes and who fixes them

Also called: frozen, hang, not responding

Everything on screen stops for a moment (0.5 s to a few seconds), then moves again.

Everyone stops. Only your own character moves a little on prediction or runs in place. When it clears, the backlog of movement comes through all at once as fast-forward or teleporting.

The whole server stopped (GC, deadlock, blocking call), the connection dropped briefly, or your PC froze.

Causes of this symptom

L1 Client game process

Frame time spike: One frame takes several times longer than usual to compute, so the screen freezes for a moment. (Game team (Client development))
Client garbage collection: The whole game freezes while it reclaims memory that was used and thrown away (garbage). The telltale sign is stutter at regular intervals. (Game team (Client development))
Synchronous loading and shader compilation on the main thread: The game freezes to read files and build shaders right before it draws an area, monster, or effect for the first time. (Game team (Client development))
Slow storage delays asset streaming: On slow storage such as an HDD, reading open-world textures and models can’t keep up with movement, so objects appear late or the game stutters while it waits for reads. (Game team (Client development))
Anti-cheat scans: The anti-cheat module that runs alongside the game to block cheats scans the system periodically. If a scan is heavy, or the heartbeat (a periodic keepalive signal) to the anti-cheat server is late, the game stutters or disconnects. (Game team (Client development))

L2 Client OS and device

Wi-Fi ↔ LTE/5G switching: When you walk out of the house and your phone drops Wi-Fi for LTE or 5G, your IP address changes and the existing connection stops working. (Game team (Server development))
Client low on memory and swapping: With dozens of browser tabs open alongside the game, the OS moves part of the game’s memory out to disk. (External (External))
Out of graphics memory (VRAM): When the graphics settings need more memory than the graphics card has, the OS moves textures out to system memory and brings them back, and the game stutters. (Game team (Client development))
NIC power saving and driver issues: When a network card or Wi-Fi chip enters a power-saving state between packets, it takes time to wake back up. (External (External))
Overlay software interference: Chat apps, launchers, recording tools, and FPS counters hook into the game’s rendering to draw their own UI on top of the game screen (hooking). That adds work to every frame and sometimes clashes with the game, causing hitches or crashes. (External (External))

L3 Home network

Cell tower handover (while moving): When you travel by bus or subway, the connection drops out while your phone switches cell towers. (External (External))
Frequent 5G↔LTE switching (at 5G coverage edges): Inside buildings with weak 5G signal or at the edge of 5G coverage, the phone switches between 5G and LTE often, and each switch causes a ping spike or a brief dropout. (External (External))

L4 Internet path

BGP route changes and convergence: When internet routing information changes, packets are lost for the few seconds to tens of seconds (rarely a few minutes) it takes to converge again. (Infra team (Network infrastructure))
Poor line quality: Loose connectors, old wiring, or a faulty modem cause steady packet loss and periodic line drops. (External (External))

L5 Data center network equipment

Network equipment failover: When a router or firewall fails and traffic switches to the standby unit (failover), everyone freezes for a few seconds. (Infra team (Network infrastructure))
MTU mismatch (only large packets vanish): If the MTU (the largest size that can be sent at once) shrinks somewhere along the path and the “packet too big” messages are blocked, only large packets keep vanishing. (Infra team (Network infrastructure))

L6 Server network card

Cloud host maintenance and live migration: When a cloud provider performs maintenance on a physical server (host), it moves VMs to another host (live migration) or pauses them briefly. The whole server freezes during that time, and if the pause is long, connections drop. (Infra team (Server infrastructure))
NIC driver and firmware problems: When a driver bug or a malfunctioning feature hangs the card, all traffic in and out stops while it restarts. (Infra team (Server infrastructure))

L7 Server OS (kernel)

CPU steal (virtual machines): While the physical server (hypervisor) briefly gives a virtual machine’s CPU time to another VM (CPU steal), the game server stalls. (Infra team (Server infrastructure))
Stalls from memory reclaim and compaction: The process stalls while the OS compacts memory to build huge pages or reclaims memory to free it up. (Infra team (Server infrastructure))

L8 Sockets and protocols

TCP head-of-line blocking: To keep data in order, TCP holds back every packet that arrived after a lost one until the lost packet is received again. (Game team (Server development))
TCP RTO and exponential backoff: Each time a retransmission fails again, the wait doubles, so a brief connection drop turns into a long stall. (Game team (Server development))
Blocking sends caused by slow clients: When one player on a slow connection has a full send buffer and the server sends in blocking mode (a send call that doesn’t return until the buffer has room), the server thread waits on that one player. (Game team (Server development))
Uneven SO_REUSEPORT distribution: When several processes share one port, the kernel assigns each connection to a process by address hash and never reassigns it. If one of those processes stalls, only the players assigned to it wait. (Game team (Server development))
WSAECONNRESET errors on Windows UDP sockets: When a Windows server sends UDP to a client that has already left, a “port unreachable” (ICMP) message comes back. That message makes the next receive call fail with an error, and if the server code treats the error as a failure of the socket itself, everyone using that socket is affected. (Game team (Server development))

L9 Server game process

Lock contention: When several threads wait on one lock to write the same data, they run one at a time no matter how many threads you add. (Game team (Server development))
Deadlock: When two threads each wait for a lock the other holds, both stop forever. (Game team (Server development))
Blocking calls on the game thread: If the server waits for a DB response or a file write in the middle of a tick, all game progress on the server stops for that long. (Game team (Server development))
Timers firing all at once: When every monster respawn, every buff expiry, and the on-the-hour reward all land on the same tick, that one tick becomes tens of times heavier. (Game team (Server development))
Thread pool exhaustion: When every worker thread is tied up in slow work, new requests just wait with no end in sight. (Game team (Server development))
Infinite loops and runaway logic: When a bug keeps a tick from ever finishing, the server stops, and the watchdog forces a restart. (Game team (Server development))
Spawn burst when entering a crowded area: When you teleport into a town packed with players, the server has to send the appearance, gear, and status of hundreds of newly visible players all at once. (Game team (Server development))

L10 Memory

Server GC stop-the-world pause: While a Java or C# server halts every thread to collect garbage (stop-the-world), the whole server stalls. (Game team (Server development))
Script engine GC pause: Even on a C++ server, if quests, AI, and skills run in a scripting language such as Lua, the zone stops while the script engine’s GC runs. (Game team (Server development))
Allocation surge: Creating large numbers of temporary objects during an event makes GC run far more often than usual. (Game team (Server development))
Memory leak: Memory that is never freed piles up little by little and, days later, leads to GC storms, swapping, or the process getting killed. (Game team (Server development))
GC thrashing (too little heap headroom): When live data gets close to the heap limit, each GC reclaims almost nothing, so GC runs over and over without a break. (Game team (Server development))
Swap: When memory runs short and the OS moves part of it out to disk, every access to that memory waits on a disk more than 1,000 times slower. (Infra team (Server infrastructure))

L11 Disk

Synchronous log writes: If the game thread waits for the disk to finish every log line, the game stalls too whenever the disk is busy. (Game team (Server development))
IOPS limit / queue saturation: When requests exceed what the disk can handle per second, the queue grows and latency explodes. (Infra team (Server infrastructure))
Server-side lazy loading: If the server reads dungeon or map data from disk the first time it’s requested, everyone freezes for that tick. (Game team (Server development))

L12 Database

DB failover: When the primary DB dies, writes stop while it fails over to a standby, and the last data that hadn’t been replicated yet can be lost. (Infra team (DB infrastructure))
Cache stampede: When cache entries for popular data expire at the same time, thousands of requests hit the DB all at once. (Game team (Server development))
Slow Redis commands: Redis processes commands one at a time, so a single slow command blocks every request behind it. (Game team (Server development))

L13 Server architecture and operations

Zone transfer (handoff between servers): Entering another area or dungeon means handing the character’s data to another server, and that handoff can be slow or fail. (Game team (Server development))
Cascading failure: When one service slows down, the servers that call it get tied up waiting for responses, and even unrelated features stop. (Game team (Server development))
Logging and monitoring overload: During an outage, log volume explodes, and servers that ship logs synchronously get even slower because of the logging. (Game team (Server development))

Netcode design

Lockstep waiting on the slowest player: When everyone computes the same turn together, one player’s late input makes everyone wait. (Game team (Server development))
Player-hosted server (host): When one player’s PC acts as the server, that player’s connection and PC performance decide how the game feels for everyone. (Game team (Server development))

Problems only some players hit

Bloated data on one character: A character with thousands of items or mails piled up, or an unusually large friend list, block list, or set of buffs, has several times more to load, save, and announce to nearby players than others. It’s slow only on that character, regardless of connection. (Game team (Server development))

Root causes of TCP retransmission

Wireless link loss: Wi-Fi and mobile networks retransmit a few times on the wireless link and drop the packet if that still fails. TCP resends the dropped packet only much later. (External (External))
Bottleneck queue overflow (congestion loss): When the queue at the narrowest point fills up, such as a home router, a link between ISPs, or a data center uplink, newly arriving packets are dropped. (Infra team (Network infrastructure))
Send bursts overflow shallow buffers: When a server sends a whole tick of updates for thousands of players in one instant, a switch’s small buffer or a cloud instance’s short-term limit overflows in under 1 ms and some packets are dropped. (Game team (Server development))
Policer drops excess traffic: ISP plans, cloud instance limits, and DDoS protection devices sometimes drop packets over a set rate right away, without queuing them. (Infra team (Network infrastructure))
Physical errors (bad cable, optics, connectors): Damaged cables, dirty fiber connectors, and worn-out optics cause bit errors, and network equipment silently drops the corrupted packets. (Infra team (Network infrastructure))
Duplex mismatch: If one end autonegotiates while the other has speed and duplex hard-set, one side runs half duplex and loses packets to collisions whenever load picks up. (Infra team (Network infrastructure))
Packet drops on the receiving host: Packets reach the server but get dropped, because the NIC’s ring buffer (which briefly holds arriving packets) overflows or the kernel cores that handle receive processing are saturated. (Infra team (Server infrastructure))
Firewall and connection tracking drops: Firewalls and Linux connection tracking (conntrack, which records passing connections in a table) drop packets when the table is full or when they decide a packet doesn’t match the connection’s state. (Infra team (Network infrastructure))
Middlebox over capacity (firewall, IPS, DDoS protection): Firewalls, intrusion prevention systems (IPS), and DDoS protection devices inspect every packet passing through. The moment traffic exceeds their inspection capacity, they drop the packets they can’t process. (Infra team (Network infrastructure))
MTU black hole (only large packets keep getting lost): If the largest packet size a link along the way can carry shrinks and the “too big” notice (ICMP) is blocked, large packets keep vanishing no matter how many times they’re resent. (Infra team (Network infrastructure))
NAT or load balancer mapping expires mid-connection: If a device along the way deletes the mapping for an idle connection (the entry that records where to forward that connection), the next packet sent can’t be delivered. The connection either retransmits over and over until it disconnects, or the device sends back a reset (RST) and it disconnects right away. (Game team (Client development))
Route change / bad ECMP path: Packets vanish for a few seconds while an internet route changes, or steadily on connections assigned to a faulty path among several ECMP paths. (Infra team (Network infrastructure))
Spurious retransmission from latency spikes: A packet that isn’t lost, just very late for a moment, still gets retransmitted if the delay is longer than the RTO, because the sender treats it as lost. (External (External))
RTO settings that don’t fit the environment: Set the RTO minimum too low and even small delays cause spurious retransmissions; leave the default (200 ms) and it’s too long for games, so every loss means a long freeze. (Infra team (Server infrastructure))
Slow recovery on thin streams: When a game sends small packets sparsely, the RTO fires before “three following packets” can pile up. The same loss causes a much longer freeze than it would on a bulk transfer. (Game team (Server development))
Middlebox strips TCP options: When some firewalls or accelerators remove or rewrite TCP options, multiple losses get recovered only one per round trip, or the window (how much can be sent at once) shrinks, and everything slows down. (Infra team (Network infrastructure))
Zero window (a stall that looks like retransmission): When the receiving program doesn’t read its socket in time and the buffer fills up, the sender stops sending and sends only zero window probes. The network itself is fine. (Game team (Client development))

View the illustrated symptom guide